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

Question: accuracy of inertia parameters? #14

Closed
ahundt opened this issue Apr 9, 2016 · 14 comments
Closed

Question: accuracy of inertia parameters? #14

ahundt opened this issue Apr 9, 2016 · 14 comments
Labels

Comments

@ahundt
Copy link

ahundt commented Apr 9, 2016

I noticed you have inertia parameters:
https://github.com/SalvoVirga/iiwa_stack/blob/master/iiwa_description/urdf/iiwa14.urdf#L51

Are they ballpark estimates, or very accurate ones? Thanks!

@SalvoVirga
Copy link
Member

The URDF for the 14kg model comes from here.
I never had a 14kg to play with for long, so I never had the chance to test how accurate those numbers are. What I noticed is that those made some sense when loading the robot onto Gazebo.

The inertia values are not there for the 7kg model and for various reasons I feel I have to step back from that duty, but the smartest idea would probably be to use the same approximation used in the Universal Robot stack using that cylinder_inertial macro for each link.

@ahundt
Copy link
Author

ahundt commented Apr 9, 2016

Thanks for the info!

@SalvoVirga to clarify, step back meaning you won't be able to do much development on iiwa_stack on an ongoing basis?

In case you are interested or someone comes across this question while googling I also came across this interesting looking paper about reverse engineering the inertia params on the previous lbr:
http://www.dis.uniroma1.it/~labrob/pub/papers/ICRA14_LWR_RevMod.pdf

@SalvoVirga
Copy link
Member

Oh no, I meant only about the inertia parameters. I have some professional/legal reasons that might clash with me working on that publicly.

Thanks for the link, I was aware of the good work of those Italian guys. The approximation done with the UR robots could be an easy first step to at least check if it is any good.

@ahundt
Copy link
Author

ahundt commented Apr 11, 2016

ok thanks that makes sense, I totally understand you need to fulfill those obligations. Though as an aside to me it seems very silly that inertia parameters are considered a trade secret! What will an adversary do, write code that runs on your hardware, making it easier to use, so you sell more units of very expensive robots??!? oh my, what a loss! :-)

@SalvoVirga
Copy link
Member

added this in the wiki

@JimmyDaSilva
Copy link

The appendix of the following paper gives identified dynamic parameters for the IIWA 14 (R820):
https://www.sciencedirect.com/science/article/pii/S2405896317317147?via%3Dihub

I wish the same experiment was made with the IIWA 7 version...
The parameters currently used come from the following paper, as discussed in #35: http://www.inacomm2015.ammindia.org/img/94.pdf
The values picked from this paper are the values estimated from CAD files, and do not come from identification. The authors clearly show at the end that they found a better set of parameters through identification, but do not provide them in the paper.

@matthiashh
Copy link

I have a student currently working on that. If he succeeds we should have parameters for the 7kg version. Timeline says about 6 weeks.

@JimmyDaSilva
Copy link

Awesome! Please keep me posted.

@jacknlliu
Copy link
Contributor

Just have a try rosdyn and rosdyn_examples which can calibrate the robot dynamics model.

@JimmyDaSilva
Copy link

Thank you so much @jacknlliu. This seems life-changing

@JimmyDaSilva
Copy link

@matthiashh Did your student managed to do this during this difficult time period?

@matthias-mayr
Copy link

[I separated work and private Github accounts now]

We have some parameters, but the thesis project ended before they could be properly evaluated.

Here are some points about the procedure:

  1. We were finally using ROSdyn as suggested by @jacknlliu (thanks man) and worked with the authors to make it compile and fix some bugs
  2. iiwa_stack only updates joint states at 50Hz. The developers of ROSdyn have their doubts that this is enough for a good estimation of the parameters
  3. We experienced very jiggly execution of the robot with small accelerations and decelerations when executing some of the generated trajectories (stage 2 in ROSdyn, fyi) . We do not know the reason for this. It does not appear when using MoveIT from RViz and does not appear in some other trajectories (stage 1) ROSdyn creates. We noticed that we can circumvent the jiggles when executing the trajectories in T1.

Regarding the validation:

  1. The iiwa_stack Gazebo integration does not seem to support a non-gravity compensated robot arm. When activating gravity for the arm, it basically falls to the ground and shakes a little there. We noticed that a non-gravity compensated simulation of the Panda uses p-gains of more than 10000 whereas it's <=500 for the iiwa (For reference an old commit in a Panda simulation repository)
  2. An internal validation of ROSdyn showed promising results though.

Before releasing values I think the following things should be done:

  1. Get more frequent joint state updates to comply with recommendations of the ROSdyn developers
  2. Find the reason of the jiggly executions of the stage 2 trajectories
  3. Validate the estimated parameters with a non-gravity compensated Gazebo simulation. To do this, at least the controller gains should be adapted, but I do not know how to do this in a structured way.

Maybe @SalvoVirga or somebody else knows something about those issues.

@JimmyDaSilva
Copy link

We experienced very jiggly execution of the robot with small accelerations and decelerations when executing some of the generated trajectories (stage 2 in ROSdyn, fyi) . We do not know the reason for this. It does not appear when using MoveIT from RViz and does not appear in some other trajectories (stage 1) ROSdyn creates. We noticed that we can circumvent the jiggles when executing the trajectories in T1.

I had the same issues with iiwa_stack. It has been discussed a little bit with @jacknlliu in #212
Apparently, there is a random delay introduced by SmartServo.
People from KUKA advised me to perform a “warm-up” and command the current position for about 200ms before starting to command the first motion.
Which is a problem when using MoveIt or ros_control in general, because we stop sending commands between trajectories so SmartServo gets into "nap mode"...

iiwa_stack only updates joint states at 50Hz. The developers of ROSdyn have their doubts that this is enough for a good estimation of the parameters

For those reasons I switched to iiwa_ros, which uses the FRI channel but allows for realtime control, from 200Hz to 1kHz.

Thanks @matthias-mayr. Keep us posted.
I mostly need better gravity compensation, so mass and center of mass for each link

@JimmyDaSilva
Copy link

I think there is definitely something wrong in the IIWA7 model.
On the left the IIWA14 model, on the right the IIWA7 model, showing the center of masses for each link in Gazebo 9.

I know there can be multiple working solutions with identification, but this one seems quite strange to me. Especially with link_6

Screenshot from 2020-06-17 17-21-36Screenshot from 2020-06-17 17-22-44

The model parameters seem to come from this paper.

I didn't get the time to transform the identification coming from this paper using the DH convention, to the URDF convention.
@ahundt @SalvoVirga, do one of you know the "ROS way" to convert the DH params to URDF style easily?
How did you come up with this URDF for the IIWA7?

Many thanks !

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

No branches or pull requests

6 participants