Finding problems too late

[jblay]

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.

[Nadav Zingerman]

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

[pfreivald]

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.

[Radical Pi]

Originally Posted by pfreivald

Remember how this works:

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

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

[cooker52]

Originally Posted by pfreivald

Remember how this works:

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

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.

[cpeister]

Originally Posted by pfreivald

Remember how this works:

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

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

[Al3+]

Originally Posted by pfreivald

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.

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

Yeah.

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

[pfreivald]

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

[Radical Pi]

Originally Posted by pfreivald

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

Oh, that happened to us once . 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.

[kjolana1124]

Originally Posted by pfreivald

Remember how this works:

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

Truer words were never spoken

[Ether]

Originally Posted by jblay

It turns out our code timer wasn't syncing with the field

Could you please explain what that means?

Thank you.


~

[jblay]

Originally Posted by Ether

Could you please explain what that means?

Thank you.


~

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.

[Ether]

Originally Posted by jblay

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.

Thanks.


~

[jblay]

Originally Posted by Ether

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.

Thanks.

~

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