4795 Eastbots - 2024 Build Thread

Post 1: Open Alliance Introduction for 2024

Team Intro

We are ECHHS Robotics, comprising teams 4795 and 4861, the Eastbots and Beastbots, based out of East Chapel Hill High School, and we are excited to be doing OpenAlliance this year! This is our second time doing OA and you can check out last year’s thread here. This thread will primarily focus on the Eastbots build, but we will have periodic updates about Beastbots, as well as overall process posts about each team and the dual-team setup.

We are a student run team with 70 members, 15 leadership members, 6 mentors, and 3 additional teacher supervisors. We’ve worked for the past several years to create training and engagement programs to support sustainable knowledge transfer, along with building awesome competition robots. The team’s mission is “to promote a future of leaders in STEM by teaching passionate students skills in engineering, technology, and leadership. In doing so, we are enabling them to inspire the same passion in their communities and operate with excellence in their work.”

Program Organization

Eastbots and Beastbots

For the first time this season, we will be competing with two FRC teams. More details on the team split and rationales are in last year’s thread, but the highlight is that we are organized as one team building two robots. All students and mentors are on both teams and are able to contribute to either robot, but each has a different focus. Beastbots will be building a stock robot like an Everybot, and is designed to provide primarily younger students and new mentors with fundamentals of engineering and smaller-scale leadership training in a lower-stakes environment. Eastbots will be faster-paced, and more focused on building an advanced, competitive robot. Both teams will be competing at the same district events, but we will only enter a maximum of one into District or World Championships, depending on qualification status.

Leadership and Mentors

The team has six mentors in a fairly flat structure, along with three additional teacher supervisors. To help engage our 70 students across both teams, we have been adapting and focusing on building our student leadership team across the years, settling on the current structure:

|606.8487394957983x656

This leadership team is for the overall ECHHS Robotics organization, not either team in particular. Organizationally, Beastbots will be treated as a major project with a project lead overseeing and helping manage tasking along with the rest of leads and mentors - the entire leadership and mentorship team is responsible for the success of the program, including both teams.

Not all of these roles are filled in a given year as the team’s needs and student base changes, and we will often promote students throughout the season into at-large or named leadership roles as they demonstrate commitment and potential. The structure is less formal than the diagram would imply, with significant overlap between technical subteams, business, and outreach. Each student lead is also assigned one of the mentors to check in with periodically about status, stress levels, and any challenges or concerns they have - this is a new addition for us this year, and has been helpful on both the student and mentor side. A full description of our leadership structure and each role is here.

East Robotics Competition (ERC)

For the past four seasons, the primary focus of our preseason has been the East Robotics Competition. Initially designed as a challenge students could do at home during the pandemic, it has evolved into a full preseason training event both for our new students and other FIRST NC teams. We try to make things as similar to FRC as possible, including a kickoff, game manual, build season, competition, and more, just on a smaller, simpler, and more accessible scale.

This season, we had a new high of 7 ERC teams participating - 3 composed of our new students and 4 from other teams across NC! We will have a follow-up post soon with more detail about this year’s ERC.

Conclusion

We’re all very excited to be participating in OpenAlliance again this year, please feel free to reach out with any questions!

20 Likes

Virtual Workshops - Swerve and Robot Reliability

We gave a virtual workshop for FIRST North Carolina teams on the basics of swerve and what to consider when switching - we have a video recording at:

The slides are linked here, and a list of product recommendations is linked here.

Additionally, I also mentioned a presentation on reliability I gave with Team 888 as part of the Maryland Robotics Alliance’s Virtual Education Day

9 Likes

2023 ERC Recap: Castle Conquest

What is ERC?

This is now our fourth year running the East Robotics Competition (ERC), a training program meant to simulate the FRC-season and competition on a much smaller scale. The purpose of ERC is to train new and inexperienced team members in the technical and interpersonal skills needed for FRC, as well as to help build their confidence, so they can be comfortable working with the rest of the team once the build season begins. In recent years, however, we’ve also opened participation to other FRC teams as a way to help their returning members continue refining their skills or learn new ones.

At ERC kickoff, we present the game manual to every ERC team, either in-person or online through a call; then begins the season. This year, we split our new members into ERC teams of less than 10 students so we could provide each student with the chance to have more say and hands-on time on their robot. Then, over the course of the 6-week build season, our teams worked to make smaller-than-FRC-scale robots with the help of returning member mentors. This all leads up to a competition, where teams get the chance to face off in 2v2 matches, scout, and be interviewed for awards.

ERC has been greatly beneficial to us in helping prepare new members for the FRC season, both in participation and collaboration. This year especially, we’ve seen new members grow familiar not just with those on their own ERC teams, but with those across other Eastbots teams, leadership, and returning members as well.

This Year’s Season

Game

Manual and Kickoff Slideshow

The ERC game this year was called Castle Conquest. The kickoff slideshow is linked here, and the game manual here.

The winners of the 2023 East Robotics Competition were Team 3822 Neon Krakens and Team 4561 TerrorBytes! Congratulations to both teams!

Changes from Last Year

Ranking Points and Scoring Website

For ERC this year, we made some quality of life improvements and other changes to more accurately represent the FRC season. The first was that we created more ranking points, these based on game tasks, while last year’s ERC only had ranking points based on winning or losing. While no alliance ever obtained these ranking points, they showed the ability to in the playoffs, a change we plan to continue in future years. Another major thing we had this year was a scoring system. Referees were able to input match data into a website on their phones, which then output on a website we were projecting onto a screen behind the ref table, making it easier for teams to keep track of their scores and rankings.

Our Team

Continuing on last year’s tradition, our new members were split into three ERC teams: 47, 79, and 95. Each team met two to three times a week, with each meeting containing all three teams to allow for both intra-team communication and inter-team interactions and help. We also had returning members and leadership helping mentor and support our ERC teams.

Other Teams

After last year’s success with other teams, we continued expanding ERC this year, gaining participation from four other NC teams this year! Joining us were Neon Krakens (3822), a returning team, TerrorBytes (4561), Titanium Tigers (4829), and Fire Hazard (7671), and they all sent one ERC team. The continued expansion of ERC from last year, where we only had 2 other attending teams, allowed us to keep developing our social network, expose members to a wider array of ideas, and increase the level of competition, especially with the performance from these four teams.

Additionally, TerrorBytes, Titanium Tigers, and Fire Hazard all came to kickoff in-person, where we got to work with them on strategic design and concepting for their ERC robots. We visited Neon Krakens and Fire Hazard during the build season to check in and offer to help. It was a great opportunity to see other teams’ buildspace and process and both a teaching and learning moment.

We are glad to have gotten to work with all these teams this year and are tremendously appreciative of them!

The Bots

Robot Descriptions and Pictures!

Team 47 (Eastbots)

Eastbots Team 47’s primary mechanism was a rotary arm with a wheeled intake, mounted on the front of the bot opposite the driving wheels. It could intake wiffle balls both from the ground and the feeder station and score low and high. It could also theoretically score rings if aligned correctly, but that was never tested. (Robot CAD here)

Team 79 (Eastbots)

Eastbots Team 79’s main mechanism was a virtual four bar made from aluminum tubes with a 3D-printed custom intake. The robot was capable of intaking both wiffle balls and rings from the feeder station and the ground and scoring them in or on every possible scoring goal. (Robot CAD here)

|295.66084788029923x222

Team 95 (Eastbots)

Eastbots Team 95’s robot had a wheeled intake that was made of 3d-printed plates connected by churros. Its position was fixed through the use of uprights and max spline, allowing them to intake wiffle balls from the feeder station and score high. (Robot CAD here)

|887.3766233766232x661.0909090909091

Team 3822

Neon Krakens’ robot was very similar to their robot last year, they had a mechanically actuated scooper attached to a one-stage elevator

Team 4561

TerrorBytes’ robot had a custom bent sheet metal drivebase with four driven wheels. They had a custom intake similar to the 2023 Everybot intake attached to a one-stage elevator, and was one of the only two teams that demonstrated the ability to intake and score both game pieces on both levels.

Team 4829

Titanium Tigers’ robot had a custom drivebase with a horizontal intake mounted to a one-stage elevator. They could intake from the ground and score low.

|542.1176470588235x406.9854573630944

Team 7671

Fire Hazard’s robot had a bucket to catch wiffle balls, hence the name ‘bucket bot’, and a pivot on which they could rotate the bucket to dump the balls and score low. They also performed defense and had an auto that worked every match.

|230.92913385826773x171

Lessons Learned

This year, we held a retrospective meeting with our ERC teams so new members could go over what they felt went well, what didn’t go as well, what they learned, and what they wanted to improve on so they could work off their mistakes and apply the lessons ERC taught them during the FRC season. Five major takeaways our teams had were: better communication, proper time management, build simple but effective, ask for help (leadership isn’t scary), and think critically (leadership also isn’t always right).

Better Communication

Our team utilizes slack for communication, and while one of our teams has been active in their channel, posting meeting summaries, to-do lists, and availability updates, the others have been less so. Then, at a meeting, one such team made a major decision to change part of a mechanism for their robot. When members who were not present at that meeting showed up at the next meeting, they were shocked to see the change and hurt since they had both not been informed about it and not been part of the decision. This experience helped our teams realize that communication is an integral part of being on a team, and our new members plan to better communicate during the actual season.

Proper Time Management

While one team had a robot that was competition-ready by the actual competition date, having already had multiple meetings to test and troubleshoot, our other two ERC teams were scrambling to figure things out and create fixes the day of, very in-spirit of a first-week competition. Even so, they all acknowledged that there were things they could have done, decisions they could have made, which would have allowed them a more proper use of their time. They pointed out certain things they could have done in conjunction with other parts of the build process, but had waited on or not done, like motor testing, which ended up adding even more time by presenting issues they needed to troubleshoot.

Build Simple but Effective

This was a lesson that team 95 specifically was able to take away from ERC, and a motto we’ve been using for our robots. The ‘build simple but effective’ refers both to mechanisms and to what the robot can do. In 2023, our robot Hydra couldn’t score high cones and focused mainly on scoring game pieces in the middle level, giving us a simpler task that we could learn to do and do well. While they felt they were running out of time, team 95 decided to change from a rotary arm to a fixed-position arm, leading to a simpler robot that was still effective for the game.

Ask for Help

As we had many leadership members help mentor ERC teams this year and work directly with new members, they learned how to talk and interact with them, realizing ‘oh, leadership isn’t that scary.’ We believe availability and approachability leadership members presented themselves with to the teams helped them feel more comfortable asking them for help, in the process learning how to ask for help, possibly without even ever being afraid to do so in the first place for some.

Think Critically

While new members learned how to ask for help, they also learned how to think critically about the advice given, even if it’s from leadership. This was especially true with one team that accepted advice from a leadership member for part of their intake mechanism, only for it to fall through. Their reaction to it was an ‘oh, I should’ve known,’ and they acknowledged that there wasn’t anything wrong with their initial plan, that it was more sound of an idea even, they had just changed it on the advice of a leadership member. Sometimes, it’s hard to differentiate when to listen to advice and when not to.

Conclusions

ERC is a program we’re very proud of. It’s been greatly beneficial to us, this year and in the past, in helping integrate new members into our team, furthering their knowledge and skills, and developing greater confidence for all members involved, new or returning. We’re excited to be able to keep improving this activity, both for ourselves and others, and keep increasing FIRST NC participation.

Coming soon we’ll make another post about more of the organizational aspects of ERC, including how it’s planned, the legal control systems, our custom KOP drivebase, and more.

Any and all questions are welcome, thanks for reading!

This post was written by Vicky, our ERC Lead.

8 Likes

2023 CAD and Code Release

Tech Binder

Code

Highlights

  • Pathplanner 3 game piece and 2 game piece + balance over charging station auto
  • Central state manager for mechanism collision avoidance and double-extension avoidance
  • Automatic game piece possession detection

CAD

Highlights

  • Single-joined dead-axle MAXSpline arm with rotary wrist
  • OTB roller bar intake handoff into roller craw
  • 24"x24" frame size

Happy kickoff, everyone!

3 Likes

Build Season Update 1/7: Kickoff and Strategy!

Saturday - Kickoff Overview

Wow! Is it kickoff already?! We met to watch the livestream, ate pizza, and did early game analysis.

Directly after the game was released we broke off into 8 groups with roughly 5-7 people. We read through the game manual and analyzed every task we could do in this game, then ranked them based on value and difficulty in this spreadsheet.


After we discussed it in small groups, and consumed too much pizza for our own good, we met as a large group and began discussing potential archetypes. Here’s an abbreviated list of things we discussed, bearing in mind that we’ve decided to design a robot that focuses on scoring rather than one that prioritizes RPs.

  • Ground intake is critical for autonomous routine potential, and very valuable for quick cycles due to field layout
  • The field layout poses significant visual obstructions, we’ll need to heavily prioritize getting vision working
  • Sacrifice trap capability (it’s a trap!)
  • If it comes down to an amp-speaker choice, we’re going to be prioritizing speaker. However, it’s very possible that we could do both, and are going to be attempting to do so

We were all very interested in the Coopertition and Amplification bonuses, particularly because of Coopertition’s influence on rankings this year.

Screen Shot 2024-01-07 at 8.57.58 PM

We put some discussion into RPs and how to achieve them, but it wasn’t our focus and it isn’t what we plan to be designing our robot around.

We managed to get our hands on some of the notes and had some impromptu Human Player practice, although it was a little unconventional… we’ll see how well it translates.

Weekend - Game Analysis, Strategy and Conclusions

Before we get into strategy, here is a bit of info on our competitive and technical goals:

  • Finalist at our first event (Week 1: Chapel Hill)
  • Peak at our 2nd event (Week 3: Ashville)
  • DCMP finalists.
  • Rank in top 7 in NC to qualify for Worlds
  • All as a simple but effective (the Easbots way!) well practiced cycler with advanced software controls and autonomous.

In a call on Sunday, we started discussing the archetypes we came up with in our kickoff meeting, starting with a priority list. We determined that the most important things for us are ground intaking, speaker capabilities, amp capabilities, then climb. Trap’s positioned comically low because we believe that focusing on it would take away effort that’s needed on other mechanisms.

This is our finalized priority list.

When discussing what type of intake and outtake system we’re going to use, we came up with some goals and evaluated each mechanism archetype (ie, over the bumper versus under the bumper) based on how well it will complete them. Because bumper cutouts are now illegal (R401), we’re going to be getting crafty in comparison to our 2022 season.

A lot of our decisions will come down to prototyping. Moving into week 1, we’re going to be testing shooter compression using hype blocks and will be testing the viability of a fixed position amp and speaker shooter to determine whether or not we need a variable position shooter or secondary amp mechanism. In the meantime, we started some CAD sketches of potential intake geometry.

We also did some broad path planning for what we’re hoping to accomplish in the first 8 weeks. We’re planning on constructing a Kitbot this week to let our programmers start testing autonomous routines and shooter code.

Final Thoughts and Schedule

We are supa excited about this year’s game! We are planning on doing a weekly update on Sunday. Thanks for tuning in, make sure to like and subscribe.

Happy designing!

-Reese and Dharma

6 Likes

Build Season Update 1/14: Prototyping & Design Review

Hi all, we started working on several intake and shooter concepts this week.

Shooters

Kitbot

Testing video (4795 Kitbot testing)

We’re building a very basic Kitbot that we’re going to place on a swerve drivebase to give programmers a robot to work with so they can start autopathing and testing early.

Because we used compliant wheels instead of stealth wheels, our bot doesn’t shoot particularly well. We ordered some stealth wheels and will be testing success with them later this week.

Horizontal Axle Shooter

Inspired by Team 95’s shooter, we made a rudimentary prototype of this concept and began fleshing out CAD. We decided to drive each side independently instead of using unparallel shafts and different-sized wheels to introduce spin. Because of its resilience against warped gamepieces, we’re planning to proceed with this concept. However, we’ve seen no significant benefit from inducing spin, which might add unnecessary complexity.

Vertical Axle Shooter

CAD linked here.

We created this prototype to test the consistency of horizontally shot notes. This prototype is heavily inspired by Cranberry Alarm’s Ri3d shooter design and was designed to test the best compression. It consisted of four 4” grip wheels driven by two through-shaft vortices for the sake of simplicity. From some initial testing, we have realized that the 80a wheels from Andymark are way too slippery for the notes, causing some inconsistency in the shooting. Hopefully, the 40a wheels from AM and 45a from TTB will improve the grip.

However, some concerns about the varying compression of notes due to deformation and wear, causing inconsistency with shooting, got the idea scrapped in favor of the horizontal axle shooter.

Intakes

Over-the-Bumper

CAD can be found linked here.

Our over-the-bumper intake consists of two sets of rollers, one to intake and one to vector. The outer set has 3” compliant wheels on the top row and 2” compliant wheels on the bottom, and the inner set has two rollers of compliant wheels arranged as shown in the diagram below, with the intention to vector rings to the center.

Through testing, we learned that less space between rubber wheels = better since rings can get caught in-between them, as well as that the mecanums weren’t really effective in vectoring the rings. This week, we plan to try physical vectoring, prototyping a sort-of funnel with wood to physically force the ring (diagram below), to see if that’s more effective, as well as omnis to aid that. Additionally, our rings would sometimes get caught on the pulley connecting the front two rollers. We’re currently brainstorming fixes, one of which is a pulley cover, though a drawback of that is that it would decrease our intake width. Another fix would be to move the pulley to the outside of the intake plates, but this makes the pulley exposed and might be a risky move.

Under-the-Bumper

|624x471.26213958330965

This intake follows very similar geometry to our over the bumper intake. We didn’t do any specific prototyping for this due to the similarities, but currently do not plan to advance with the concept as both the over-the-bumper and in-between intakes offer more benefits to less risk of getting the ring caught on our swerve modules.

In-Between (Grasshoppers intake)

Our design lead Wesley created some sketches for potential geometry of an In-Between Intake to guide indexing design.

Key parts of the design:

  • Allow for variable angle shooter
  • Fast and consistent indexing
  • Touch it own it
  • Potential upgrade for amp scoring
  • Stowing position to go under the stage

Preliminary Design Review

We reviewed crayola CAD all of these designs on Saturday (1/13) and took notes in this doc. To summarize our primary takeaways:

  • We’re going to be moving forward with the horizontal axle shooter concept due to better predicted consistency against warping gamepieces
    • Vertical axle shooters tend to deform gamepieces into a more oblong shape, leading to less compression. While we theorized that we could have a human player manually bend any warping pieces back into shape before releasing them, this was not something we wanted to chance
  • We’re going to focus on the over-the-bumper and in-between intake concepts, as the under the bumper concept has less to offer than the in-between concept does
    • We’re still testing to see if we can repurpose an over the bumper intake as a secondary amp mechanism.
  • Passive amp mechanisms may be more difficult than they seem
    • We believe that actively controlling a gamepiece until it is either scored or on an uninterruptible trajectory to be scored (ie, shot from an outtake) is the best way to guarantee success, and worry about the viability of passive ramp mechanisms
7 Likes

Do you have any videos of this testing?

Yep! Still some issues to sort out with notes jamming on the pulley when entering from the far right, but pretty happy so far, and we’ll be adapting this geometry to the Grasshopper intake

4 Likes

I can’t tell, but do y’all have some sort of floor/roof to keep the game piece contained?

The intake is designed to have belts on top to help contain the gamepeice. However they are not implemented in the video.

2 Likes

Build Season Update 1/18

Hi all, here’s a short update on our week so far:

We’re prototyping with an adjustable-compression horizontal axle shooter, where we’re using endcaps and differently-sized 3d-printed spaces (⅛”, ¼”, and ½”, which allows us to utilize 1” to 1⅞” compression) for quick compression swaps while prototyping. CAD can be found linked here.

We made a decision to use an in-between-the-bumper (ITB) intake and a prototype CAD was made using the same compression from our over-the-bumper (OTB) intake.

|473x372.9315068493151

While testing with a wooden-plated prototype, we found that due to the hex shaft spinning inwards with the bottom roller, the ring was getting intaken by the two of them instead of going up like we wanted it to:

So, we took apart our pulley system and spun the roller bars individually simultaneously, which worked. Additionally, we found that while intaking from the motor side, the ring could get stuck between it and the roller, stalling the two.

With these flaws in mind, the second version of the intake moved the hex shaft and motor above the outer-roller so they wouldn’t get stuck in the way. CAD can be found linked here.

In the future, we will probably change the design from the front-mounted system back to the side-plate system so we can make it thicker and limit collision damage.

While intaking from the non-motor side, everything went fine, and we found that as long as the ring was touching a wheel with at least half the ring within the intake, we’d be able to intake it.

Lastly, we tried intaking with a physical vector and found that the ring follows the path we gave it pretty well.

All these tests were completed on tile, and we will be redoing them on carpet later this week.

-Vicky and Troy

4 Likes

Build Season Update: 1/22

Shooter Testing

With a horizontal axis shooter prototype fully equipped with two new vortices, we proceeded to spend quite some time this week breaking eardrums within a 15.7 meter radius with the constant 153 dB humming noise of said vortices running at 100% speed.

Oh, we also tested how well this shooter design accelerates the notes at different compressions - that’s kind of important too:

1” spacing

1⅛” spacing

1¼” spacing

In terms of exit velocity, we ultimately decided that 1⅛” spacing (7/8” compression) was the most effective, as we found 1¼” spacing to be too loose and 1” performed similarly to 1⅛”, but with more motor strain.

For calculating the initial velocities, we used logger pro to analyze the videos of the physical shooter to guess at the real initial velocity while doing very-much-too-idealistic calculations by hand using kinematics from ΔY and ΔX to find the theoretical value.

Math for compression testing of ⅞”

ΔY = .88m

ΔX = 12.505m

ΔY = ½(acceleration due to gravity)(time2)

.88m = ½(9.8m/s2)(t2)

t=.423s

ΔX/time = initial velocity (because velocity is only in the x direction)

12.505m/.423s = 29.52m/s

So we may have stacked up too many not-assumable assumptions, leading to an exit velocity of literally highway speeds. But hey, it backs up our 1⅛” spacing assertion, so… shrug.

Consistency did seem to be an issue at times, but that could be due to a variety of factors in the prototype that wouldn’t be present in the final mechanism (terrible feed inconsistency, wobbly side plates). But if worst comes to worst, it can be a fun problem for software to handle instead…

Handoff Testing

In parallel to shooter testing, we also put together a prototype setup to verify how well notes would travel between the intake and rollers at the bottom of the intake.

While the note transfer was generally fairly smooth when the note was centered on the intake, the handoff struggled in trying to vector the notes inward when intaking significantly off-center. So we tested with some very janky physical vectoring, though that wasn’t too successful.

We ended up having around a 50% success rate throughout our testing, which means - if this was being graded in our school district - it’s equivalent to having no handoff at all (because the 50% floor policy is perfectly flawless… at inflating senior graduation rates anyway).

Basically, it means we still have work to do here to find a more consistent solution.

Index Testing

We did some simple testing to see if a single-roller indexing system is viable. It is.

Design

Thank you so much to FNC for providing a design review! We were able to go over our CAD with professional engineers.

1/17 1/19 1/20

Summary

What we learned

  • We should test our maxspline for shearing
  • Counterbalancing is something we should look at (constant force springs?)
    • Reduces backlash, reduces oscillations (“wobble wobble wobble”)

What we’re taking action on

  • Using 1/8th polycarb on the shooter for weight reduction purposes
  • Chain tensioning methods for pivoting chain
  • Go to straight side plates for intake
  • Add vectoring plates on intake
  • Shift motors back
  • Adding springs for weight reduction/oscillation reduction
    • Maybe making a shorter shooter if this does not work

Goal: Get ground intake + speaker shooting robot out the door ASAP, then add functionality

This year we decided to have a very detailed master sketch and design each mechanism accordingly. This makes task delegation easier, as the geometry of each mechanism is determined before the mechanism design. We’ve been able to get CAD done quickly this year because of the influx in interested desi %gn members.

Pandas for Scouting

Last year, we tried out scouting apps for the first time. While there were many issues with them, and we found we prefer paper scouting, the different types of data visualization made possible by the apps were something we wanted to keep. So, this year, we plan on utilizing a hybrid scouting system where our scouters scout using paper and then a head scout inputs the data into Google Sheets. This way, we open up more options in terms of data visualization.

Right now we’re experimenting with pandas (python for creating graphs from tables that we convert into csv files). We came up with some fake numbers for 6 teams playing 12 matches, and then used pandas to graphically represent them.



Link to google colab notebook - Here

Link to CSV file- Here

Conclusion

Thanks for tuning in! Insync said it best: bye bye bye

7 Likes

Build Season Update 1/24:

Here’s a brief update on this week. Lots of testing!!

Horizontal Axis Shooter testing

We tried 12” compression with 80 and 40 durometer wheels and we found it reduced shooting consistency.

We also found that the notes were not actually spinning like we intended.

Because of this we’ve decided that we are going to use the same 40 durometer wheels on the shooter. CAD for the prototype can be found here.

Shamper testing

We tested the shaper at various setups. We found it to be tolerant to angle changes and sensitive to distance changes. We cut the shooter plates with it integrated.

Handoff

We 3D printed a funnel which helped a lot with intaking notes that were extremely off center. We manufactured the intake plates out of aluminum and are working on the permanent assembly now.

Indexer

We tested with unpeeled polycarb because there was less friction. It worked quite well - very consistent and fast. We’re planning on putting HDPE on the actual construction, or teflon tape.

Peace out, a town

-Dharma

5 Likes

Build Season Update - Software: 1/28

Welcome to the Den! Our software team’s very own hall of tranquility, insulated from the ear-breaking screeching and thudding noises of prototypes flinging notes all over the place.

(The Den in all its glory - special thanks to Mr. Day for letting us use it)

It’s been quite a secluded past few weeks - which has been good for getting work done, but we’re definitely happy someone fiiiiinally decided to open Pandora’s box (of software ramblings).

What We’ve Been Up To

There are two things we’ve really wanted to improve upon from last year: spreading tasks out and being efficient with testing time, both of which pretty much go hand in hand.

For the former, we’ve set out a more detailed organizational tasking plan to give everyone on our subteam who would like to contribute a chance to do so.

(General Tasking Sheet)

(Climber tasking progression, which we happen to be behind on…)

This also provides a very nice learning opportunity for many of our new members and we’ve had at least one of our two software leads floating each week to help foster that.

For the latter, we’ve ramped up our pace compared to 2023, spending most of these first three weeks bolting out the major components for code v1 following alongside the design iteration and prototyping process so that we’re ready to test whenever we get the green light. And we’re almost there - just pending some final simulation testing in a couple of our branches.

(Simulation is actually so nice for code logic verification)

Once again, a very special thank you to Team 6328 for their work on AdvantageKit (AdvKit) and AdvantageScope - it’s made our lives so much easier. So much so that we’ve chosen to run an AdvKit codebase for Beastbots (our second team) as well, as we feel that it’s important enough to teach everyone on our team despite the additional complexity.

And while most of what we’ve done so far is mostly the usual subsystem and control code, there is one project that we’d like to highlight.

AdvantageKit MAXSwerve and the REV Spark Wrapper

Yeah, yeah, I know. These are listed as two separate tabs on the tasking spreadsheet so they’re technically separate projects, but they tell a story together, so I’m clumping them together - deal with it.

Since we never got swerve with AdvKit working this offseason, we decided to give it another shot early this season. We had originally planned on adapting the AdvKit swerve template from SDS over to MAXSwerve; however, a week and a half got us to a point where odometry was messed up when swerve was driving correctly and swerve was messed up when odometry was functioning correctly - basically, that plan flopped.

We then completely backtracked and added AdvKit functionality onto the MAXSwerve template, which we were able to get working in one meeting of testing - except everything was driving 90o offset and we just couldn’t figure out why.

After scouring over the swerve code at home, we found that it was just a simple controller joystick to xy-speed supplier mismatch, as the xSpeed in the code was supposed to line up with the joystick Y axis.

(Joystick and field axes being annoying)

(Swerve testing in sim)

Ok, so swerve works, and our job here is done right?

I mean, yes, but… why not add a REV Spark wrapper on top of it while we’re at it?

Long story short, we added the wrapper code and broke swerve again, with a whole array of weird turning module oscillations, terrible module state optimizations, and completely incoherent module directionality:

We were really worried at one point after trying the MAXSwerve template code to see that swerve still didn’t work.

Turns out though, the entirety of the issue was that inverting the motor itself isn’t the same thing as inverting the turning encoder (and as to why the template code didn’t work, uhhh… who knows?):

In hindsight, it probably wasn’t the wisest choice to run the very first test of a new wrapper class on our most important mechanism, which we had just managed to get working with a fancy new framework. But thankfully, the only consequences were a scare for our team and two days of testing time in exchange for code with a working motor wrapper. And very thankfully, we didn’t fry any Neos! That was the whole motivation behind making the wrapper anyway after burning out two of them in the offseason when we forgot to set current limits.

(Vision Sneak Peak?)

Anyway, there are more projects, particularly our vision revenge tour, that are worth mentioning in depth; however, if we add it to this post, the seventh mass extinction will be over in the time it takes to read it, so we’ll refrain for now.

But no worries, we’ll get to it…



SoonTM.

12 Likes

Build Season Update: 1/28

Design

We had a design review on the 24th which went over the entire robot CAD, with a focus on pivot and gas shock geometry.

  • In terms of key takeaways, for the pivot, we decided that:
  • It needs an absolute encoder, and to focus on minimum tolerance buildup
  • Because the chain tensioning could cause plate to bend, we’re going to extend the motor mounting plate and run a crossbar between
  • We talked about some ways to support the motors, but we didn’t come to a conclusion
    • Always make sure that motor settings are set correctly!!
  • We may not need two vortexes, but overpowering won’t really hurt
  • We talked about using linear actuators, but due to their novelty both on the shelf and to our team, are not progressing with this idea currently

Screenshot 2024-01-29 at 9.43.02 PM

Hard Stop

  • Add a hardstop at the stowing position – it would shatter the gas shock if it was our hard stop
  • Add another on the frame/tube at max upwards gas shock extension

Ballasts

  • Steel front frame rail, since we’ll be VERY tippy if we don’t

Cameras

  • We need many cameras of different types everywhere!

Link to full design review doc - Here

Intake

With the insights gained from prototyping in mind and a design basically done, we started assembling our actual intake to go on our robot. (CAD can be found here.)

Off the bat, there were already a few road bumps we found ourselves running into. We had neither the belts nor the gears we needed to build the intake, but we were able to find some temporary fixes while waiting for parts order, some of which worked better than others.

We replaced the RT25 40T belt connecting the motor to the bare hex shaft with a 3D-printed one, which ended up working better than expected. Then, we replaced the RT25 48T belt with a longer one and its corresponding pulleys with larger pulleys and our two 36T gears with an infinity belt. However, these two fixes ended up adding too much friction, as a pulley was rubbing against our front frame rail and the infinity belt was really tightly tensioned, which our motor did not exert enough torque to overcome during testing.

Additionally, while assembled, we were able to test the intake by spinning it with a power drill and found that it does work. Going forward, there are still a few things we need to figure out. One is where to mount the 3D-printed physical vectors, especially the one on the motor side, as we don’t want our wires to be exposed to danger.

Shooter

We began construction on our final shooter. It has the same geometry as the wooden plates used for prototyping but cut out of 1/8in aluminum. The shooter is driven by 2 1:1 NEO Vortices, one for each roller. We are just waiting on some RT25 belts from REV so we can mount it to the tower.

Scouting

This year we’re going to have scouts using paper sheets and then have someone input the data into this spreadsheet.

This way we can look up each team and see all of their data for both pre match strategy and picklisting.

We’ve also been experimenting further with pandas. The photo above shows a radar chart with each team’s matches. We are still trying to figure out the best way to graphically represent all of our data.

Conclusion

We will send another update later this week and do an in-depth review of design this weekend.

Gotta bolt!

7 Likes

Weekly Update: 2/1

Drivebase Intake and Tower Assembly

With parts orders beginning to roll in, we were able to finish assembly of our drivebase, reattaching swerve modules and crossbars for mechanism mounting. The intake is mounted via bolts into 2 WCP tube plugs in each frame rail for both ease of maintenance and stability.


We began assembly on the tower, cutting and mounting the UHMW sheet and the hex shafts, as well as inserting thrifty inserts into all of the 3d printed pulleys.

Intake testing

After mounting our intake we did some preliminary testing. We found that the gears were rubbing on the front frame rail, and the neo did not have sufficient torque to force the note through unless we gave it 100% power.

New Motors

We got the 3 Kraken motors that we ordered and co-opted our drivebase for use as a testing rig. All 3 motors worked wonderfully right out of the box.

Gas Shock Shenanigans

We plan on using gas shocks to dampen the arm. Aaron did the math and made a desmos calculator for us to figure out the torque(and thus the gas shocks) needed to keep the arm stationary.

We decided on two 20 lb gas shocks with ~23” extended distance, from Lift Supports Depot,

3d Printed Belts

We were inspired by Spectrum to try TPU belts. In the past we have used some 95a TPU timing belts for prototyping but we encountered a lot of stretching . Even if we undersized the belt, it still skipped more than we like.

Due to shipping delays, we tried it again. This time we used a higher durometer TPU (64d) and it worked much better. We undersized the belt by 2 teeth to replace a rt25 40t timing belt and found that the belt did not skip even when we stall a direct drive Neo on it.

Here is the RT25 belt generator we made based off of Spectrum’s HTD 5mm generator - RT25 belt generator

-Ethan

13 Likes

I love this, weve experimented with 95 TPU and decided it was not ideal I’m gonna test print something with 64d when it comes in, I love it!

1 Like

Weekly Update 2/08:

We have been very busy since the last update - we have most of a robot now but still have a ways to go. Specifically, Whatever-Our-Robot-Name-Will-Be MkI is coming together nicely mechanical-wise, but we still need some wiring and testing (and a name) before it’s functional!
image

Pivot:

image

  • The pivot - in all it’s overgeared-to-the-nine-circles-of-the-inferno glory - has been mounted on the robot
  • https://youtu.be/2TW26dvnq9o
  • Some notes from towerless testing
    • Our primary concern was making sure the inversion and motor following were correct before mounting tower
    • We started out testing one motor manual control, but couldn’t get one of the motors to spin until we realized the motor was set to follow itself (We forgot to reset defaults in code…)
    • Kept control at manual for now, will migrate over the control loops and setpoints once manual control has been tested with the tower mounted
  • More specific design recap to come

Tower:

While waiting for the pivot assembly and testing, we did some testing on the assembled tower, resulting in many minor iterations:

  • Slight design modification necessary due to poly belt slipping - added a neo 550 driving one of the handoff rollers to address this
  • Discovered that we needed to do more filing of edges to consistently intake Notes

  • Indexing and handoff wasn’t acceptably consistent

  • Biggest issue, it seemed, was getting the note to compress to 12 in without guidance
  • Unassorted batch of attempted solutions
    • Adding more wheels to handoff shaft, and mounting some outside of the tower
    • Spamming teflon tape everywhere
    • Aggressive sanding and filing of corners and sharp edges
    • Addition of a 2nd baby NEO
  • We might also try some additional 3d printed funnels on the tower side to more gradually compress the note in the future, depending on how it performs during on-robot testing

After mounting the tower onto the pivot and adding gas shocks, we ran into quite the fun wiring dilemma:

  • We have 4 motors on our tower: 2 Krakens, and 2 Neo550s. These motors all have wires that need to find their way to the PDH
  • Due to design constraints the wire runs are not simple and necessitate some creative problem solving. Our current Ideas include:
    • A cable carrier in the highlighted region:
      image

    • A plate underneath the tower to mount wires to

    • Various other cable carrier ideas

    • The one blindingly obvious idea none of us can see

On the bright side, this is the last major problem we need to solve before testing can commence, so hopefully That-Which-Cannot-Be-Named (because it doesn’t have one yet) will be up and running very soon.

General Electrical Updates:

  • Other than the aforementioned challenges the electrical subteam has begun to implement the Molex CAN connections using the kit we received from FIRST choice. I am not an electrical member but I am told they are very nice and expensive. (They are VERY nice! - Electrical)
  • Electrical layout complete
  • Preliminary drivebase and pivot wiring completed, in need of some wire management and time
  • We began considering sensor options for both indexer and intake to help our driver out:
    • HiLetGo
    • Banner
      -Ethan
6 Likes

2/10 Software Update

Since the rest of the team is busy putting together our robot, now seems as good a time as ever for a brief(ish) update from the Den.

Firstly, with the time for round one of testing quickly approaching, our team’s overarching focus comes down to two points:

  • Have a plan and follow it
  • Do the little things right before, during, and after testing

We want our new members to take a large role in testing and debugging this year to prepare them for the pit crew experience (two robots = more pit crew members👍), so we’re hoping that emphasizing these two points will make testing simpler and go by smoother, particularly when things don’t work.

Ok, that’s enough about that, let’s talk about actual code stuff.

Design Makes Our Lives Harder By Making It Easier

Rewinding to this past offseason real quick to start:

September 2023: We replaced the pneumatics on Hydra’s (our 2023 robot) wrist with a motor, creating ~15 degrees of backlash in the process due to poor tolerancing. As a result, we had to use the motor to replicate pneumatic motion by running it at a constant speed and stalling it against a hardstop…

That’s the big problem we wanted to avoid this year with the shooter pivot, as we want the tower angle to be accurate and stable so that our shots are accurate and consistent.

Part of that solution was adding gas springs to hold up the arm and relieve some of the torque necessary to accelerate the arm from the pivot motors. But since feedforward models don’t have a spring gain term, we had to make our own, taking the physics calculations we’d previously done as our own addition to the feedforward model, which calculates the voltage necessary to offset the force of the gas springs.

From there, we’re planning on running a classic arm feedforward and a PID control loop with trapezoidal motion profiles to achieve the accuracy and speed that we would like on our pivot.

Of course, whether it works out remains to be seen, as we don’t have springs in our code simulation testing (that’s more to help verify we have limits in place and that the control loop is working, arm + spring simulation is here, courtesy of Aaron). Updates on this to come after testing happens.

Visiting the (Robot) Optometrist

It’s finally time we revisit an old friend of ours… vision.

A quick recap from last year:

2/19 - Post Yeti testing: Vision align works!

3/12 - Post Asheville Week 1: Minor setback?
Screenshot 2024-02-04 195014

3/21 - Pre-DCMP: Is it time to pray yet?
Screenshot 2024-02-10 221423

1/11 - Post Rumble in the Roads: :resigned-defeat:
Screenshot 2024-02-04 194841

TL;DR - Last season, we were the Western Australian farmers in 1932 and the cameras were the emus

This season, we’re planning on using PhotonVision on an OrangePi5 with a pair Arducam OV9821s as our main vision processing system for a few reasons:

  • Multiple cameras = better vision coverage
  • PhotonVision’s simplicity is appealing since we have about three months of collective vision experience
  • The OrangePi5 + OV9821 is a hardware combination that has been proven to work well.

And in an effort to NOT repeat history, our vision task group has spent the previous three weeks setting up a working vision system to run on-robot.

We struggled a bit with calibration, as that was one thing we’d never done before, resulting in a lot of… interesting results:

After starting out with a printed checkerboard pattern (which turned out to not be 1 in squares) and then loading a checkerboard image on our school-issued chromebooks, we finally switched to using calibdb’s chArUco calibration, which we’ve had best results from (~30 ft of detection range).

As for the code, we’re mainly using vision measurements to complement our drivebase odometry, so that we can have a command that will accurately lock the robot rotation to the Speaker.

We did get in some tests of this using a purely reactive PID loop, but have since edited the command to use the estimated pose n = 1 (arbitrary value) periodic frames into the future based on chassis speeds to calculate desired heading. But again, we’re waiting on testing to see how helpful that is.

Anyway, that’s all the ramblings I have without much testing to back me up, so I’ll end it here and steal raid amiably invade one of the next posts to update on how code testing goes.

5 Likes

Build season update 2/18:

Hard stop

We decided that the travel of the gas shock is not sufficient to act as a hardstop, so we added hardstop at the front of the robot. It is also used as the limelight+radio mount for now. The purple part is printed out of TPU to absorb shock.

PDH issues

During testing, our CAN bus ceased receiving traffic, which was traced to the PDH displaying a “Device Overcurrent” blink code and reporting CAN errors on the REV HW client. Despite multiple reboots, errors persisted. Disconnecting the PDH from the CAN bus allowed other devices to function, but reconnecting it resulted in abnormal behavior. REV devices showed normal blink codes but were undetected on the HW client, while CTRE devices displayed “Fault Detected” codes. Vacuuming the PDH for debris and toggling the terminating resistor yielded no change. Proceeding with testing using a spare PDH entails the risk of encountering similar errors, suggesting further investigation into potential causes like electrical issues or component failure.

Testing

Amp scoring

We tried to replicate our prototyping setup on the actual robot during testing. It took us a while to find the correct arm angle and roller speed to get consistent scoring. Once we found them, the amp scoring was very consistent. The arm needs to be kept a certain distance away from the amp so that the note can slide into the amp without getting bent too much. We found an angle where we can run into the amp wall and the arm would have a correct spacing away from the amp to score consistently.

Amp Testing

Intake changes

We initially designed funnels to center the gamepiece before entering the tower, but it introduces interference with the tower wire and can not get the gamepiece close to the center enough to fully complete the handoff. We were inspired by team 95’s intake roller design and added two extra rollers to guide the gamepiece to the center of the robot. This solved the centering issue but the handoff is still having some inconsistencies when intaking from the side of the intake, mainly due to the lack of contact with rollers in the tower. The problem will be elaborated further in the drive testing section.

To further reduce the resistance when entering the handoff, we designed another set of rollers at the entrance of the tower.

We will try some other combinations of wheels in the future and see if we can get more control of the gamepiece on the tower side.

Speaker and drive testing

During the testing, we found a very consistent subwoofer speaker shot however, there multiple problems that we ran into during the testing. One of which is the note getting jammed under our intake, probably due to the high compression of our intake and the gap between the lower roller and the framerail. The other was the note getting stuck between our intake and indexer in this scenario, the note was getting pushed down by the bottom roller of our intake. This downward force caused the gp to get lodged between the rollers and the frame rail.

We received another batch of notes recently and noticed that they are a lot stiffer than the original ones and behave quite differently. They are more likely to get stuck in the intake.

Swerve Issues

Disclaimer first - we don’t really know what exactly is going on here, just that something’s wrong.

So far, here’s what we know:

  • Not super frequently but occasionally, a swerve motor will oscillate back and forth
  • It happens to both drive and turning motors and on both the main and testing robots
  • The issues goes away if we power-cycle the robot or redeploy the code
  • Last time we tested it, the pivot control also didn’t work correctly while the swerve (drive this time) motor was oscillating, but both were fine after power cycling

Our best theory currently is that there are CAN frames being dropped on initialization that result in bad PIDF setpoint following (none of the SparkMaxes/Flexes have ever acted like this and they all don’t have PIDs running on them). We’re planning on added delays and multiple motor setting calls in code as well as reducing CAN utilization overall, which hopefully will help, but who knows?

Programming

PV Vision Align

Improving on our previous reaction-only vision align command, we tried adding a component that would shift our PID goal based on what the current velocity was, which we thought would give us a not-really-feedforward-but-close-enough-approximation to improve the tracking of the desired gyro heading.

But in testing, we found that “not-really-feedfoward” = very-bad-performance.

We quickly backtracked and added a true feedforward, using current robot velocities to calculate the desired angular velocity at every periodic cycle, which works much better.

(True FF on left, fake on right)

We’re hoping that this will be sufficient for basic shot alignment, as we’re still working on migrating over the oPi + Arducam setup onto the main robot, but we’ll see.

Pivot Control

So it turns out that modeling the voltage necessary to hold the arm stationary against the force generated by gas shocks isn’t the easiest thing to do. The model performed well at low angles, but was obviously wrong at angles close to and past the vertical (the voltage was positive when it should always be negative). For the sake of time, we just ended up using our budget version of REV HC and calling in backup in the form of simple linear regression.

With the two pivot motors in break mode giving us a large margin of error due to static friction, this approximation for how much voltage is needed to keep our arm static has served us quite well so far, although it does mean the arm is difficult to move once the robot is on (RIP drive team people setting up the robot)

After adding on some mostly-theoretical-but-also-half-tuned kV values, a nice eyeballed proportional gain of two, and some motion profiles, our pivot control graph looks like this.

We will take some time to crank up the arm speed later - for now, this is satisfactory.

6 Likes