Breaker Panel Diagnostics

[dm0ney]

How many teams actually used the Breaker Panel hookup to the RC and code to monitor that using the user bytes?

We did not wire it and I disabled the code to allow the user bytes to be used for other things.

For those who did use the panel, was it helpful?

I know that on this years robot, at least when I was around it, we never tripped a breaker. That might be why I never cursed that we didnt use the diagnostics. (knocks on wood)

[CJO]

I think that the issue between the serial port emulator on the PC and the breaker panel and the camera were never fully resolved.

[ConKbot of Doom]

We didn't use the breaker panel hookup either. I'm pretty sure we never popped a breaker. The kit drivetrain had enough torque to spin wheels, so we don't stall the CIMs. When our arm got stalled in autonomous mode once, the van door motor sheared the roll pin we used rather than stalling the motor, so that didn't pop the 30A it was on. That was it for motors for us.

It was nice having one panel rather than having one for the MAXI breakers and one for the ATC breakers.

[ace123]

It happened twice on our robot, and both times, it was possible to identify the problem. The first time was when one of our Victors caught on fire, and that was apparent. The second time happened ten minutes before the semifinals because of a shorting arm motor cable. Both places were easily identifyable when the motors stopped working.

Having a breaker panel port would only require either a Y-cable (nasty) or else it would make us unplug one cable in exchange for another.

Aside from disabling the robot completely (which is not always what you want to do -- it is better to have a half-working arm and drivetrain than no arm or drivetrain), what could a program do with the data it gets from motors.

[The Lucas]

I set a switch LED on the OI equal to the aBreakerWasTripped variable. It was useful early on when we were over drawing our drive motors. After we fixed the problem, we removed the cable to cut weight.