Day 8, 9, 10

Day 10 already, almost 1/4 through the season. I hope you're all working hard and making progress! There are certain days when we leave the lab we'll look at the students, the other mentors, give a solid head nod and say, "Yep. That was a good day." We won't talk about the other days.

Schedule, Redux

Last call for new ideas! Well, maybe not last last, the season is fluid, go with the flow, but don't lose your balance. Saturday we updated our robot requirements document, adding a few more lower priority items that we found through our strategic planning (more on that later). At this point, we have not yet built any physical prototypes (because we're bad at them). We have used CAD extensively to verify geometry, integration, and more. We are still behind, but still within sight of where we want to be. We will catch up without cutting corners. Take it slow, slow is smooth, smooth is fast. (Someone out there on Chief Delphi forums had the signature: If you can't find time to do it right, how will you find time to do it again?. I like their signature.) We are making final decisions for our chassis. Except when we spring a last-minute robot requirement on them, and ask if it affects them. (Yes, yes it does.) It's okay, Saturday is a long day, and a few hours later we are again making final decisions for our chassis. They'll stick this time. Our additional teams are making forward progress as well, communication is flowing. Certain chassis dimensions have been solidified, so we have a place to mount a mechanism. This mechanism moves and may interfere with another mechanism. The two leads talk and define usable volumes in space. We have a space for all our mechanisms, we have a space for our battery and electrical. We didn't forget anything. Wait, who's doing bumpers? (Fortunately, our chassis team does have toggle clamps in CAD already. We will pass bumper inspection first try this year.)
Saturday evening, we held our complete robot concept review. We listed our robot requirements (*current* robot requirements). Each subsystem lead described their system, where it fits on the robot, how its powered, any caveats or gotchas, etc. The whole team then verifies that the system meets the requirements, is operationally competent, and is mechanically competent. Once all the subsystems were described, we looked over the robot as a whole. Does it meet our requirements, is it what we <expected> to see? Will this robot play the game we want to play? Our team goal for the robot this year is to return to Einstein. Will this robot (and drive team) bring us there? All yes's? Then let's move forward and build this thing!

Strategic Planning

Each week, team updates get released, other teams post blogs, test videos, our strategically minded students and mentors craft new plans and ideas for where and how to score points. Point densities are discovered (how many points per second), ordered structures of which elements to score when are generated, and we try to constantly feed this information back into our robot design. Autonomous - er - Sandstorm and endgame are heavily scrutinized. Permutations, point densities, and better-best cases analyzed. How does our robot fit into each scenario. If we contributed this score, would we win all our matches? Would we be a good pick for the top alliance? If we don't look great in this scenario, can we alter our robot requirements to better meet this scenario? Does that completely screw up our other robot priorities? Saturday we came up with some new robot requirements that fortunately were added as lower priority, but nonetheless added to the already taxed minds of our design leads. Always fun to spring things on our chassis team.

Motor and Air Budgets

Time is a limited resource. Game elements are a limited resource. Stored energy on the robot is a limited resource. One battery, one compressor, some fixed number of air storage tanks. Around this time, both for regulation and on-board budget reasons, we start counting motors and pneumatics. Due to Power Distribution Panel physical limitations, we can use 16 motors (we almost exclusively use CIMs and 775 Pros). The battery can supply a limited amount of power, and the more we draw on it, the less is available for each component asking. We write out the max and usage load of each motor, what their use cycles will be, and what the max instantaneous draw of the robot would be. (During a match, what is the highest draw we would expect to see if we were driving, and collecting a game piece, and rotating the shooter, and ...) For pneumatics, we add the air volume for each cylinder and attempt to identify the number of use cycles per piston per game. We are okay with budgeting a run time for the compressor (which is another motor!), but we want enough stored air to be able to feed all of our mechanisms without loss of working pressure. It's also important to mount air tanks in pairs to keep symmetry, which improves the look of the robot. Its very important to keep the robot looking good. (While there is sarcasm here, there is also evidence to support the claim that simple items that look good, perform well. I stole this claim for Formula 1. Go Mercedes!) Having our motor and air budget ensures that we understand our power draw, and will have sufficient energy (air or chemical) to run the robot at its maximum designed limits.

How we pick our wheel tread:

Ian: <sniffs tread> Smells like vanilla.