EuRoC Forum

[Robotica]

Hello,

I would like to ask a few questions regarding the StopCondition messages and how they are linked to the functionality of the simulated Light-Weight Robot. Firstly, when it comes to the joints of the robot, the stop condition is based on the external force, isn't it? Based on the telemetry information these external forces seem awfully small compared with the limits provided... So my question is: do the torques (NOT external), also provided by the telemetry message, have any effect on the when the stop condition is met? If yes, how do they affect the conditions?
Secondly, when the robot is moved in a way that makes one of the joints exceed its external torque limit, the robotic arm is automatically stopped by the simulation. Is a StopCondition message published at the same time giving information about the joint that caused the disruption? I see there exists a topic called /euroc_interface_node/stopcondition but no messages seem to be published there. What I did to test this was to simply drive the manipulator to a point where one of the joints exceeded the torque limit provided using the SetStopCondition service, and then check the above mentioned topic but there was nothing.
Thirdly, I would greatly appreciate a more thorough insight into the condition operators published within the stop condition message. If, for instance, I choose the operator '|>', which according to the technical annex means "absolute value is bigger than threshold", does it mean the robotic arm can move around until its external torque exceeds the limit I have set for it? At least in some of my tests the robot has been able to continue moving even if the external torque momentarily exceeded the limit set by myself. When, on the other hand, I change the operator to '|<', the robot stops but starts moving again when the limit is set to naught, for example (thus making the external torque greater than the limit). Needless to say there is some confusion in this area of the task, at least in my case.

Thank you very much for your help,
Regards,
A

[Peter Lehner]

Hi,

Firstly, when it comes to the joints of the robot, the stop condition is based on the external force, isn't it?

Yes, if you select 'joint_ext_torque_threshold' as condition_type.

Based on the telemetry information these external forces seem awfully small compared with the limits provided... So my question is: do the torques (NOT external), also provided by the telemetry message, have any effect on the when the stop condition is met? If yes, how do they affect the conditions?

The stop condition is only affected by the external torque value. Nevertheless the external torques are estimated based on an internal model of the robot. Therefore the configuration and the dynamics of the robot have an influence on accuracy of the external torque estimation and there is an implicit connection between the torques and the external torques.

Is a StopCondition message published at the same time giving information about the joint that caused the disruption? I see there exists a topic called /euroc_interface_node/stopcondition but no messages seem to be published there. What I did to test this was to simply drive the manipulator to a point where one of the joints exceeded the torque limit provided using the SetStopCondition service, and then check the above mentioned topic but there was nothing.

There should be no topic "/euroc_interface_node/stopcondition" - when do you see this topic? When a stop condition is triggered during the move_along_joint_path service, the service returns the corresponding stop_condition as string in its return value. The StopCondition message by itself is only for passing the stop condition to the interface during a SetStopConditions request.

Thirdly, I would greatly appreciate a more thorough insight into the condition operators published within the stop condition message. If, for instance, I choose the operator '|>', which according to the technical annex means "absolute value is bigger than threshold", does it mean the robotic arm can move around until its external torque exceeds the limit I have set for it? At least in some of my tests the robot has been able to continue moving even if the external torque momentarily exceeded the limit set by myself. When, on the other hand, I change the operator to '|<', the robot stops but starts moving again when the limit is set to naught, for example (thus making the external torque greater than the limit).

You are correct - there is a mistake in the documentation. The correct description should be:

Code: Select all

# - ">" which means value is bigger than threshold
# - "<" which means value is smaller than threshold
# - "|>" which means absolute value is bigger than threshold
# - "|<" which means absolute value is smaller than threshold


which also makes it consistent with the non-absolute requests. We will fix this in the next update.

Kind regards
- Peter

[Peter Lehner]

We have inspected the stop condition code and I have edited the above post with the correct description of the condition operators.

[Robotica]

Thank you for your answer. Working with the SetStopCondition service I also noticed that setting a stop condition for the gripper (tool_force_threshold) leads to some problems. I took this threshold as equivalent to max_gripper_force, which is 200 N. But when I set this condition, the robot would not move at all from its original vertical position, and the MoveAlongJointPath service provided me with the following StopReason:

Stop Condition 7: total force in direction [0.000000, 0.000000, 0.000000] is 1434.191 N |> 200.0000 N, full force vector: [-1.727565, -20395.262286, 141977.770114] at sim_time 2.190

As I understand, the stop condition is given the number 7 because number 0 corresponds to the first joint. What surprises me is the immense amout of force measured at the gripper, and I had to ask myself whether it is a realistic value or rather an error within the code... Furthermore, the measurements come straight from the simulation but do not correspond to the values provided by the GetEstimatedExternalForce service either.
Additionally, I would like to ask one more thing about the stop conditions. Sometimes, when the robot has picked up an object and is moving toward the corresponding target zone, one of the stop conditions may be exceeded and the robot stops with a jerk. This jerking movement then causes the robot to lose the object and the screen turns red indicating task failure. Why does this happen? Is it because the object hits the robot or a similar reason? On stopping due to a red screen, the MoveAlongJointPath service only provides an empty string as the StopReason, which does not offer any explanation as to why the simulation was stopped.

Thank you again for your help!
Regards,
A

Edit:
Furthermore, in your answer to AM-Robotics' post "SetStopCondition service", you mention that "A "joint_ext_torque_threshold" stop condition with "joint_name = gripper" specifies a threshold for the measured force on the gripper jaw joints" but when I intend setting a such joint_ext_torque_threshold condition for the gripper, the service call fails and the following error message is printed:

Setting Stop Conditions failed: /home/devel/euroc/gazebo/challenge2_sim/euroc_c2_plugin/ros/ros_interface.cpp:341 on_set_stop_conditions() condition 7, invalid joint gripper

How, then should I go about setting gripper stop conditions for both the "the force exerted by the weight of the object pulling the TCP towards the floor" and "the force exerted by the gripper to hold the object in place" (According to your previous answer, "tool_force_threshold" and "joint_ext_torque_threshold", respectively)?

[Peter Lehner]

Hi,

Working with the SetStopCondition service I also noticed that setting a stop condition for the gripper (tool_force_threshold) leads to some problems. I took this threshold as equivalent to max_gripper_force, which is 200 N.

The 'tool_force_threshold' is not equivalent to the max_gripper_force. I explained this in the 'StopCondition service' thread which you referenced below. The tool_force_threshold uses the measured external force on the TCP.

But when I set this condition, the robot would not move at all from its original vertical position, and the MoveAlongJointPath service provided me with the following StopReason:
Stop Condition 7: total force in direction [0.000000, 0.000000, 0.000000] is 1434.191 N |> 200.0000 N, full force vector: [-1.727565, -20395.262286, 141977.770114] at sim_time 2.190

The high external torque measurements appear due to the singular position of the LWR during the start position. The algorithm estimates the external force on the TCP based on the kinematic / dynamic model of the LWR. This model is subject to singularities when the arm is straightened. You should only specify a tool_force_threshold when the arm is far away from singularities as the error of the estimation is not predictable close to singular configurations.

As I understand, the stop condition is given the number 7 because number 0 corresponds to the first joint.

The number 7 indicates that you specified at least eight (8) stop conditions in the SetStopConditions service. The MoveAlongJointPath returned to you the zero based index of your list of stop conditions. In this case the stop reason is the 8th stop condition in the stop condition array you specified.

What surprises me is the immense amount of force measured at the gripper, and I had to ask myself whether it is a realistic value or rather an error within the code... Furthermore, the measurements come straight from the simulation but do not correspond to the values provided by the GetEstimatedExternalForce service either.

Due to the reasons described above the measured forces are inconsistent in the singular configuration and can vary in time. The force you receive directly from the simulator is a direct measurement and independent of the kinematic state of the robot.

Additionally, I would like to ask one more thing about the stop conditions. Sometimes, when the robot has picked up an object and is moving toward the corresponding target zone, one of the stop conditions may be exceeded and the robot stops with a jerk. This jerking movement then causes the robot to lose the object and the screen turns red indicating task failure. Why does this happen? Is it because the object hits the robot or a similar reason? On stopping due to a red screen, the MoveAlongJointPath service only provides an empty string as the StopReason, which does not offer any explanation as to why the simulation was stopped.

Once a stop condition triggers the robot performs a hard stop in the current configuration. If the robot moved at a high velocity this hard stop will exceed the torque limits and the 'emergency stop' of the robot triggers. The solutions to this problem would be to avoid triggering stop conditions during fast movements (especially the tool_force_threshold in singular configurations). When stopping due to a red screen the MoveAlongJointPath returns the failure in the "error_message" field.

... the service call fails and the following error message is printed:

Setting Stop Conditions failed: /home/devel/euroc/gazebo/challenge2_sim/euroc_c2_plugin/ros/ros_interface.cpp:341 on_set_stop_conditions() condition 7, invalid joint gripper

How, then should I go about setting gripper stop conditions for both the "the force exerted by the weight of the object pulling the TCP towards the floor" and "the force exerted by the gripper to hold the object in place" (According to your previous answer, "tool_force_threshold" and "joint_ext_torque_threshold", respectively)?

This was actually a bug in the simulator. We have already uploaded Version 1.0.8 which fixes this issue.