Day 27, 28, 29

As CAD reviews push to close and our current final versions are prepared, we get into the fun game of parts ordering! Step one of parts ordering: check the lab. Found it? Great! Didn't find it? Did you check the other tote over there? Did you check the refrigerator? Great! Still no luck? Then we'll have to order it. We use a single, color coded spreadsheet to identify what parts, part numbers, quantities, priories, subsystems and more are ordered, shipped, or arrived. Our robots are comprised of so many parts, this one spreadsheet helps with a small part of that overall tracking.

I also gave some students an introduction (or refresher) crash course on FRC pneumatics. My 15 productive minutes for the day are done. (Ugh, and I left my frisbee at home today...)

Supply Chains

The FRC monster is a hungry monster. Anyone who has dealt with parts ordering during build season knows what I'm describing. Come January, FRC team purchases drain suppliers of common core parts. Some items (game pieces, electronics) go out of stock the day they are released. The numbers are staggering. There are over 2500 teams in the US. If half of them use chain for their drivetrains, and the average robot is 30 inches long, teams will be purchasing over 175,000 inches of chain. Let alone teams that build multiple robots. If each of those robots is 6 wheel drive, that's 7,500 wheels, 7,500 sprockets, 5,000 motors, 20,000 bearings, and that's just drive trains. What if every team built a 2-stage elevator with roller bearings? 2500 teams, each building an elevator using 40 roller bearings would require 100,000 bearings from suppliers. Again, these numbers are assumptions based on teams consuming only what they need for one robot.

In 2017, North America produced 17.4 million vehicles. Each containing 2-7 seats, 4-6 wheels (6 for the large dually trucks), bearings, axles, lights, electronics, plastics, metals, and so much more. Supply chain management and logistics in itself employs thousands of people. Car companies use forecasting to determine their supply needs. They have deals in place for parts to arrive early and/or just in time for production. (Or late, because sometimes plants catch fire...) Several FRC teams look at common items (electronics and bearings) and pre-purchase those items in the fall before the start of build season. They save (some) in-season headache, and save a LOT of money on shipping. (Seriously, we spend thousands of dollars each year on shipping alone. It all adds up.) Teams should identify common parts they use and re-use every year, and plan to order during the off-season. Parts on hand can mean the difference between a complete robot, and multiple days with idle subsystems. (Though, that would allow more time for dodgeball.)

Design Heavy Year

Lessons from 2015 and 2016 are coming back to haunt us. Designs change. A change here creates a new change there. The details become a focal point, trying to find every ounce of performance from a model made of pixels. Mentors and veterans poking holes and comparing trade-offs. Looking at history and similar designs to predict failures. The internet semi-assures us that we are not the only ones. (It is properly good to know we're not alone wallowing in our misery :-) ) Each subsystem is making forward progress, and we are at a point where our next bottleneck will quickly form as a line of CAM reviews and router operations. To keep machine availability high, we also have our lead engineering mentor review each CAM file before it gets run. (Yet more running around for him!) Good news for us right now is each review slowly closes the gap in integration issues. And, day 27, late at night, we have our CAD final rolling chassis up and running. It's good watching our drivers finally get their hands on a new frame. (Until they hit the wall. Multiple times.)

Why is this year and 2015 specifically coming to haunt us? 2015 CyberKnights... didn't quite know what we were doing. However, 2015 was a very strategic game. You could build near identical robots, but if one of them was better optimized and handled one stack more, or even, could throw one more tote after their last stack, that would make the difference. This years game seems very similar. We are looking to build a robot to match and (hopefully... there's a lot of hope in this post isn't there...) beat a highly efficient robot on the other side of the field. This means that every decision we make, every game piece manipulator has been looked at and breathed on by a great number of people. Can we use this new feature or mechanism to more efficiently or more accurately guarantee acquisition? Does it reduce our cycle time? (Does it come in black and red?) Inevitably, we find a new idea, venture into the geometry and attempt to see a physical form constructed from plywood. These past few days have been more about the finer details than full-on design changes. When we plan to intake a game piece, we ensure that once we touch it, we own it. The geometry should work such that our alignment or offset angle can be as large as possible, while still ensuring we collect. Once we touch an element, we never lose contact. If we have multiple grabbers, rollers, wheels, we are always contacting a game piece at some point along the intake path. We store the element as much as possible within the frame. A defensive robot can't knock the element out of our grasp. When we manipulate the game element (rotate or translate) we have sensor feedback so we know precisely where it is or how far we moved. When we score an element, we completely release it. We won't have any jams or mis-placements. We are able to accommodate as large a variance as possible, and still guarantee successful placement. We plan to have software optimizations, so that both our intake and expel sequences happen as fast as possible by the mechanism. It feels like we are waiting a long time for design, and its true that we are. It feels like a constant spiral of idea -> analyze -> prototype -> find failures -> modify or step back to a new idea -> on and on. (Like cup noodles, the spiral is real. And like cup noodles, there will come a time when the noodles are done cooking and they are ready to eat!)

That CyberKnight Attention to Detail

We all make mistakes during build, and some of them are just plain wonderful. Our software student accidentally created a single-sided terminating PID. It would bring an arm up to a given position, if you pushed down it would fight to return back up, but if you pushed further up it free-floated. Kinda fun to play with.

Our first chassis assembly had a minor mis-hap during its assembly. We are using the Toughbox gearboxes, and a third stage on the output connecting to the driven wheel shaft. The gears are... different, and if not communicated or instructed well, they can be assembled backwards. One might then have a robot geared at over 40 feet per second. Your driver will try to drive, and the bot will slloooowwwwlllyyy creep forward. Then gain some speed. Then very quickly it will crash into a wall. That was fun. A quick swap, some reassembly required, and our bot was back to driving along at normal speeds, with actual, measurable acceleration. But hey, a >40 ft/s robot was fun to play with!

CyberKnight Team Update: