ethercat trigger controller should kill the gripper light when its killed (ros ticket #3027)

[ahendrix]

It's weird to leave it on

trac data:

• Owner: blaise
• Reporter: watts
• Reported at: Fri Oct 30 00:03:35 2009
• URL: https://code.ros.org/trac/wg-ros-pkg/ticket/3027

[ahendrix]

[blaise] Rob, Derek,

Where would the best place to implement this be? We could put it into ethercat_hardware, but that won't get the job done if etherCAT crashes. The only place to do this reliably is probably in the firmware, but it isn't clear that it is important enough to put the effort in.

Kevin, Vijay

Does this only happen if there is a crash while somebody is using the LED? Is it accurate to say that most of the time the LED would be off?

[ahendrix]

[watts] I was just thinking that we could have it turn off the light in its destructor or stop function. If pr2_etherCAT crashes, you've got bigger problems.

[ahendrix]

[dking] It could be done with the gripper FW. I would use the watchdog timeout, so that when it occurs, the LED would turn off. (The watchdog timeout is caused by not getting a command packet for about 100ms). If I did do this in the FW, I would put in another bit so that this new feature could be enabled/disabled.

I believe this should be done at the controller layer. pr2_etherCAT should not crash. Even if it does, is not unsafe to leave the gripper LED on.

[ahendrix]

[wheeler] pr2_etherCAT should not crash, but it does all the time when people are developing new controllers. Is it always going to be safe to set digital I/Os to low when a watchdog timeout occurs?

[ahendrix]

[blaise] OK, it sounds like the right thing to do here is to add a parameter to the trigger controller that says what state to go to when the controller is taken down. I'm putting this as a really low priority because I think Kevin's test is currently the only thing that this would make any difference for.

Kevin, which controller are you using? The TriggerController or the MultiTriggerController?

[ahendrix]

[watts] TriggerController on r_gripper_motor

[ahendrix]

[dking] Replying to [comment:4 wheeler]:

pr2_etherCAT should not crash, but it does all the time when people are developing new controllers.

It is possible hook the digital-out to something where it is unsafe to leave the digital-out on indefinitely. If may make necessary to return the digital-out to a safe state after safety-disable.

Is it always going to be safe to set digital I/Os to low when a watchdog timeout occurs?
The digital-out will be low after the device is powered on. We can assume that low is always the safe state.

[ahendrix]

[blaise] Given that none of the robot hardware currently has anything unsafe on that digital output, I would see this as a really low priority item.

Also, I like that the camera triggering continues to work even if there is a safety lockout. So it would be best if this behavior was configurable.