Last season, our team tried CAN for the first time. We read about the brownout problem and decided to do something about it before it happens to us. Our team uses Wind River C++. We wrote a wrapper CANJag class inheriting the CANJaguar class for detecting brownouts and restoring all the configurations if necessary. We never had any problem with CAN during the entire season. So we never really know if the code worked. After the season ended, we had a public event that required demo'ing our robot the entire day. It went very smoothly but at some point, our driver reported to me that he saw yellow warnings flying by the debugger saying something about brown out detected. I took a look and was delighted to see that was a warning in the new module detecting brownouts and restoring configurations. The driver didn't even notice anything wrong with respect to the driving. It just kept going normally (may be a little sluggish). It turned out, the driving demo non-stop for a few hours ran down the battery to a voltage level that started to cause brownouts. So we replaced with a fresh battery and everything was good again. If you want to look at how we implemented that class, you can access it here in case you want to port it to LabView (
http://proj.titanrobotics.net/hg/Frc...rclib/CanJag.h).
Ideally, this code should be integrated into WPILib. This module basically shadows all the important configuration data. It overrides the CANJaguar::Set method so that before setting the motor power, it checks for brownout condition. If there is no brownout, no extra work done. But if it does detect brownout, all the shadowed configurations will be programmed back to the Jaguar before programming the motor power. The module also has an optimization to minimize unnecessary CAN traffic by checking if the caller is setting the same motor power over and over again (which is very common in your iterative robot loop). It will only send a CAN message to set power if the power is different from the last value.
Actually even better, if the CAN implementation of Jaguar or Talon makes configuration data non-volatile, then we don't need this code at all! But of course, shadowing values is still beneficial for CAN traffic optimization.