As a follow up to some of the power problems FRC#1018 encountered last year, we have performed some testing to define how long devices operate when power is interrupted.
What else did you have on your test robot besides the breaker, PDP, VRM, RoboRIO and radio? The order-of-magnitude longer time it took a main breaker trip to cause reset makes me suspect that there is a far greater capacitance-to-load ratio in the remainder of the robot than in the tested components, which is counter to what I expected for a robot in operation. Perhaps if you tried the main breaker test while simulating a robot under a more typical match load*, the sensitivity would increase.
perhaps four CIMs raising a load with an elevator, drawing somewhere from 10A to 50A each.
I’m certainly no expert on this… But I do know that pushing a robot around while it’s turned off generated enough power to light up the LEDs on the speed controllers. Could a robot coasting to a stop and mechanisms returning to their lowest potential energy point generate enough power over the (very) short term to account for that difference?
The initial focus was to examine the RoboRio and the Radio. So we didn’t test all combinations.
The major items included are:
6 TalonSRXs, and two of the new Victors.
We also have a PCM.
There are additional smaller items present, but I expect that these items provide the majority of the capacitance.
This is why I proposed an elevator as a dummy load; you can secure the chassis while taking the tests and not have to chase after your scope and interface.
What is your battery voltage during these tests? Since the various components reset at a particular voltage, the duration you measure is partly dependent on the battery voltage just before the MOSFET is opened.
Good point. Perhaps I should have instrumented the Voltage from load supply to load return.
The way the test was wired, I didn’t necessarily have access to the return line; although I could have wired the test differently. If I repeat the testing, I will attempt to examine the Voltage across the load.
Battery used was nominally at full charge, but that doesn’t quantify the Voltage at the time of testing.
I’m surprised that the VRM actually made the radio reset faster, I thought it would have some capacitance and would have extended the time needed for a power interruption to cause a reset on a radio. While not explicitly stated, you were using the 2A side of the VRM right?
While testing the radio in both configurations, what mode was the radio in? I’d expect the time needed to reset while in AP (home) mode to be shorter than it configured in bridge (competition) mode. Additionally if there is traffic on the radio, I’d expect the times to be shorter. 1mbps of data is roughly how much the control data uses should you ever want to test it again. While conducting each radio reset test, did you wait for the radio to fully boot in the event it cycled?
Yes, the VRM reset was extremely surprising; however, the radio reset timing at the radio input and at the VRM input are very repeatable. And, to confirm, the radio was fed from the 2 Amp load off of the VRM.
The team doesn’t like to run through a router at home; while not verified I am reasonably certain that the radio is in AP mode.
During testing, there wasn’t any data being communicate to/from the robot. The most time consuming effort in the testing was to iterate the FPGA design in order to change the pulse duration; the second longest time was waiting for the electronics to settle from reset conditions.
In future testing, we can try to incorporate the drive station - that will assure some data transfer is active, perhaps more is needed.
The criteria used, for the radio and for the RoboRio was ‘steady lights’. This criteria was applied between successive test runs; i.e. if test N resulted in a reboot then test N+1 waited until lights were in a steady condition. Field re-connect would have taken longer, I am sure, had that been included in the test. The real point was to attempt to identify the outage duration before the reconnect process was required.