Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Achieving Consistency (http://www.chiefdelphi.com/forums/showthread.php?t=151850)

Bluman56 12-10-2016 15:59

Re: Achieving Consistency
 
Quote:

Originally Posted by Tom Line (Post 1611512)
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.

Can you speak more on which responsibilities are given to the program lead mentor other than watching development and calling off progress on a mechanism? This is an interesting role that I never really see being talked about and would like to know more in depth about its proper usage.

Jeremy Germita 12-10-2016 16:05

Re: Achieving Consistency
 
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 12-10-2016 16:25

Re: Achieving Consistency
 
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?" :rolleyes:

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 12-10-2016 17:16

Re: Achieving Consistency
 
Quote:

Originally Posted by GaryVoshol (Post 1611518)
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 12-10-2016 20:39

Re: Achieving Consistency
 
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 12-10-2016 21:03

Re: Achieving Consistency
 
Quote:

Originally Posted by adciv (Post 1611524)
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 12-10-2016 22:33

Re: Achieving Consistency
 
Quote:

Originally Posted by PayneTrain (Post 1611559)
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 13-10-2016 01:35

Re: Achieving Consistency
 
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 13-10-2016 07:52

Re: Achieving Consistency
 
Quote:

Originally Posted by saikiranra (Post 1611569)
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.

Chris is me 13-10-2016 09:59

Re: Achieving Consistency
 
Quote:

Originally Posted by PayneTrain (Post 1611597)
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.

If memory serves, I've heard only one time in my life someone from a powerhouse team say "I don't think we'd do anything differently if we had to do it again". I heard someone from 2056 say this at IRI in 2012.

2056 is the most consistent team in the world. They're the definition of excellence. Any designer that doesn't hate SOME aspect of their robot, unless they are on 2056's level, is blinded by ego. Be constantly vigilant for flaws and imperfections, and be bold enough to iterate past them and fix them. If at some point you or your team burns out and can't justify continuing to improve the robot, it's okay to make the tradeoff between excellence and survival, but figure out how to avoid that scenario in the next year.

Ringo5tarr 13-10-2016 10:10

Re: Achieving Consistency
 
While 1764 had an issue with breaking down, I wasn't a big part of mechanical or the drive train, so I couldn't throw in my two cents on that.
What I CAN have a part in is the discussion on have consistency scoring, specifically with high goals, as we also had an issue with that, but to an extent that we're going to try to fix by our offseason event. ALWAYS USE SENSORS, this may seem like an obvious statement, but the failure to properly wire and mount ultrasonics, limit switches, and encoders drastically decreased our ability to shoot. the more sensors you can have (within feasible parameters), the better off you are, if you can do camera tracking AND an ultrasonic rangefinder along with a predictable arc for your boulder (meaning either a catapult or a wheeled shooter+encoder), you could probably wreck at comp.
If this is common knowledge to everyone else then sorry, but my team had an issue with it so I though I would bring it up for teams in similar situations.

wireties 13-10-2016 10:18

Re: Achieving Consistency
 
This thread has many great recommendations. Underlying most of them is that good teams are careful planners. We have a saying (albeit a common one) - plan the work then work the plan. Map out time for driver practice, tuning, iterative design and inter-competition improvement. The planning does little good without enforcement. The enforcer can be a group of student leaders or the lead mentor, whatever works for your team. Watch your money, your weight, your progress on key mechanisms, progress towards awards planning milestones - watch it all and do it every day.

BrendanB 13-10-2016 10:44

Re: Achieving Consistency
 
Know your comfort zone.

Don't get me wrong, trying something new is a great way to learn and this year we tried a lot of new things on our 2016 robot.

Something we agreed we wouldn't try was a wheeled shooter knowing we had had limited success with them in the past. While it eliminated a lot of winning robot concepts it allowed us to focus our efforts on mechanisms we knew we could make far more consistent than a wheeled shooter with foam balls.

RoboChair 13-10-2016 11:42

Re: Achieving Consistency
 
Quote:

Originally Posted by BrendanB (Post 1611635)
Something we agreed we wouldn't try was a wheeled shooter knowing we had had limited success with them in the past. While it eliminated a lot of winning robot concepts it allowed us to focus our efforts on mechanisms we knew we could make far more consistent than wheeled shooter with foam balls.

This right here is EXACTLY why we always try to prototype some robot mechanisms in the offseason that we have never tried before. We remembered the 2012 game balls and knew that they could be shot well with a good wheeled shooter and we have had a lot of experience with them, so for stronghold we ran a wheeled shooter(the wheel you choose makes a huge difference btw, it depends on the game piece). However you should always expand your knowledge base whenever possible. Take design risk when they don't matter so much. In 2014 we did an elevator,which we used the last 2 robots. In 2015 we did an articulated arm, which we used this last year. For this year we are doing both a turret and a pneumatic catapult.

Build what you know!

Steal from the best, invent the rest! Then take notes, record your results and put it in the cloud.

philso 13-10-2016 11:54

Re: Achieving Consistency
 
Quote:

Originally Posted by RoboChair (Post 1611645)
This right here is EXACTLY why we always try to prototype some robot mechanisms in the offseason that we have never tried before. We remembered the 2012 game balls and knew that they could be shot well with a good wheeled shooter and we have had a lot of experience with them, so for stronghold we ran a wheeled shooter(the wheel you choose makes a huge difference btw, it depends on the game piece). However you should always expand your knowledge base whenever possible. Take design risk when they don't matter so much. In 2014 we did an elevator,which we used the last 2 robots. In 2015 we did an articulated arm, which we used this last year. For this year we are doing both a turret and a pneumatic catapult.

Build what you know!

Steal from the best, invent the rest! Then take notes, record your results and put it in the cloud.

A team will retain the lessons learned much more if they keep some sort of records of what worked, what didn't work and why. Students and mentors come and go, taking the experience they gain, personally, with them.


All times are GMT -5. The time now is 14:37.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi