RobotLocomotion/spartan

Possibility of discontinuous robot commands when robot is restarted

gizatt opened this issue · 5 comments

If the robot is stopped in the middle of playing back a trajectory (or planeval is in some other state where its setpoint is continuously changing), and then the driver and pendant apps are restarted, but planeval is not restarted, the robot might be commanded to move instantaneously to a distant posture. The "proper" restart procedure (kill plan eval + controller, then un-estop and start robot, then start plan eval + controller) avoids this, but it'd be nice to have some safeties in place to prevent it from happening at all.

Plan eval currently only checks deltas between the previous commanded state and the new commanded state. Having it also check between previous observed state and the new commanded state would offer limited protect against this. (The threshold would have to be picked carefully to be sensitive to the fact that the robot doesn't instantaneously or perfectly track robot commands... but even a fairly liberal threshold would catch the more dangerous, 10s-of-degrees-large movements that we would never consider actually commanding.

@pangtao22 has observed that these instantaneous commands cause trip fuses in the robot, so definitely be careful about how you restart drivers, especially before we get this safety in place.

Yes, we should definitely add this.

I took a crack at adding a guard on startup of the iiwa driver which looked for incoming command messages before any status was sent (such as commands from a controller which was left running). I never really tested to make sure it reliably avoided the problem or merged with master, but for the curious:
https://github.com/sammy-tri/drake-iiwa-driver/tree/startup_guard

I think that this check should be added in kuka_driver.cc. This is the lowest level and where the ultimate safeties should live, just in case someone does something stupid in plan_runner, we still don't want to send it to the robot.

This has since been fixed in our kuka_driver branch