Bad luck, or poor execution?

[nitneylion452]

You decide!

The Philadelphia regional ended today (congrats to all teams!) and I will start by saying that there was an extremely high level of competition and an almost omnipresent aura of Gracious Professionalism.

Now on to the main point of my thread. My team (3167 Environmental Tectonics Crusaders) fielded a robot, as one would expect. When we arrived, the robot had no pneumatics, which was planned. We spent hours adding all of the necessary components to our robot to make it work and pass inspection. It ended up being over-weight (which we knew and had a half decent plan for) and too long (though our measurements begged to differ). We had to remove our minibot deployment system and cut the frame down by 6.5" all in day 1 just to pass inspection.

Once we had all of that done (13 hours of work later) we were very excited for the start of the qualifying round. We had very high expectations for this year because our robot was a great deal more sophisticated this year. Our first match didn't go well and we did not score a tube. The main reason for this was that our driving seemed to be very off, our drivers would twist left and the robot would rotate right. We attempted to fix this, but with no success (we believe that the issue was our encoders, one on each wheel, were "arguing" with each other, but we didn't think of this until it was too late).

Without going in to much more detail, our robot managed to score no tubes. We had several chances, but various things were wrong, such as the tower did not go high enough to score the tube, and the tube bouncing onto the scoring peg, and bouncing back off (which I didn't see happen to anyone else, and needless to say, I was quite disappointed).

I don't want this to be misconstrued as a "woe is me" type thread. I honestly want you all to ask questions about out operations, offer feedback, and, for the teams that were at this event, comment on what you saw from my team. I'm looking for constructive criticism.

Thanks in advance for all of your feedback!

P.S. For those of you at Philly, I was the coach for 3167, in case I met any of you and neither of us are aware of it!

EDIT:

In particular, I want to give a big shout out to team 3553 who made it to the second (or third?) round of the eliminations! I was very excited to see that robot play the game and you played wonderful defense. The design was genius, and I really enjoyed seeing your bot in action.

[VKP]

The most effective way to improve your robot (as our team has found) is to build a second robot to practice with between ship day and the competition. Our team worked out a lot of kinks and other problems with our practice robot which we otherwise would have had to deal with at the competition.

I strongly suggest you guys do this next year. It helped us tremendously (we are now using our practice robot to practice with a new roller claw we build for the championships!)

[nitneylion452]

We actually did build a practice robot; however, it was not ready until Monday, i.e. two days before the competition. This was due in part to all of the new sensors we were using. Plus, there were some minor differences between our competition bot and practice bot.

[Chexposito]

the sooner you get a rolling chassis of the type of drivetrain you want to use, the more time the programmers have to work on code. try to make sure you get your final robot done as soon as possible, then immediately start building your second as close as possible. that way on ship day, they can transfer to the practice easily and keep working on code. usually they are running the robot to it's limits, so problems with the design or manufacture are found in your shop instead of at competition. most teams experienced teams use the 30 lb. withholding allowance to their benefit, so whatever you fix you can build the fix and bring it with you. safety inspection is important to make sure your ship robot will pass. reading the robot section of the game manual can help with most of these problems. as for not reaching the top peg, testing on with game field elements that are somewhat accurate or really close is key.

so pretty much test, test, test and when you're done with that test some more.

[DonRotolo]

A team needs to consider what they are really capable of. If your second robot wasn't ready until several weeks after the first one was built, perhaps you "bit off more than you could chew". As a suggestion, consider a simpler robot next year, and focus on robust and 'done early'. That will set you up for future years of excellence.

[BigJ]

From a control systems perspective, I'd suggest an iterative and segmented approach. Make sure base functionality is working, then integrate sensors as you go. We try to provide a way to "cut out" the sensor code, so that if it still isn't working, or started not working, and we need to queue for a match, it takes little more than a few seconds and a redeploy to have the robot is a correctly working state.

Here's an example:

1675 has 2 major control elements this year: Mecanum drive and our lift system.

Our rough development schedule through the year was as follows:

1. Mecanum drive working correctly
2. Lift operable using manual up/down controls
3. Lift maximum limit switch operational
4. Encoder on lift drum shaft, used for preset positions
5. Automated scoring procedure using lift and claw with encoder once tube is snagged on peg (this is where we are now, and will be implemented on Wednesday at CMP)
6. Drive encoders for more precise control (doubt we will have time enough to put them on and test)

(There was minibot stuff too, but just flipping a few servos.)

We use C++, so each of the above past number 3 have alternate functions that can be used to revert to proven, mostly reliable alternatives. Class constructors are defined for the components of our robot to be used with or without sensors, and a simple change to a line at the top of our main robot file switches what sensor groups will and will not be used.

[Tristan Lall]

Originally Posted by nitneylion452

It ended up being over-weight (which we knew and had a half decent plan for) and too long (though our measurements begged to differ). We had to remove our minibot deployment system and cut the frame down by 6.5" all in day 1 just to pass inspection.

I just want to verify something: you cut 6.5 in off, but surely that wasn't the difference between your measurement and the measurement taken at inspection? By how much did the inspector say the robot was oversized? (And was this controversial, or obvious from way it didn't fit in the sizing box?)

As far as lessons go, that's one that can't be emphasized enough. The size limits are limits. There's not supposed to be any positive tolerance, so teams should design whatever tolerance they need into the robot. (Make it an inch undersized in all dimensions, for example.)

[nitneylion452]

Originally Posted by Tristan Lall

I just want to verify something: you cut 6.5 in off, but surely that wasn't the difference between your measurement and the measurement taken at inspection? By how much did the inspector say the robot was oversized? (And was this controversial, or obvious from way it didn't fit in the sizing box?)

As far as lessons go, that's one that can't be emphasized enough. The size limits are limits. There's not supposed to be any positive tolerance, so teams should design whatever tolerance they need into the robot. (Make it an inch undersized in all dimensions, for example.)

We cut off 6.5" because of the weight issue. When we went for inspection, we were a hair too long, probably no more than .25". We measured our robot afterwards and our measurements indicated that the robot was 38" long. We measured the size of the box (with the inspectors' permission, of course) and found that is was 37.875".

As for your parenthetical question, some of our team members were pretty upset and tried to "fudge it" and make the robot fit, but as the rules and past experience tell us, there's no two ways about it. If the robot doesn't fit, it's too big. And that's what I told my team.

[nitneylion452]

Originally Posted by DonRotolo

A team needs to consider what they are really capable of. If your second robot wasn't ready until several weeks after the first one was built, perhaps you "bit off more than you could chew". As a suggestion, consider a simpler robot next year, and focus on robust and 'done early'. That will set you up for future years of excellence.

The physical building of the practice robot was actually finished maybe 3 or 4 days after ship. We had wanted to add "just a few more sensors" to the robot. These included IR distance sensors and encoders. Our programmers worked frantically to get the code working, but so many things kept not working correctly that the process was dragged out over the course of a few weeks.

The entire process was made more difficult because our practice area was not in the same building as our workshop. We are located in the basement of a building behind our school and our practice area was on the school gym stage. Most of the programmers' tests needed the full size replica to be accurate, so in order for us to test the code, we had to bring the robot, tools, and various other items over to the practice area, which was about a half hour process.

I don't want to sound like I'm making excuses, I just want to provide some insight about our situation.

Thanks again for all of the feedback!

[IKE]

Originally Posted by nitneylion452

... we were very excited for the start of the qualifying round. We had very high expectations for this year because our robot was a great deal more sophisticated this year.

Higher levels of sophistication frequently require higher levels of execution. For a young team to be able to do this, they need:
Experienced mentors
A lot of help from an experienced team
A fall test bed for those added sophistications (experience)
A second robot to work out all the bugs (experience)

My advice would be to continue to work on those robots over the next year, and compete at some off-season events. This will give you the experience you need in order to be able to pull off a "more sophisticated" robot. Notice I took the "great deal" part out.

Also, if you get the chance, check out 1503s robot this year, and all of the 330 robots. In my opinion, 330 year after year achieves a design elegance above most of the competition. They build successful robots that are just complicated enough to be great. I don't think it is a coincidence that the year they got particularly complicated (2009) was not their best performance.

In Michigan this year, a couple of the most successful young teams built fairly simple clean designs that were robust and extremely effective (2137 and 2054). 2054 was such an elegant solution for this game, that many respected mentors I know had a ton of praise for this team. I don't know what 2054s program is like, but I do know that 2137 did a lot of off-season events last year to improve their robot and team. This additional effort is akin to lifting weights in the off-season for football. It really paid dividends this year as they are one of the best teams out there.

[Vermeulen]

My opinion is that you probably used too many sensors that you didn't exactly need. Now, I don't know what your team used these sensors for, or if you actually needed them, but from your post earlier, you said that the reason you couldn't debug and test is that people wanted "just a few more sensors". If I were in your situation, I would put on only the sensors you actually needed. (If needed, I would scrap autonomous in favor of scoring during teleop).

[gren737]

I too will echo the sentiments of you might have bit off more than you can chew.

When I give my rookie or intro to FIRST seminars I try to emphasize that teams need to build within their capabilities and maximize what those capabilities are vs. trying to keep up with the Jonses (or in FRC the Thunderchickens).

Practice robots are not for figuring out the design, they are for driver practice and learning where the weak points of design are prior to competition.

In the off-season, preferrably just before the start of the season try making a list of your teams capabilities. Mentors, machining, facilities, budget, student experience (did you graduate alot of seniors last year?) etc. Then determine the best way to utilize those resources with your robot. You can make good decisions and trade offs with those three, no machining but large budget, buy vs. make. Etc.

The main goal of the lesson is, a simpler robot that works well will be much more competitive than a really complicated robot that never works, or doesn't all work at once.

I'll throw out a great example. In 2009 I started a rookie team w/Greg Needel. We had a good sized budget, 2 experienced mentors, NO machining, no programming capabilities and no experienced students at all. We built quite possibly the simplest robot ever. No sensors, 5 motors, that was it. We were the #3 pick at our regional end ended up as finalists (losing to 16 and 71) and won Rookie All Star. At champs we were picked by 1717 (we made the book!) and were Finalists at Champs loosing to 111 who won it all that year. Our robot was very simple, very effective and built by students with no experience in a agriculture shop with a chop saw and drill press. The principal of KISS cannot be overstated enough. It really works. Not to mention that robot never broke down during the season either.

Another big tip, design and build your robot at least .5" smaller than max on all sides you will never miss it, and if you need to have that random bolt head sticking out, you've got room for it without going over.

Oh yeah, and the reason I know all this?? Because we've ALL made these mistakes! The good teams will learn from them and move forward, not repeating the same mistakes twice. Keep doing that over a period of 10 years and see where you end up. I promise it will be a fun journey. You do need to continuously challenge your kids and your team, but small steps each year, building on things you mastered in the previous year is better than an all at once approach.

[MrForbes]

Originally Posted by nitneylion452

When we went for inspection, we were a hair too long, probably no more than .25". We measured our robot afterwards and our measurements indicated that the robot was 38" long. We measured the size of the box (with the inspectors' permission, of course) and found that is was 37.875".

Our rookie year, someone on our team figured out to make the robot an inch smaller on each side than the max allowed. This was a very smart move, because the robot "grew" almost an inch on each side as it was built. We've always made the robot chassis 26" x 36" since then. In 2008 we discovered that the sizing box is not necessarily level, square, or plumb, and since then we've made the top of the robot at least an inch smaller than the chassis on each side.

Experience...you can't buy it, you might be able to get some for free by reading CD a lot, but usually you have to earn it, and it's not always fun.

[OZ_341]

We are not that far away from you guys if you would like to visit our school. We could sit down and go through our design process and organizational structure.
We do have engineering mentors, but we build our entire machine each year in a high school wood shop with a minimum of welding and complex machining.
Success can be attained with a minimum of resources, through careful planning and even more careful execution.

Please send me a PM and we can meet some time in May.

[PriyankP]

Originally Posted by nitneylion452

our driving seemed to be very off, our drivers would twist left and the robot would rotate right. We attempted to fix this, but with no success (we believe that the issue was our encoders, one on each wheel, were "arguing" with each other, but we didn't think of this until it was too late).

If something like this happens and you don't know where the problem was or how to fix it, the quickest solution would be to get rid of the encoder code all together. Encoders improve the base control, but they're not a must have sensors!

Similar thing happened to 188 last year. We had meccanum base and we had encoders on all four pods. The encoder code that we had was written using the practice robot and it worked beautifully until we got to our first regional. The encoder code didn't work on the competition robot. We spent about 3-4 hours trying to fix it with no luck, eventually we decided to get rid of the code and it turned out that as long as the battery was fully charged, the base would go straight.

Anyways, in short, sensors are great but you should always have code that doesn't depend on sensors. This year we had two versions of the code, one that uses sensors for better control and one that uses no sensors (skeleton code). Always learn from past mistakes. I have a feeling you guys won't have a similar problem next year.

My $0.02.