FRC 4322 Clockwork | 2024 Build Thread | Open Alliance

[AnyaChopra]

Handles

4322 started using handles to lift our robots after ocr 2023. We feel that handles are super important to safely picking up and putting down the robot. Especially since we are constantly bringing our robot to different places due to the lack of a shop space, handles have made robot transportation a lot easier for us. In this post, we will be covering a few of the different ways we have mounted our handles over the past couple years.

MOUNTING

We started off by designing the eye bolts for the handles into the robot/bumpers, but for TOAST, we ended up just hooking them in the pockets on the robot (swerve has really nice pockets for latching handles).

2023 Nemo handles (eye bolts in frame):

2024 CRUSH handles (eye bolts in bumper mounting brackets):

2024 TOAST handles (latched into pocketing in swerve modules and intake gearbox plates):

We use these handles and haven’t had many issues with them over the past couple years. We highly recommend that teams use handles because they make picking up the robot a lot easier and safer

[AnyaChopra]

Leadership

As always, we are open to trying new things with our leadership team and would love suggestions

For the past month, our team took on a new approach to our leadership structure. Here is a look at the structure we used that helped us finish TOAST and get as prepared as we could for our two off-season events.

OLD LEADERSHIP PROCESS (2024 summer-fall):

We used to have a student leadership team composed of a president emeritus, president, vice president, integration manager, and sub-team leads. The sub-team leads we had were design, strategy, electrical, build, outreach, business, and software. We would hold weekly leadership meetings, but due to the slow progress we were making on TOAST, the meetings would often get pushed around and were not consistently on the same day at the same time.

Our leads were picked through an interview process. The president and vice president interviews were open to any interested students and the past president and mentors were invited to come and decide. The past president (myself) was invited despite still being a student for the 2024-2025 season due to our one term presidency rule. The people involved in the interview selection process then decided on a president and invited them to vice president interviews. Once the president and vice president were decided, they were responsible for deciding the sub-team leads along with the mentor for that specific sub-team.

This system overall did not really work out for us because of the lack of experience and inconsistent attendance of subteam leads, resulting in many tasks falling to older students who were more active. Managing subteam task breakdowns and organizing them on the Miro board wasn’t working out and there was no organized Gantt chart with concrete dates to get the robot built in time for our first competition. The younger students chosen to be on the leadership team needed more time to gain experience in their subteams and learn from older students how to manage leadership tasks before taking on the roles themselves. As such, a new leadership structure was developed to reflect those necessities.

NEW LEADERSHIP PROCESS (current):

We cut our leadership team down to 2 students

• President
• Tech Director

The technical director is in charge of managing task assignments for each meeting and sending them out in advance. Students are expected to see their tasks before a meeting and ask questions beforehand to ensure meetings run smoothly and we stay productive. Students are also expected to read Open Alliance posts from our team to see what we have learned and what our robot’s progress is to stay on track.

Again, we do one term presidencies, so our 2023-2024 president was the only student who was ineligible for that role. The past president is still eligible for other roles should they agree to it. For example, I was our 2023-2024 president, so I am ineligible to be president for 2024-2025, but could fill another role, so I became the 2024-2025 technical director.

FUTURE PLANS:

We will be holding supplemental leadership training over the next couple months to train up a new leadership team since our president and tech director are both seniors. This leadership training will focus on how to do leadership specific tasks, like making a TOAST tasks chart to ensure a smooth flow of robot build. We make it known to our students that they do not need to be the best in their sub-team to be the lead, they just need to be able to handle the leadership aspect of it. We want to train up a new president, technical director, business lead, design lead, software lead, and strategy lead.

We will also be focusing on the core areas (business, design, software, and strategy) rather than having a larger leadership team. That being said, there will still be opportunities to participate in other sub-teams, such as outreach and electrical, they just won’t have a lead.

TLDR

• One-term presidency still
• Only president and technical director (temporary)
  • President already served one term, so I am now technical director
• Ran this leadership system for a little over a month

[AnyaChopra]

11/10 Update

CRUSH and TOAST got to meet for the first time

We had 4 students total with 2 staying the whole meeting.

BUILD

• Swerve
  • Decided that we wanted to run the mk4i L2+ ratio again for the 2025 season
    • Same ratio we used for 2024, so we are keeping the modules built and just cleaning them up
    • Still need to decide what wheels we want to run
      • Know we don’t want grip locks again
      • Considering colsons and aluminum wheels with tread
        • Any insights to wheel selection would be greatly appreciated
  • Removed 2 modules from CRUSH (our #neveragain bot) so we could clean everything up

SOFTWARE

• Connected 2 cameras per pi without getting phantom cameras or losing camera configs
  • Step 1: Flashed SD card with fresh install of photonvision
  • Step 2: Inserted SD card into pi along with USBs from cameras
  • Step 3: Powered on robot
  • Step 4: Set team number and enabled strict USB matching
  • Step 5: Set static IP address

We made sure not to power cycle the robot or reboot photonvision before strict USB matching was enabled and saved as a config. Otherwise, we would have to reflash the SD card and do the process again as mentioned by @Vasista

The configs persisted multiple power cycles and reboots. This was done with the default 2024 photonvision install to test out the process on TOAST, and we will be doing the same for the 2025 release.

• Slight issue with one of the cameras where it was showing a black screen on stream and displayed 4ms latency and 0fps
  • Think it’s an issue with the camera JST to USB cable since we swapped the USB extensions and it still didn’t work

TLDR

• Decided to run L2+ mk4i for the 2025 season
  • Wheel type tbd
• Got 2 cameras per pi

LESSONS LEARNED

• There are multiple different gear ratios available for swerve

[AnyaChopra]

EVEN MORE BATTERIES

We got 6 new batteries before tt that need some names! Help us pick a naming scheme for our new batteries

• Pasta shapes
• Ice cream
• Hot sauces
• Sandwiches
• Car brands
• Beaches
• Sesame street characters

[AnyaChopra]

11/13 Update

We finally looked at how many brownouts we had in our last elims match at tt (the one where we climbed with like a minute left because the brown outs were that bad) and it was 271 setting a new 4322 record for this off-season!

We had 3 students for practice at 294’s field

SOFTWARE

The heading of our robot drifts whenever we try to drive it straight without requesting any rotation, and in order to mitigate it we developed “pseudo auto rotate” which locks and maintains a heading while driving.

• Tested pseudo auto rotate
  • Found bug that was causing robot to sometimes spin out of control due to unintentional bounding of gyro angle

ELECTRICAL

• Robot disconnected occasionally when rotating quickly and amping
  • Similar to the disconnects we were getting at 9408 practice a while ago
• Had a “reverse brownout” (regeneration) with our battery voltage
  • Spiked to 15V which we think is due to power regeneration from new CTRE firmware

TLDR

• Fixed pseudo auto rotate bugs
• The disconnects are back

LESSONS LEARNED

• Don’t keep code that doesn’t do anything because it might introduce unintentional bugs
  • Auto-generated CTRE swerve code was causing unintentional bounding of gyro angle

[AnyaChopra]

Even More Battery Names

The chosen battery naming scheme for our 6 new batteries is Sesame Street characters! Help us name our batteries

• Elmo
• Cookie Monster
• Grover
• Rosita
• Abby Cadabby
• Zoe
• Big Bird
• Bert
• Ernie
• Oscar the Grouch
• Mr. Snuffleupagus
• Rocco
• Count von Count
• Baby Bear

[AnyaChopra]

11/15 Update

We had 2 students for practice at 4201’s field.

SOFTWARE

• Tested pseudo auto rotate (solves our issue of the heading of our robot drifting whenever we try to drive it straight without requesting any rotation)
  • All bugs are gone and it works
• Tested 6 note auto
  • Lowering current limits to prevent brownouts resulted in notes not getting picked up fast or shooting fast

When testing our vision odometry, we noticed that driving becomes jittery when tags are slightly off since the vision estimates for robot heading jump around. We are considering changing weights to rely more heavily on gyro and only use vision heading estimates in certain cases: Updating heading when a hard collision detected or when using robot field position is necessary(eg. shooting, passing).

We also noticed that sometimes tag detection flickers in and out due to field elements partially covering a tag. We’re considering adding more vision filtering to smooth out the jumpy pose estimates(eg. Trust tag data less as distance from tag increases)

ELECTRICAL

• Redid the ferrules on our CANivore since it was occasionally giving us red lights for CAN
• Swapped from the open mesh to the vh-109 radio
  • Stopped having disconnects when we did that

Disconnect #1:

6 Note Auto Disconnect #1

Disconnect #2:

6 Note Auto Disconnect #2

TLDR

• Made shots from the wing
• Did our last climb and trap with TOAST

Final Trap:

Toast Final Trap 🫡

• Did some trick shots

Trick shot #1:

Trick shot:)

Trick shot #2:

Trick shot #2:)

• Still having brownouts

As a reminder, we are still voting on our battery names: FRC 4322 Clockwork | 2024 Build Thread | Open Alliance - #346 by AnyaChopra

[JoshuaJ1710]

Could you guys explain the orange pi stack setup? What fan was used? Also, what’s the section on the side of the boards for?

[AnyaChopra]

Attached is an older picture of the pi stack (the orange tape is no longer there and fan power wires are soldered differently). The 3 orange pis are stacked up in the orange section of the picture. The blue is the fan, we used this fan. The green section on the side are the buck converters. The buck converters were recommended in this thread by 6328. Following their advice, we used one buck converter per pi because we heard some teams experienced intense overheating after heavy use of vision processing when they tried using the same buck converter for multiple pis. The one orange pi to one buck converter setup has worked very well for us this off-season with no overheating or reboot due to insufficient power.

In terms of wiring, the diagram on this thread gives a good example of how you can use USB-C to power the orange pis. Since our pi case has the USB-C port right up against the left side of the case in the picture with no hole for accessibility, we opted for direct soldering power wires from the buck converter to the 5V and GND GPIO pins on the orange pi. Additionally, we didn’t want to take up 3 MPM slots just for the pi stack, so we spliced the buck converter wires together to only take up one slot. The fan is powered by soldering the power wires to 5V and GND on the bottom of the top pi because the pins on top were used to connect to the buck converter.

[JoshuaJ1710]

Thank you so much!!

[thatmattguy]

We’ve started adding more wiring examples to our new quick start guide — if there’s anything y’all learned from running multiple coprocessors, would love to incorporate that into the docs for everyone to learn from!

[AnyaChopra]

CAD Navigation for the Build Team

We mainly did this training using the Roti and TOAST cad docs since the CRUSH cad has a lot of errors. We switched to the CRUSH cad at the end to go over exporting and working on a shared doc with other people (if someone moves something or hides something, the part moves/is hidden for everyone).

We had 9 students at this training (2 presenting and 7 attending). We had all our students share their screens so we could make sure everyone was following along.

CAD SKILLS

We understand that not all of our students want to CAD, but we still need our build students to be able to navigate the CAD model. We had 2 of our students hold this training to show our build students some of the basics of CAD navigation to ensure we correctly manufacture and assemble parts in 2025.

• Panning around/zooming in and out of the CAD
  • Zooms in/out where the cursor is hovering over (in this example, we are hovering over the bolt and scrolling forward and backward with the mouse wheel)

• Measuring part lengths
  • Face to face

• Grabbing along an edge

• Turning on dark mode (very important)
  • All of our students now have their onshape in dark mode

• Part labeling systems based on CAD names
  • Color coded folders with sticky note labels that go in the parts bin for its respective sub-system to ensure we do not lose parts and can easily see what we have manufactured
    • Note has the part name in CAD, length/part description, and quantity

• How to hide and bring back the instances and mates list
  • When showing someone something in the CAD, hide it so there is more room to look at the part(s) on the screen

• Hiding parts/hide other instances to get one part alone

• Isolate parts to look at something alone
  • Hiding transparent parts to get rid of the outlines of other parts

• Searching for part names

• Using “j” to hide mates and “k” to hide mate connectors if there are any shown

  • Before “jk”:
  • After “jk”:

• Show all instances to bring back parts without the mates/mate connectors

• How to hide entire subsystem (click the eye icon)

• How to open and close the drop downs in the CAD

• How to find part materials and quantities with the BOM
  • Move/remove/add columns

• How to export parts and title them for printing
  • Add the qty in the file name

• How to follow someone in Onshape (see where they are in the CAD model to help with design reviews)
  • Double click their icon

FUTURE DESIGN/CAD/BUILD TRAINING

Moving forward, we are having our students individually go through https://www.frcdesign.org/ for design training. We are having all of our students go through this material before the season starts. For students who do not want to CAD, they are still required to make it through the design aspects of the website to understand how parts work. If students have questions, they will ask them in our design chat, or we will hold online meetings to do reviews. Students can also look at the 3847 design explorations videos (Spectrum 3847 | Build Blog 2024 - #558 by AllenGregoryIV) if they are interested in looking deeper into robot designs.

Students who are interested in CADing for the 2025 season are also responsible for following the frc design learning course and asking questions in the CAD chat.

For build, we will have a couple of our students pick objects that our students need to create prototypes for. We want our students to get used to rapidly prototyping using the materials we have laying around.

We hope that all of these trainings will help us reach our goal of #neveragain for the 2025 season!

[Pizzatc]

What would you guys say is your biggest challenge when it comes to CAD and Design?

[AnyaChopra]

We don’t really have one big challenge, it’s more of a bunch of things that add up. Here are some of our issues and ways we are trying to solve them for 2025:

• Lack of design review
  • This past season, students briefly went over our designs with mentors, but didn’t have them fully inspected by multiple mentors
    • Intakes V2, V3, and V4 were not even design reviewed, we just sent it because we were super short on people and time
  • Potential Solution: Having people on other teams do design reviews for us
    • Gives us a fresh perspective to catch potential issues we might had overlooked
    • We are super open to anyone from any team that wants to review for us
  • Potential Solution: Having more routine reviews throughout the season
    • Makes us rethink our decisions more often and potentially figure out a more optimal solution
• Lack of students who understand design/cad (we have like 1.5 students who understand CAD and design)
  • Makes us slower at finishing our design/cad, which slows down all our other sub-teams
  • A lot of work for not a lot of student(s)
    • Us 1.5 students are also involved in other sub-teams, so we end up getting needed in multiple places at once when things go wrong, which slows us down since we can’t be fixing a build issue and tweaking the design
  • Potential Solution: We are trying to use frcdesign to teach our students CAD and design for the season. We have tried doing our own training and the 3005 training in the past, but it didn’t work out as well as we hoped
• Lack of students who consistently attended meetings
  • Slows down our design team because we are constantly trying to catch people up to speed so parts get manufactured/built correctly
    • Tried to fix this by having our students follow our build thread when they miss a meeting to see where we are at, but we still have students who don’t understand things and don’t ask us questions
• Integration with other sub-teams
  • Our CAD students worked with our prototyping groups (we also were from the prototyping groups which made this easier), but our software and mechanical did not communicate well this past season
    • For example, at port h we had a climber that was built and wired, but it had no code because there was a lack of integration between our sub-teams
  • Other sub-teams just didn’t fully understand the design when working on the robot, so we had parts manufactured incorrectly and other little delays that really hurt us during the season (again, goes back to more routine design reviews and a lack of consistency in students showing up)
    • Build kids don’t understand the order that parts need to be assembled in from the design (lack of communication with design and build as well as a lack of understanding of CAD/design from our build students)
      • We now have sheets like our TOAST tasks - Google Sheets that we will be having our design team make for build
        • Also had the training the other day to hopefully ensure that is not an issue for 2025
  • Potential Solution: Created a tech director role to oversee all of our sub-team integration integration
• Organization in the cad docs
  • Cad gets really messy really fast and gets harder to follow
    • Ties back to us not having many students because we all get super focused on just fixing the errors and finishing the design that we don’t have time to go back and clean everything up
  • Don’t have a set naming scheme for our parts, so it gets confusing later on during manufacturing (for example, some of our spacers were named with their length, others were called things like “stupid spacer”, and others were just left as “part xx”)
    
  • Potential solution: we are working on figuring out a naming scheme we like for our parts by looking at what other teams like 6328 do
• Slow WiFi and computers
  • Constantly waiting for Onshape to load when we were working on CAD at our old shop
    • If you made a mistake and had to go back, you were waiting for at least a solid 10 minutes sometimes. When it finally loaded, you would need to wait a while for it to process the change you made. It would take us like an hour to do something that should take 5-10 minutes
• Lack of home to CAD/design
  • Pretty self explanatory, we still don’t have a shop or any leads on a shop, so we can’t work together in-person on design stuff as much as we would like
• Slow build/manufacturing
  • Since our build/manufacturing is not the fastest, our design team doesn’t have a lot of time to rework designs to make them work better

[Pizzatc]

@AnyaChopra

Organization in the cad docs

• Cad gets really messy really fast and gets harder to follow
  • Ties back to us not having many students because we all get super focused on just fixing the errors and finishing the design that we don’t have time to go back and clean everything up

You have no idea how much this drives me nuts within my team and my college rocketry club lol.

The main problem we have has to do with speed of trying to get the CAD done and also trying to create a fast loading document. The biggest complaint from our other CAD students (while I was student in 2023) was that it took forever to load because I had all the parts on 1 document)

My advice and what i’m trying to implement this upcoming season is to follow 5940/8033’s onshape model for file organization because I like their technique with master sketches and then using derive to keep the stress from being on 1 document.

As for naming. Lots I teams I know use the following protcol

Team#-year-A/P/M-(Assembly#)(Part#)
P: Part
A: Assembly
M: Master Sketch

Example
4322-2025-P-0101

Main Assembly should be A-00

@AnyaChopra

Lack of design review

I would say post here as well, i’m sure there is plently of people who be happy to give you feedback

@AnyaChopra

Slow WiFi and computers

Honestly I would ask your CAD students once you have enough data from prototyping to do pretty much all the CAD at home and maybe just arrange zoom meetings if you need them to talk to each over. I got 90% of the CAD(in 2023) done at home where I had a ethernet connection

[ditty]

@AnyaChopra

Organization in the cad docs

• Cad gets really messy really fast and gets harder to follow
  • Ties back to us not having many students because we all get super focused on just fixing the errors and finishing the design that we don’t have time to go back and clean everything up
• Don’t have a set naming scheme for our parts, so it gets confusing later on during manufacturing (for example, some of our spacers were named with their length, others were called things like “stupid spacer”, and others were just left as “part xx”)

Here’s what our team does to name and organize our onshape projects and the parts within:
BOM_CAD Organization Guide.pdf (2.3 MB)

[AnyaChopra]

A little more about the fan, this configuration runs the fan at max speed all the time. Some people connect the fan to 3.3V power to reduce the speed, but we went with 5V because we are cooling 3 pis with one fan. It is possible to connect the fan power to a PWM output and write a script to control the speed using the onboard temperature sensor. We haven’t experimented with this because it isn’t accurate if the vision processing load is less on the pi controlling the fan speed. We had numerous issues during integration that required running some pis with only a single camera or even no cameras at all while we were troubleshooting.

A better way to reduce power consumption is to only enable vision processing at the start of a match and during field calibration. Having vision running the whole time since power up results in a noticeable drop in battery voltage by the start of the match. We found this to be acceptable, but we may experiment with adding control over when vision runs for next year to save battery so we can run higher current limits on our motors.

[AnyaChopra]

CRUSH: A Blessing in Disguise

How we got from this:

To this:

For some context, our 2024 main season robot, CRUSH (named after the turtle from Finding Nemo), wasn’t our finest creation… We had a rough year, but we still had a lot of valuable learning opportunities that we would like to share for others to learn from.

• Ensure there is clearance for wires when designing
• Add enough clearance to the battery mount to be able to line it with something soft/squishy
• Don’t use 3d printed gears for high torque applications like mechanism pivots

• Back polycarb plates with a sheet of 1/16th inch aluminum to help with the cracking or mechanisms
  • If in a pinch at events, lollipop it

• Don’t use materials you did not prototype with on the robot (polybelt)

• Maximize in-person meeting time (at home tasks happen at home)
  • Test/tune instead of writing code
  • Build instead of cadding

• Just use standardized spacers when building
  • Less printer time needed to print unnecessary parts
    • More time can be spent on parts that need to be custom printed

• Do as much work as possible before the season starts
  • Test drivebase code and vision odometry
• Don’t overcomplicate parts (funnels)

• There’s a balance between trying to write beautiful code versus something that just works (state machines)
  • Don’t fix what isn’t broken
• If something just isn’t working, don’t get too stuck up on it because it probably isn’t worth your time/resources
  • The intake didn’t work, so we ended up intaking through the outtake
    • For AVR, we got the intake working for autos (4 note) and we got it working for auto and teleop for champs
    • Gave up on it for cvr because we needed to do what was going to help us for avr

• Put motors that move in a separate CANbus (intake feeder motors)
  • Less likely for them to get snagged and for the CANbus to go down

#neveragain

[Indiebot]

In addition to using the correct mechanism for deployment, make sure any jack shaft is properly supported to prevent issues with bending, in this case we only supported it with a single bearing on each side through 1/8" tubing… … Had we referenced the image below from FRCDesign.org we would have (hopefully) avoided that issue entirely.