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

Tune admittance controller #2

Open
sangteak601 opened this issue Jul 18, 2024 · 10 comments
Open

Tune admittance controller #2

sangteak601 opened this issue Jul 18, 2024 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@sangteak601
Copy link
Member

I’ve set up the admittance controller, but I’m having difficulties tuning it. If anyone could help me with this, that would be really helpful.
You can follow these steps to start peg in hole example.

@sangteak601
Copy link
Member Author

Screencast.from.2024.07.25.07.11.26.webm

@pac48 @dyackzan
This is what I'm experiencing now. What would be a problem here?

@sangteak601
Copy link
Member Author

Screencast.from.2024.07.25.08.03.29.webm

This is without admittance controller.

@dyackzan
Copy link
Collaborator

It looks like you're probably getting positive feedback here. This could happen if your FTS frame axes are not properly aligned between your admittance controller configuration and your robot model(s). If you echo the FTS readings while you run this, I expect the FTS readings shoot up once contact is made.

@dyackzan
Copy link
Collaborator

Try negating these lines in mujoco_system.cpp first. Also ensure that your FTS frames are aligned between the URDF and the Mujoco model

@sangteak601
Copy link
Member Author

@dyackzan Thanks for the reply. I will try to make them negative.
It seems direction of mujoco force sensor has a problem or at least unclear behavior. I found some similar issues

@sangteak601
Copy link
Member Author

sangteak601 commented Aug 2, 2024

I'm not sure whether this is desired behavior or not, but this was the best I can do...
panda_peginhole.webm

@sangteak601
Copy link
Member Author

@dyackzan @pac48
Hi guys,
I tried different values for stiffness and damping. It seems the motion doesn't change a lot.
I'm uploading data. Do you guys have any thoughts?

Also, there is another problem. When motion planning goal is canceled, robot goes out of control and moves crazily. You can see this at the end of this video.

  1. mass = 30, damping = 0, stiffness = 0.01
    rosbag2_2024_08_07-19_33_38.zip
    image

  2. mass = 30, damping = 0, stiffness = 0.1
    rosbag2_2024_08_07-19_36_11.zip
    image

  3. mass = 30, damping = 0, stiffness = 1
    rosbag2_2024_08_07-19_37_43.zip
    image

  4. mass = 30, damping = 0.1, stiffness = 1
    rosbag2_2024_08_07-19_38_59.zip
    image

  5. mass = 30, damping = 1, stiffness = 1
    rosbag2_2024_08_07-19_40_41.zip
    image

  6. mass = 30, damping = 10, stiffness = 1
    rosbag2_2024_08_07-19_42_55.zip
    image

@sangteak601
Copy link
Member Author

@dyackzan
You can reproduce the problem with following setup.

@dyackzan
Copy link
Collaborator

I am getting better performance/less oscillation with the following admittance parameters:

      mass:
        - 8.0  # x
        - 8.0  # y
        - 8.0  # z
        - 8.0  # rx
        - 8.0  # ry
        - 8.0  # rz
      damping_ratio:  # damping can be used instead: zeta = D / (2 * sqrt( M * S ))
        - 30.  # x
        - 30.  # y
        - 30.  # z
        - 30.  # rx
        - 30.  # ry
        - 30.  # rz
      stiffness:
        - 60.  # x
        - 60.  # y
        - 60.  # z
        - 60.  # rx
        - 60.  # ry
        - 60.  # rz

As for the jump at the end, that is occurring because there is a big spike in the FTS readings right when the command is cancelled for some reason. You can see this spike in the PlotJuggler plot below that I recorded while running the demo:

Screenshot from 2024-08-13 10-12-39

To debug further, I would recommend you take a look at your ros2_mujoco system code to ensure that the jump in FTS values is actually coming through from MuJoCo and is being passed through correctly. Then we can rule out any issues coming from your ros2_mujoco package.

Once you check that and verify that MuJoCo is actually sending this discontinuous FTS reading, then you can start tweaking the MuJoCo simulation setup. Here are a couple ideas it may help to look closer into:

  1. Is the convex decomposition causing an issue somehow? Try a simplified contact task (just pushing a flat peg against a flat surface) and see if this behavior is replicated.
  2. Are your MuJoCo contact solver settings (like solref and solimp) configured correctly? See the MuJoCo Contact section of their documentation for more details.

@sangteak601
Copy link
Member Author

@dyackzan Thanks David. It looks much better with new parameters!
I will take a look at the FTS issue.

@sangteak601 sangteak601 added the bug Something isn't working label Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants