Radio Packet loss + closed loop control system = lunging robot

[Dave K.]

Teams that have implimented closed loop speed/position controls should be aware that when packet loss occurs, and the PWM outputs are disabled, that your control loop software will continue to run and accumulate error that may in turn result in rather agressive behavior when the radio link is re-established.

When the robot controller has declared a communication's failure and disables the outputs the user firmware currently has no direct means of determining that the robot is now in a "disabled" state. All your firmware will know is that the motors are slowing down and will attempt to make them go faster. When the outputs are re-enabled, the (now) larger control values will be immediately applied to the motors and make them rapidly increase in speed, until the control firmware recognizes the overspeed condition and takes corrective action.

The "disabled" bit in the mode struct only indicates whether the disable input on the competition interface has commanded a disable, and thus cannot be reliably used as an indication to your control loop why the motor(s) are slowing down.

I've asked IFI to make the local disable visible to the user code, and they are considering a change, but at this late date, I wouldn't rely upon it to resolve this problem.

In the alternative, possible work arounds, which I've not yet had an oppertunity to test, include:

1.) Watching the 'packet_num' byte to make certain it is changing

2.) Wiring a 'relay' output directly back into a user 'input', set the relay output ON and use the user input bit as an indication of output disable.


Although I've had the closed loop control firmware implimented for a few weeks, this problem became much more obvious after loading the V14a RC master CPU firmware. V14a disables the outputs much more quickly than V13 did, so with V13, a few lost packets only caused a momentary loss of control, but didn't create an immediate problem for the control firmware.