Finding problems too late

So yesterday and today we struggled with our robot driving incorrectly and were extremely frustrated because of all the trouble we spent making it work. It was really upsetting because all the systems worked except the drive. We were using mecanum wheels, and I made certain when I put them on that they were in the X configuration.

So after alliances had already been picked, we stripped down the robot to see what the problem was, and it turns out the mecanums had been repositioned at one time into the diamond configuration. At the time it was really annoying, but now I’m having a good laugh about it. :rolleyes:

I was just wondering if anyone else has stories of discovering problems too late, because it’s nice to share silly mistakes and to learn from them.

The one story I can pull from our team was, during one of the Saturday qualification matches, it turns out our drivers didn’t set the bumper in right. On the way to the field, the pins to keep it in feel out on various locations on the field, and we seemed to not notice until ten seconds in and our bumpers are at a 45 degree angle relative to the robot. I was watching from the stands…confused.

Needless to say, our bumpers were screwed in after that match xD

Last year at utc we were on the top alliance going into eliminations and all of a sudden our autonomous stopped turning on and that stopped teleop from turning on most matches. we made it to the semis but with such a huge disadvantage we couldn’t get the win.

It turns out our code timer wasn’t syncing with the field and we couldn’t move.

We once spent 5 hours debugging code before noticing the Digital Sidecar was not connected to power. Surprisingly, it still works, only wrong.

Oddly enough, we had exactly that problem with mecanum wheels this year. They were all labeled properly, but somehow someone had managed to switch them around. It was a frustrating programming switcharoo obnoxious time trying to debug the code and figure out why nothing was quite working right and then it was ‘oh, change those out’ and everything worked fine.

Remember how this works:

Mechanical blames electrical.
Electrical blames programming.
Programming blames mechanical.


Could you please explain what that means?

Thank you.


Actually the best time that happened ever for me was
Pneumatics blames Programming
Programming blames Electrical
Electrical blames Pneumatics
Pneumatics goes “uhh”

2nd to last day before ship the programmers FINALLY get their hands on the robot and start trying to drive stuff, balance motors, set constants, etc. During that time I notice the v89 of the jaguar firmware and update them all (of course under the time pressure of everyone else). Once everything got setup we start getting an intermittent signal to the jags through the CAN bus. I immediately take the blame for it and have to spend the next hour tinkering with the system until I get called for the driver test. During the part where you have to drive without being able to see the bot I think about how easier this would be if I had the live camera feed, and then a “lightbulb moment” hits me. I promptly run across the school back to the robotics area and remove all references to the camera, and suddenly everything works! Turns out the frame for the camera was built so that it would always push the reset button on the camera :stuck_out_tongue:

Every time haha.

In 2007 our robot was about 4" over the size limit when extended out. So we spent the entire day Thursday hacking away at our robot. Friday we came in and our robot went on the fritz, literally. It ran into the side posts, ran circles, freaked out. Bent our ball forks (4 mentors 5 students to bend them out). Ended up metal shavings got into our controller and slowly fried it. We didn’t realize until the end of the day.

Mechanical blamed electrical, electrical blamed programming, programming freaked out, turns out it was mechanical leading to failure of electrical making programming go crazy.

It’s a little over my head since i was an engineer and the driver. As our programmer explained it to me we had a timer that made sure that we broke out of autonomous and our gyros didn’t keep us running autonomous into teleop. Autonomous would start before or after the timer was initiated and it caused things not to turn on. Thats basically all I know about the matter it was some weird stuff.

Does your programmer hang out on Chief Delphi? If so, could you ask him to post some more detail? We’re experiencing some strange issues in autonomous and perhaps there might be some clues here.



He does on occasion but I’ll make sure he sends you a pm in the next couple days with full detail.

Ha ha we have the same system on our team, except programming isn’t allowed to blame mechanical, so we blame admin.

On our team:
Mechanical blames programming.
Programming blames electrical.
Electrical blames the newbies.


Yesterday at our last qualification match at Silicon Valley the robot wouldn’t respond at all and just sat there all match. Afterward we powered it on in the pit and everything worked. We’ll never know for sure what went wrong, but the most likely explanation seems to be that we didn’t plug in the ethernet cable to the radio.

It didn’t help either that in our second to last match we were flipped during autonomous and were upside down for the rest of the match. Not really an impressive show for the top 8 to want to pick us. Heh…

The Friday before ship we were literally flipping our robot over on its side – letting it fall as hard as it would – and then using the righter to right itself, checking to make sure everything still worked, fixing the things that didn’t, and then doing it again.

And again.

And again.

That’s when we discovered that if our robot tips over fast enough, she automatically rights herself after bouncing the lifter off the floor… Which was really cool. We called it a feature!

On a side note, there has been an inside joke on our team that should, IMO, be spread across the FIRST community. The idea is as follows:

In all robot code – not just ours, but all robots from the coolest of automobile assemblers to the humblest of photocopiers – there is a subroutine that we call ‘Secret Subroutine C’. You cannot delete it, and you cannot in any way remove it, even by reformatting everything and starting over. The best you can hope to do is minimize (not prevent) the chances of it executing, and minimize the damage caused when it executes. It reads only one line, and roughly translated from machine code into English, it reads:

“Run amok and destroy your masters.”

Truer words were never spoken

Oh, that happened to us once :P. One of our matches we lost connection to the cypress. I switched the controls over to the compatible mode to show our drivers what they could do if the cypress board failed again, and then I switched it back into cypress mode. I didn’t realize the last guy hadn’t disabled the bot, and that when the cypress is gone all of the inputs go high, so when I switched it all of the controls defaulted to on and suddenly our kicker starts spinning at full speed, the winch starts running, and the pneumatics to raise our arm activate. I disable it before the arm actually gets enough pressure to raise (something that can be very dangerous if you’ve seen our bot), but the mentors are instantly questioning me about how it could all activate on it’s own. It takes a while for me to explain how I know the exact reason for it.

Oh, also when we were queuing for a match one of our guys bled the air from the pneumatics (I have no idea why) and forgot to close the valve. We spent that match mostly crippled, since our arm needs pneumatics, our kicker needs pneumatics as well, and all we can do is drive around. We promptly put a nice big sign next to the valve that says “close me”. Next match? We forget to unwind our winch before the match and our arm gets stuck.

You mean like when we were sitting on the floor of the hotel hallway Friday night eating pizza, and we started giving the driver a hard time because the robot was moving like it was under the control of a drunk driver about half the time, and his response was “it would help if when I turned the joystick to the left, the robot turned to the left instead of the right…” (We were using a 3-axis joystick, and turning the stick was supposed to turn the robot). We all looked at the programmer, whose only response was “oops” and then he disapeared to his room to fix the code.