Achieving Consistency

[OccamzRazor]

A lot of the things I have to say have been said but I can add a few. Most people overlook a couple of things such as combining designs to simplify your robot design. A lot of people this year combined their shooter and intake mechanism into one assembly which I thought was one of the better designs.

Simple machines have less failure points and better durability. I tried to convince my students to redesign our shooter/ intake into a single pivoting mechanism but they were married to what we had for whatever reason. But hey, we are a student led team so that is their machine and their decision.

One thing I try to push out to my students is that the robot is never complete and it can always be better. We don't have a 6 week build season. If you attend more than one event and you didn't win your first, change your machine using your allowable part limit of 30 lbs. That is 1/4 of your machine!

Design new parts for your machine in CAD (if you don't use cad, start) and plan to replace anything that does not work. If something does not work, don't try to use it during competition and remove it from your machine as useless weight. Use a practice robot chassis running or not to test these new designs since your robot will be in the bag. For regional participants this is more challenging but district model teams have their 6 hour time between events to implement.

Just like Karthik's presentation stated and one of the cleanest ways to state it I think: Chase perfection and achieve excellence along the way.

[Jay O'Donnell]

I've seen a lot of great points about the robot, but another important point is that you need as much driver practice as you can get. The driving and scoring motions should become natural to your drivers so they almost don't have to think about what buttons they're pushing.

[Trying to Help]

Great thread! Achieving consistency is going to be a huge topic for our team this season.

I love all the terrific responses. My question is then, how did you implement these processes? Did you build a second robot? How big is your CAD sub-team? How did you decide to allocate time for the design, build, test iteration?

Thank you!

[OccamzRazor]

Originally Posted by Trying to Help

Great thread! Achieving consistency is going to be a huge topic for our team this season.

I love all the terrific responses. My question is then, how did you implement these processes? Did you build a second robot? How big is your CAD sub-team? How did you decide to allocate time for the design, build, test iteration?

Thank you!

For us, we had two students using CAD but there was a huge choking point in our progress last season with only two people creating the content for the entire mechanical team. This season we trained the majority of our mechanical students in CAD making them more responsible for their own ideas and iterative designs. I hope we turn over designs and ideas more quickly this way because we can fail things out that will not work much faster.

[adciv]

Tolerances: Don't design a Jaguar, design a Ford Pickup. You don't want your robot to only work when perfectly tuned and everything is just so. You want it to be able to tolerate as much variation as possible. This variation can come from game elements, field location, or degradation of the robot over the season.

Margin: Don't build to peak performance, always have margin for when things degrade. Electrically, your battery will drop below 12V and this will impact your motors. Pneumatics wise, you may get something in your air flow that restrict it slightly.

Parts that Break: The earlier you find out a part is going to break, the better. This year the programming team was shearing rivets on our intake (we WERE being careful). We got it changed to bolts for the season (drive team is not as gentle as we are). Related item, make sure you know what will break and use this to your advantage. If you have the choice in your design between an easy to replace part breaking or a hard to replace part, ensure the easy to replace part breaks first (sacrificial component) and just build several of them. We had some small pieces of metal used for lifting the portcullis and they broke ~10 times during the season due to impacts with the walls.

Automation: Some designs you can control with PID (or similar). Some designs you can't. If you can have it controlled by software, you'll get more repeatability than by a player. In 2014 we had two different ways of pneumatic catapulting a ball (complaints on pneumatics aside). One pulsed the pneumatics for ~125ms (milliseconds) and the other fired into a hard stop. Both used software and the timing made it so our driver hit one of two buttons based on where he was on the field to score. He couldn't have done these reliably under manual control.

[RoboChair]

Originally Posted by adciv

You don't want your robot to only work when perfectly tuned and everything is just so. You want it to be able to tolerate as much variation as possible. This variation can come from game elements, field location, or degradation of the robot over the season.

This. DO NOT BABY YOUR ROBOT! Do not drive it gently in practice. Do not place game pieces perfectly for your robot to intake in practice. Practice with everything in the worst possible scenarios you can throw at your drivers, make them chase those game pieces because that is what the game will be like. Take bigger risks in practice to find the limits of your performance and durability, then try to improve the robot to make it easier for your drivers to do their job. Remember that every single second counts and needs to be spent wisely.

[Chris is me]

General advice: Fail faster. Iterate like crazy, identify design weak points and fix them (either literally weak as in structure, or as in "the speed of the intake is the limiting factor in our scoring speed"). Spend an extensive amount of time prototyping and tuning variables to match desired performance goals rather than just proving the concept. Strategize well. Compromise on the right part of the design, not the wrong parts that make it easy.

[Jeremy Germita]

Great tips in this thread. I'm a fan of "fail early, fail often". It's definitely something we've been practicing this offseason.

At the event: Do a FULL systems check and inspection of your robot. This helps us identify potential issues early enough to fix them for our next match. Also, avoid fielding untested changes by doing a full systems check after ANY change, software or hardware. Even the smallest change may have unexpected effects on robot functionality.

Minimize(ideally eliminate) the number of changes to driver-facing controls at the event. This ensures that your drivers' inputs will produce the same outputs match to match.

[GaryVoshol]

Be careful what you wish for, because you may get it.

I recall an FLL team that won an award, with consistency being one of the judges' high comments. The kids were greatly pleased to win an award, but one mentor was heard to say, away from the kids, "What, consistently mediocre?"

Granted, you want what you can do to be consistent, rather than haphazard. Doing one thing well consistently is better than doing 3 things inconsistently, only sometimes achieving the results you want. But I would say consistency is only one of the criteria needed to become a "great team".

[adciv]

Originally Posted by GaryVoshol

Granted, you want what you can do to be consistent, rather than haphazard. Doing one thing well consistently is better than doing 3 things inconsistently, only sometimes achieving the results you want. But I would say consistency is only one of the criteria needed to become a "great team".

I can agree consistency is only part of being a great team, but from an engineering design standpoint consistency is the first thing you need. Edward Deming taught manufacturers to drive variation out of the system. Only once you do that can you truly control where you are at and drive the system to where you want it to be. If you're inconsistent, you can't say if something worked because it works or if it was just a one time event.

[JVN]

1 - Full function prototypes.
You don't need to do this for everything, just the stuff you want to work.

2 - Hundreds of hours of consistency testing and tweaking.
The 148 unveil video from this season showcased our method of "us putting balls through the catapult until we didn't hate it".

[PayneTrain]

Originally Posted by adciv

I can agree consistency is only part of being a great team, but from an engineering design standpoint consistency is the first thing you need. Edward Deming taught manufacturers to drive variation out of the system. Only once you do that can you truly control where you are at and drive the system to where you want it to be. If you're inconsistent, you can't say if something worked because it works or if it was just a one time event.

Getting the process that can help breed consistency on your team is just like learning how to walk before you can run. You're almost never getting anywhere with an inconsistent robot. You're getting somewhere when you hit a consistent walking pace. Figure out how to add complexity without sacrificing your consistency? You're running laps around everyone else.

Build up some good, old-fashioned hate for your robot when you first start working on it. Try to break everything! We built our drivetrain in a week and spent the rest of the season running it over defenses trying to break it (we couldn't). Hold your core functions (driving, primary scoring acquisition, and primary scoring delivery are usually the core functions of a competitive robot) to incredibly high standards. Accept you will never get them perfect, but never hesitate at investigating any possible changes. As a team hones the ability to master these core functions, you can add complexity to these and other functions and create a stratospheric machine (I hope).

[saikiranra]

Originally Posted by PayneTrain

Build up some good, old-fashioned hate for your robot when you first start working on it.

I would go even further and say always hate your robot. Keep breaking, iterating, and trying to figure out how to change the robot from week one of build season to champs.

[Steven Smith]

Doing a little research on 4607, I’ll note that you aren’t in too different position than 3005 was ~1-2 years ago. Arguably, we have a ways to go before claiming consistency, but here are the things I think mattered most for our success this last season.

#1: Starting with a solid strategy. If you design a great robot to do the wrong thing, or commit to building “too much robot” and sacrifice time to tune, practice, iterate, you are taking a high risk / high reward approach. I’d argue that a team that is consistently successful is more likely to grow and improve. Define what consistent success looks like for your team, perhaps always make elims at a regional, or trying to be a “picker” vs. a “pickee”, or always making it to champs, or anything else.

#2: Put in the time, but make sure the time is meaningful. The best teams aren’t magic, their combination of hard work and design efficiency allows them to do in a few days what some teams need 6 weeks to do. This goes into later points, but you need to enter the build season with as many people as possible trained to contribute in some meaningful way. That doesn’t mean every student/mentor needs to be a CAD expert, or a machining expert, or scouting expert. Robot seasons are made up of a million important tasks, from designing the most complex mechanism to tapping the millionth hole. Try to delegate in a way that uses each person most efficiently. As an example, our students are still building confidence in their ability to prototype independently. A known bottleneck is having enough people in Week 1 & 2 to efficiently and effectively evaluate a breadth of options. Identify bottlenecks and address them.

#3: Have a plan and be willing to make tough decisions regarding schedule. There is likely not a single magic design I would trade to make me willing to go into the first regional with zero driving practice or runtime on a robot.

#4: Design in CAD / Practice Robot: This can be dependent on machining skills, CNC availability, finance, other resources. However, under the bag/tag rules (correct or not), there is a huge advantage to the additional iteration time that is afforded with a practice bot. For this to be effective though, your construction needs to be repeatable enough such that your iterated designs can be transferred to your bagged robot with a high probability of working.

#5: Sweat the small stuff. If you want to be a top 5 robot at a regional, it’s very hard to do if you lose more than 2-3 matches. Start by figuring out why you are losing matches. It’s easy to think, well if my robot could score 10 more points I could beat X, Y, Z team, it’s a robot design issue. If this was 2015 and every match you scored exactly the same amount of points, that could very well be the case. However, I can’t tell you how many matches we’ve lost in my history due to… faulty battery, leaking pneumatics, bolt working its way loose, part breaking without a spare, etc. All the points about pit checklists, getting students to take ownership of the details (battery management, spares creation, etc) can be considered low hanging fruit when compared to designing a better robot.

#6 Robot Mechanical Design: Yes, there are certain designs that are just more prone to consistency than others. I agree with much that is said about simplicity. As an additional preference, even at the sacrifice of simplicity, I’ll point to 2015 and our decision to not have an active intake. Our elevator/arms interface with the tote was only effective when we were lined up ~+/- 5 degrees with the tote, and we lacked any way to effectively center it. Any time your robot can actively engage a gamepiece and pull it into a known position before taking the next action, it is likely worth it. Same thing with methods to clamp a ball before shooting (in case you are bumped), as well as other game piece movement issues.

#7 Robot Electrical Design: Learn how to properly wire robots, use high quality connectors/wire, properly strain relieve wires, etc. Electrical issues are a pain to troubleshoot, stop them at the source.

[PayneTrain]

Originally Posted by saikiranra

I would go even further and say always hate your robot. Keep breaking, iterating, and trying to figure out how to change the robot from week one of build season to champs.

Exactly. It's good to not get too invested at the beginning, but I would guarantee you that there are probably fewer than a dozen robots ever built at the powerhouse level that didn't have some obnoxious quirk or "what if" scenario attached to them by the teams that built them.