Week 2 - Progression

Busy days in the shop, preparing electronics, CAD and part libraries,
software plugging away in the far background...

As we arrived in Week 2, the team were in high spirits. We had rocked our Week 1 goals, had a clear concept to design in sight, were <this> close to handing a drivebase to the software team, and had our plans for the next prototype. Our Week 2 goals loomed, so we had to stay focused and progress with our plans. Week 2 involved filling out the robot sketches and crayola CAD as real, functional, produce-or-purchase-able components, getting our swerve chassis powered and driving with 2024 code, and starting to order all our needed metal stock, bearings, intake wheels and etc so we can build this thing!

Our 'put stuff together' team has been rockin' it this year. We got the chassis together, velcro-ed electronics, and on day 10 of build season, software got wheels spinning on our brand new competition chassis. Awesome. Double high-fives all around!

As life seeks balance with all things however, we soon ran into some control issues with the swerve library we chose to work with. While working through debugging, we learned that we missed a step of Loctite-609-ing the encoder magnets on the swerve modules. And the very small but important cherry on top where we hadn't greased the gears on the swerve modules yet either. So close, yet so far. 

Software ran the robot a few more times (with very low maximum speeds) to get a better hang on the swerve library. Even without the absolute encoder offsets, we watched and watched as the wheels spun and rotated, jumping positions back and forth, and never homing to the motor 0 position. We read the documentation. We took the example values for a square chassis with SDS MK4i modules and NEO motors. We inverted the gyro readings (in case that was doing anything?). We read the documentation again. SDS MK4i - invert the drive motors but not the steering motors. Set this compensation value for NEO encoders and wheel diameters. Pull hair out. Do we just not understand the library? (Is this a common trend?) Just for kicks invert one of the steering motors. ZWHOMP PFFFfff. The one wheel drove directly to 0 (did not pass Start and did not collect $200) and stopped. Faces were made. We inverted the remaining motors. ZWHMOP PFFFffff (times four). All 4 wheels spun and halted, each finding 0 as quickly as we allowed them. Thanks documentation. (Should we send an email to YAGSL about that?) But hey, progress was made! The library, now that our configuration was correct, allowed us to code and run the robot, but also contained a simulation mode that would allow us to tune and "see" what the robot was doing, even if we didn't have a robot!

Robot rules: no touching carpet until we have bumpers!
But, wheels spinning on our brand new chassis in 10 days!

Outside the robot and the code, we made progress on other small but needed items for the season. Our cart that we'll use to ferry the robot around has sliders so we can position supports to fit different sized robots. Ours is now set up for this years chassis. With the Amp mockup finished, we looked to building a speaker mock-up. We looked at Open Alliance and the blog of FRC3847 Spectrum with their PVC tube speaker opening, and figured that would suffice for our needs.

Steal from the best, invent the rest!
Another team showed how we could build a simple
lightweight Speaker mock-up with PVC

From our robot design, one item we had not validated from prototype testing was our intake, which would be pretty important! As we had found a new concept late last week, we started looking into another prototype for our intake to make sure everything packaged, powered, and behaved as expected to meet our robot needs. We are not the fastest at producing prototypes, but we are able to produce some higher fidelity items as needed. Some quick CAD sketches turned into drawings turned into lazers cutting sheets of wood. This happened later in Week 2, so we haven't fully played around with it yet.

More great assembling happening, constantly checking and referencing the CAD.

Why do I keep putting design last? Next week Design is going first. That'll show me!

The robot design has been shaping up nicely. I think we're in the "slump" now. folks are here, and we're messing around with as much as we can, but the majority of time is in the 'hurry up and wait' period for the design team. We ended last week with 2 concepts, after reviewing our goals, Robot-in-3-days videos, Open Alliance videos, kitbot, etc. We got feedback and input from the team on which direction we should take, and the final decision from the designers was... merge the best parts of both designs. They were similar enough that it was possible, and the final outcome looks very simple, contains three degrees of freedom, and should be constructable with our equipment and facilities.

Both concepts were pretty far along as we reviewed and made our decision, so even early in the week, the conversion from sketches and crayola cad into real components happened very quickly. To align with the schedule, and keep hands busy, we opted to look at each component linearly, starting with the structure on the chassis, the components and movements attached to the structure, and so-on outward and upward. As/if we finished a component, we could logically call it 'done' (yay! we finished!), but also start parallelizing such as gathering the required items to purchase or materials to order.

The longest conversations of this week were about our rotating joints. We have a few of them (well, at most 3 as per comments above...). In crayola CAD, its really easy to place a rotating mate onto 2 object and show how the conceptual item moves. Defining the actual geometry, power transmission, specific torque, transferred torque, parts capture, packaging, etc requires a bit more effort.

Geometry and packaging might be easiest - how do we feed the power transmission in the roughly defined space? Power transmission is all about what type of propulsor we are using, and how that energy gets enacted to move our component. For us that meant a place to locate and mount a motor, and how to physically get the power from the motor to the mechanism - also for us that meant chains and sprockets.

Then we get into the specific torque - we are rotating an object about an axis, that object has length, mass, and a range of angles. How much torque do we need to apply to get this mechanism to move, and how quickly will it move? Do we add a second motor? What gear ratio do we use on the chain so that we can accurately rotate the given load to a position in a given timeframe?

And we're back to our robot goals! If we want X cycles during a match, each cycle must be Y seconds, and each action within a cycle has some timing criteria to meet! Great! Once we've got our gear ratios, now how do we affix the sprockets to both the motor and the appendage such that they will remain rigid through the forces being exerted on them? We like to draw load paths on our parts - torque enters here, goes through this bolt into this plate which is connected to this plate, etc. (Hard to visualize without a sad Bearcat blocking out an image of a whiteboard, I know...)

We're still not quite done - we have an axis of rotation which is also a part in CAD. We've defined how it rotates, but we need to ensure it is captured correctly - what moves or slides on the axle? How quickly? What doesn't move? How do we retain the axle between it's mounting plates? Well that took all day and a half. Now do all those same steps for the next rotating joint, with it's own unique requirements! But actually we still aren't done, so, hold your horses, and please don't throw your laptop out the window. (You know who!)

I'm going to say this was also a bit fun for me, as two joints we have are very different and solved very differently. One joint was a dead-axle - the axle fixed in place and the main component rotates around it... uh, let's call it "slowly". We were more concerned with the lever arm and weight, so we're planning on beefy bushings to help rotate the component around the axle, while basically bolting the ends of the axle into the mounting plates to capture it. A second mechanism is a lot lighter and smaller, and just might extend outside our frame perimeter (like, maybe...), so we want it to move a little quicker, on a smaller shaft. For this application we're mounting a live axle on ball bearings and affixing the axle to the intake - I mean the sneaky component. We're also not using chain on this application, so, yeah both of the mechanisms described had to have similar processes for design, but ended up with very different solutions. All great stuff if you ask me!

Big boss keeping us all focused and aware of the schedule.
Time is one of the most difficult resources to manage during the season.

Now that we've finished holding on, one final step (I wonder how many final steps we actually have...) is adding hardware into the CAD and checking and re-checking everything for clearance. If this rotates, will it smack into the bolt that's holding the thing together in the first place? It's nice to find that out early, so we can pack plenty of bolts.

QotW:

Mentor 2: "Is it simple? Does it meet requirements? THEN STOP DESIGNING!"