Roughly Smooth: Week 4

Starting to ramp up production as parts, materials, and drawings start to arrive.
The real robot is going to take form soon!

Week 4, known to many teams as - the slump. Most of the work we can dole out has been completed, and we're spending a few days seemingly waiting. Design is finalizing and wrapping up, stock and parts orders are in transit, and hopefully soon a new flurry of activity can begin again. For Bearcats, Week 4 was also test week! All team members had to take the 2024 Crescendo rules test to make sure they could perform job functions effectively, such as being a drive team member or a scout.

Software continued running the robot in a larger space in the school where we had a lesser chance of running into things. Pathplanner is a nice tool for building autonomous paths, and we were trying to get a feel for how to use it. Tuning stuff is an interesting process, try a number, see how it behaves, try a new number, see if it's better or worse, and hopefully arrive at a point that you're generally happy with. Last year we had quite a time suggesting to our programming folks that Shuffleboard is a great tool. Rather than changing a value, re-deploying code, and testing, Shuffleboard would let us change values on the fly, cutting 30-45 seconds off each attempted variable change. In a 3-hour team meeting, that's a lot more testing that can happen.

This year, we're using a lot more libraries, YAGSL, Pathplanner, Lean protection (that's an inside joke that got outside...) I encouraged the students to build a Shuffleboard panel to help tune faster. They started writing code to post and fetch values, then together we looked at how to put it together. And wouldn't you know it, both movement libraries use different mechanisms to subvert our intentions. YAGSL reads PID values from a JSON file in its class definitions. Either re-write the whole class creation, or deal with re-deploying JSON files. Blegh. Pathplanner does accept a PIDConstants value when it's created! And then internally stores them in an immutable structure. Zero for two. So, with time taken away trying to optimize, we were back to the process of change-deploy-change-deploy. At least we got moving forward again. Hopefully forward...

We updated some parts on the robot cart.
Snazzy!

After a few runs, I asked what I thought was a silly question - Does the robot drive backwards sometimes? Why yes, it does. But we're tuning PID values right now was the response from the team. Now, I'm not a rocket scientist myself, but I was skeptical that PID tuning would have an impact on the robot driving in the intended direction. Indeed, after several more runs, the robot would still drive backwards sometimes. Once again I stepped in and encouraged re-looking at the YAGSL documentation, the Pathplanner setpoints, rotation targets, etc. Later in the day a great question was asked - why aren't we tuning PID, what are we trying to fix?

Awesome! Let's bring everyone onto the same page. We need the robot to be predictable, then controllable. Start with a macro view, then work downward with precision. As a start - we need to know that when we set a robot on the field for autonomous, it will always drive in the expected direction. Once we guarantee all the configuration and motor direction and path direction, then we can use tuning to smooth out the paths, and start increasing the speed. Once again the week flew by (and I've been spending more time with software, if it's not apparent), so we'll have to tackle this giant next week.

Yet another set of intake plates!
We'll definitely break last years record of 3.
Wait, we already have...

Design had a nice punch list after our external design review, and quickly turned that feedback into iteration in the CAD. At this point we were confident in freezing some aspects of our design. But not the intake. After playing with the v2 intake last week, we had some ideas for improvement, and this week were able to cut new side plates on our fancy wood lazer cutter that now look more CAD-ish, rather than blocks of wood with strategically placed bearing holes. Even while cutting those plates, we designed yet another version of the intake. Even without testing our v3 mechanism, we looked at just how far we could maximize certain trade-offs for a potential v4.

With certain items frozen in design and more testing happening on the intake, climbing is the last challenge. We have talked climbing before, but now we had time and a resource to start putting real content into CAD. Back in 2022 the team bought some climbers in a box, but were unable to get them assembled and installed on that years robot. Yay us! 2 climbers in a box, here at the shop. Known quantity solution to one of the games problems - why yes, we will steal from ourselves. But nothing is ever entirely free - climbing mechanisms have to be robust in their connections to the robot, in order to hold the weight of the robot! This week was spent analyzing how best we could mount a climbing mechanism, and how to reinforce structure on the load paths we identified.

Parts drop! Packaging science is fascinating,
how all these parts came in a single slender box...

By the end of the week, our fabrication was able to start churning out parts! We started getting some orders in for chain parts, hex and tube stock, and the purchased gearboxes. Also at the end of the week, our in-house baby waterjet died. (Again. Coach loves this thing. Broke in the middle of last build season. We ran some test parts on it a week ago and were happy with its performance. We actually get ready to run real parts on it and kaboom, Marvin Martian finally gets what he's been hoping for after all these years... Dear Santa - Omio? Please?) We scrambled to put together a contact list - sponsors and friendly local teams who might be able to help us get sheet metal parts cut, otherwise, we would have to get really creative to cut out some of these shapes...

Real robot parts!
Hand-made (with love) in Monroe, WA

The progress we could make was good though - our MAX planetary gearboxes came together with little issue, reductions ordered largest to smallest outward from the motor. We started getting some tubes cut down and hole patterns added. This is yet another slow process due to an already constrained design team - parts may be finished in CAD, but we can't just magic them into existence. Drawings are needed for each part. As our manufacturing is still mostly manual, we print 1:1 drawings of hole patterns to be used as templates for our parts. We glue these print-outs onto the material, then use a center punch and a drill press to (as best we can) correctly line up and cut out the required patterns. This year with our new Tormach, we attempted using some hand-programmed CNC logic to make the process more accurate. Install a tube, find the 0 position, space holes 0.5" apart, drill, rinse, repeat for the ~14" of usable travel on the machine deck. With our drill press and Tormach, we could produce a simply staggering 2 tubes in parallel.