Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

external force equals exactly (0, 0, 0) despite acting force #25

Closed
christgau opened this issue Aug 16, 2018 · 5 comments
Closed

external force equals exactly (0, 0, 0) despite acting force #25

christgau opened this issue Aug 16, 2018 · 5 comments

Comments

@christgau
Copy link

(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.

@jrmout
Copy link
Contributor

jrmout commented Aug 17, 2018

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.

@christgau
Copy link
Author

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?

@jrmout
Copy link
Contributor

jrmout commented Aug 17, 2018

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!

@fwalch fwalch transferred this issue from frankaemika/libfranka-release Nov 6, 2018
@tjaeuth
Copy link

tjaeuth commented Sep 12, 2019

@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.

@AndreasKuhner
Copy link
Contributor

If there is any further discussion necessary, please re-open the issue 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants