Closed christgau closed 1 week ago
This happens when you reach a singular configuration. If you want to check if you are in a singular configuration or not, track the rank of the corresponding Jacobian; if it's not full rank you will get 0 values. Note that you can always trust the external torque estimation, which does not suffer from this issue. Thanks for pointing this out! We will add a note in the API documentation.
Thanks for your reply.
Stupid question from my side: When I encountered that F_ext = 0 phenomenon the robot was steered by using the guiding mode. But this was only done for testing purposes. If we use MoveIt to steer the robot, will this prevent the robot from going into such a singular configuration?
And one suggestion: It appears to me, that the FCI "knows" about a singular configuration and emits those (0, 0, 0) forces in that case, i.e. when it is not possible to compute the force components. Wouldn't it be more convenient for the user to have a direct indicator for such a state an favor of computing a matrix rank. All-Zeros in F_ext might be such a indicator (if documented), but what about adding a field in the published F_ext
topic message which marks the values as valid?
Concerning your first question, I don't know the details, but I guess that the via points of the trajectory that MoveIt! generates are probably non singular. However I don't think that the final behavior, which is interpolated and tracked by the JointPositionTrajectoryController, guarantees that no singular configurations will be reached.
Concerning your second question, we will definitely consider your suggestion!
@jrmout
This happens when you reach a singular configuration. If you want to check if you are in a singular configuration or not, track the rank of the corresponding Jacobian; if it's not full rank you will get 0 values. Note that you can always trust the external torque estimation, which does not suffer from this issue. Thanks for pointing this out! We will add a note in the API documentation.
I tried to figure out in which cases the jacobian matrix is rank deficient.
Suppose following joint configuration:
[0, 0, 0, -2.356194490192345, 0, 3.141592653589793, -2.356194490192345]
Obviously, panda_link1 and panda_link2 line up and forces/torques are set to 0 on F_ext
topic.
However, the rank of the jacobian matrix returned by MoveIt! MoveGroupCommander API is 6, unless I set the threshold for singular values to somewhat around 0.085 (using numpy.linalg.matrix_rank).
According to the MoveIt! documentations the jacobian is computed with reference to the last link of a specified group. Can you please explain how you compute the jacobian of the matrix.
Besides that, you are saying external torque estimation does not suffer from this issue.
Tell me if I am wrong but F_ext
messages are created from the K_F_ext_hat_K
field of the robot state.
Your documentation about that field says:
Estimated external wrench (force, torque) acting on stiffness frame, expressed relative to the stiffness frame.
However, torques and forces are all 0 so where can I read the values of external torque estimation instead?
I would appreciate any help, thanks in advance.
If there is any further discussion necessary, please re-open the issue :smile:
(I'm not sure if this the correct place to submit this issue, so please apologize if it's the wrong one.)
In an experiment with the panda robot, I needed data that was published under the
/franka_state_controller/F_ext
topic. When the robot was "idle", which means no force except gravity is acting on it, I observed forces more or less around zero but with clearly observable noise. With a constant force, introduced by a weight, e.g., the same applies: constant but little noisy force component values are observed.When the robot is brought into certain positions using the guiding buttons all force values become precisely 0.0 and so do the torques. This happens for different positions. I recorded both
F_ext
and/franka_state_controller/franka_states
with rosbag. In the current error field of the state messages, no error is marked as present.Since the force and torque values are precisely zero and different to the values from the "idle" state, I assume that there is either an internal error, e.g. in the FCI, or those zero values are meant to indicate an error. In the latter case, I cannot find any documentation that validates this hypothesis.
So, is this an error or intended (but undocumented) behavior? For the latter case: which circumstances are causing these values. Can one prevent to bring the robot in such a state.