[Greg McKaskle]

To review what is going on with this issue.

The robots are capable of drawing hundreds of amps from the battery and that causes an enormous drop in the voltage seen by robot components. This is also affected by battery condition, wiring loss, gearing, number of motors, etc.

If nothing attempts to manage the current draw, motor controllers, robot controller, VRM, PCM, cameras, and anything else with a micro controller will reboot, fault, and misbehave. Lots of bad behaviors that nobody wants to see.

If the condition persists for very long, the heat will cause breakers to pop or fuses to blow in order to prevent wire failures.

Luckily the system is capable of managing current draw at many levels.
1. The roboRIO monitors its input voltage level and coordinates brownout staging in order to prevent blackout of critical elements. This is the approach that is currently being tweaked.

The general approach of the brownout behavior is to disable high draw components -- motor controllers -- in order to stabilize the voltage level and avoid reboots and further faults. As mentioned earlier, the alpha results were quite promising, but the response is being tweaked in order to maintain the supply rails to sensors -- both analog and digital.

One aspect of this, detailed by Joe earlier, is to identify which PWM devices are motors and which are servos. The FPGA will then be able to disable motors directly instead of simply removing their signal and waiting for their micros to timeout. This quicker response has not been tested by the alpha or beta teams, but it is a ~10X improvement in timing control of the circuit driver.

2. When a brownout does occur, the information will be accessible to robot code. If the motor controllers outputs are zeroed by the FPGA, this can cause integral windup in control loops. If those control loops are aware that their set point was not what they requested, they can adjust their integral state.

If the brownout is more severe and the supply lines to servos and sensors is interrupted, the robot code can know that absolute position of some mechanisms may need to be recalibrated.

3. Motor controllers implement the set point, and as seen with the Jaguar, they can impose limits. Currently this is not a part of the plan.

4. User code is in charge of motor controller set points. Ramping or limits are easy to implement. The Power API now gives feedback from the PD and roboRIO that should help with balancing performance and current draw. I don't personally have a PD to test, but it is hoped that external current sensors and monitoring isn't really required in order to make this approach effective and accessible to many teams.

5. Robots sensors could be allowed to use a suppy that is not shared with servos.

There are probably others. I feel that the next step is to characterize the improvement that Joe has already implemented. I'm sure that will be accomplished in the beta. Probably quite soon.

Greg McKaskle