Arms remain down when no tf is received

[130s]

When somehow tf isn't received, hiro's arms are down (similar to what's reported in this issue but different cause) even when they are actually posed differently, say initial pose. Manually giving certain pose in that situation by MoveIt! RViz plugin ends up moving the arm toward the down pose as shown on RViz, which most likely hits the base, and even worse in a very fast speed for some reason I haven't been able to explain.

Assuming lost-tf situation is probably inevitable for many reasons, workaround is needed.

[k-okada]

In general, No tf situation is critical situation for ROS-based robots, so usually the robot wont work. One possible solution is to add some code in [1], that it wont send any command if tf is not seen for a while. Another solution is to add InitialPose in MoveIt so that robot does not arms down, in initial state or Lost-tf situation.

https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/src/HrpsysJointTrajectoryBridge.cpp

[130s]

One of the causes that possibly realized the erroneous situation should now be addressed by this PReq. We might still want to implement a more robust solution to this.

One possible solution is to add some code in [1], that it wont send any command if tf is not seen for a while.

That sounds a viable option. Aiming for ver 1.1 milestone.

[130s]

Talked to @k-okada and we think we want the robot to "FREEZE" when there's no tf published.

In more general note, we want a nice low-level measure to freeze robots from any movement when there's a critical error detected in the higher level. And this ticket's issue is an example. https://github.com/start-jsk/rtmros_hironx/issues/36 as well. I'll open a ticket in hrpsys-base.

[snozawa]

I'm not sure that I could understand all discussion, but is this "FREEZEING" necessary for hrpsys-base?

I'd like to know which situation is related to your discussions:

1. If tf is not aveilable, stop the current executing motion sent to SequencePlayer previously.
2. If tf is not aveilable, do not send further setJointAngles command to SequencePlayer and just wait for execution of current executing motion.

I agree with your opinion that "FREEZING" robot in hrpsys-base layer is necessary:

a nice low-level measure to freeze robots from any movement when there's a critical error detected in the higher level

However, in the case of 2, if hironx-users move robot's joints only from SequencePlayer, i think you can implement "FREEZEING" in HrpsysSeqStateROSBridge. If tf is aveilable, pass through SequencePlayer->setJointAngles function. Otherwise, do not pass through SequencePlayer->setJointAngles function.

In the case of 1, we need "FREEZING" functionality in hrpsys-base layer, as you said.

[130s]

Just leaving a memo; just saw this happened on a new robot that was experiencing network issue. Why this issue is so dangerous is that users might not realize the impact (i.e. it's very likely that robot hits the base when giving any command while this issue is happening).