Achieving Consistency

[Ginger Power]

The biggest difference between good and great robots is consistency. My question is how do you build a consistent robot? Are some mechanisms always superior to others? Taking last year's game as an example, Texas had a bunch of amazing catapults while California and Canada had a bunch of incredible wheeled shooters.

Does it just come down the number of iterations of a design? The more tweaking, and fine tuning, the more consistency... What is the best way to go about this fine tuning? Is it possible to make an inferior mechanical design superior with enough programming loops?

During your game analysis/initial design brainstorming, how does consistency factor vs. other design elements?

My team has lacked consistency in scoring game elements in every year of its existence. We've managed to do pretty well in spite of that through strategic creativity, but it's definitely time to take the next step as a program. How do you achieve the consistency needed to be the number 1 alliance captain or first pick at an event?

[Tom Line]

Robustness. One breakdown can and will cost you an event. Which means you need to drive your robot before you bag it. Teams that consistently do well in early season events are the ones that practice driving and find the large bugs in their robot before they get to the first event.

Focus. If you're fighting with some mechanism at the competition and can't seem to get it working - stop. Just don't use it. For instance, we fought with our climber for most of states. As a result, we were always rushing and small things were missed. This hurt our overall performance significantly.

Routine. In everything you do. Have one or two people who always pack the trailer. One or two people who always handle the driver station. One or two people who always do the batteries. When other folks get 'helpful' and try to do things, they get missed or messed up. Stick to your jobs. When everyone performs you'll do well.

Checklists. What must be done before the robot leaves the pits. What must be done when the robot it placed on the field. When should the robot be powered up.

Delegate. Everyone should have their job before they get to the competition. Sorting things out once you get there is difficult.

Verify. One person should be making sure that everyone else gets their responsibilities done.

To summarize: Plan.

[cadandcookies]

GOFIRST regularly has engineers or other professionals come in and speak to our group for our general meetings, and today we had an engineer from Boston Scientific who gave an excellent presentation focusing on this exactly (his day job is designing pacemakers and other implanted medical devices). He had a few things which I think are particularly applicable to competitive robots:

1: Understand when reliability is needed, and what the acceptable threshold for reliability is.

He related this back to developing consumer versus "mission critical" equipment, but I think it's particularly relevant in the context of robotics where 100% often isn't actually feasible for a variety of reasons. If failure isn't a huge time sink, designing something that can do the thing multiple times very quickly might actually be a better option than trying to design something that is 100% reliable (and inevitably failing).

2: Fundamental simplicity is better than any level of complexity.

His example for this was a manufacturer who had a laser device for which the lens changed its focal length between operating temperatures (-20 to 100 degrees celsius). The solution that worked best wasn't adding thermal sensors and a control loop, but making the stand out of a material with similar thermal expansion properties as the lens, which automatically kept it at the right length. On robots, this is sometimes more difficult to catch, but think of some of the most famous/well designed robots out there-- like 1114's Simbot SS, which have a fundamental simplicity and functionality to them.

3: Understand modes of failure and alleviate or plan for them.

Often in FRC this means building a part more robustly or more intelligently, or bringing back ups. It also might mean using COTS parts and building in the design to easily remove and replace critical subsystems. I believe Nemesis (2590) has designed robots for which the drive rails are replaceable, which may be an example of this.

There's my small digression, but next up is my personal opinion from someone who has only designed one subsystem that I consider to have been 100% reliable during competition (2220's 2014 drive train). So take it with a grain of salt since I am definitely not the most qualified person on here to be speaking on this subject.

I think Tom hit on the core of it with his last point: consistency is about planning. Not just planning in the general sense, but knowing what can and should be planned for. Sure, a complete failure to plan can ruin your day, but so can putting too much time and effort into planning/designing for things to go wrong when the most effective solution might be to cut your time and make an extra plate or part. And ultimately that knowledge comes from being willing to learn from your experiences.

[RoboChair]

Originally Posted by Ginger Power

Does it just come down the number of iterations of a design? The more tweaking, and fine tuning, the more consistency... What is the best way to go about this fine tuning?

The robot is never done, there is always something to improve. Keep tweaking until it's better and understand why it is better, then redesign and implement. Simplify your systems as far as you can. Accept nothing less than 100% reliability, then making it faster.

I don't even want to talk about how many can grabbers we built in 2015. /shudder But that is the reason not a single team ever beat us in a can race at champs, we made the fastest triggering, highest accelerating, reliable grabbers by spending MONTHS reworking them. We could have gone faster but decided to stick with building a robot and not a cleverly disguised lethal booby trap.

[jwfoss]

Pneumatics. In all seriousness the repeatable force and defined retracted and extended positions allow your robots mechanisms to be where you want them. Giving up full range of motion simplifies not only design, but software control as well.

Additionally, using the field to your advantage to score can eliminate variables and increase consistency and accuracy. See ramp camping in 2006, fender shooting in 2012, shooting from contacting the pyramid or wall in 2013, team 254 2014 etc...

[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".

[Tom Line]

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!

We build a second robot. Our cad team is usually 4 or 5 students and a mentor. We have a build calendar that we've honed over time, but in reality there has never been a year that we follow it to a T. Every team needs a mentor who has a grasp of everything that is going on with the robot and knows when to break process and take a shortcut, or when to call it quits on a mechanism that showed promise but is proving problematic. That program lead mentor is the difference in a lot of good teams.