Updated the new so101 calibration urdf with fixed direction and frame #106
Conversation
1- remove package in assets path 2- add material back 3- add encoding style in xml header
|
@adityakamath Can you maybe test the urdf in this pr? we flipped and corrected the axis for mujoco and add back proper frames |
|
cc @StoneT2000 FYI |
|
@michel-aractingi I'm curious, what's the reason for flipping the Y axis? And what convention are you following? Mostly in robotics, the right-hand convention is used - x: forward, y: left, z: up. Is this the case with SO-101 / LeRobot? And does the change match this convention? This question ^ is for both the URDF and the Mujoco files - with the flip, the entire model is now rotated, and does not match the so101_old_calib URDF/Mujoco or the so101 URDF. SO100: SO101 Old Calib: SO101 New Calib: Addition of the frames in the URDF looks okay - as long as the frame names are not duplicated, it should not cause issues with other frameworks And the Mujoco file is also OK other than the rotation of the entire model. |
|
If the y axis flip is not necessary, I'd recommend making a PR with only the addition of the new frames in the URDF. Won't impact existing applications using the URDF and also provides compatibility to placo |
…entions used in the other description files
|
Hey @adityakamath , You're right the flipped y-axis won't impact placo or our controllers. I think we orginally flipped it because we were relying on an old convention in our code, but its not needed. @pkooij shifted the base back to origin and the files should follow now the same conventions as the old description files. |
…b over the full range of motion
Simulation/SO101/so101_new_calib.xml
Outdated
| <position class="sts3215" name="1" joint="1" forcerange="-3.35 3.35" ctrlrange="-1.91986 1.91986"/> | ||
| <position class="sts3215" name="2" joint="2" forcerange="-3.35 3.35" ctrlrange="-1.74533 1.74533"/> | ||
| <position class="sts3215" name="3" joint="3" forcerange="-3.35 3.35" ctrlrange="-1.74533 1.5708"/> | ||
| <position class="sts3215" name="4" joint="4" forcerange="-3.35 3.35" ctrlrange="-1.65806 1.65806"/> | ||
| <position class="sts3215" name="5" joint="5" forcerange="-3.35 3.35" ctrlrange="-2.74385 2.84121"/> | ||
| <position class="sts3215" name="6" joint="6" forcerange="-3.35 3.35" ctrlrange="-0.17453 1.74533"/> |
There was a problem hiding this comment.
I added the ctrlrange to be able to control each over the full motion in mujoco.
Is the xml update fine for you?
There was a problem hiding this comment.
Hi @michel-aractingi just curious how are these ctrl ranges / joint limits computed?
I would like to apply the same for the SO100 (I am guessing the range should be the same but would need to verify).
There was a problem hiding this comment.
Hey @StoneT2000 They already present in the joint ranges in the xml and the limits of the urdf. I just put the same values for the ctrlrange.
There was a problem hiding this comment.
Does the urdf file in this PR work for you @StoneT2000 ?
There was a problem hiding this comment.
Oh my concern is these values do not reflect the new hardware calibration. I remember the original URDF this repo had, despite making the 90 degree change / axis flips was still off by a few degrees when doing sim2real.
@pkooij mentioned that the new calibration system will result in the zero position actually an absolute reading of something like 5 degrees for one of the motors in another issue.
There was a problem hiding this comment.
Hey @StoneT2000 yeah your're right, I just saw the discussion in your PR #87
Perhaps we need to improve our calibration procedure or add a fixed offset if the shift from the middle position is fixed over all arms calibrated in the same way
There was a problem hiding this comment.
Is changing calibration a possibility at this point given that LeRobot only introduced the breaking change recently?
I personally think LeRobot should keep the current calibration system (it's easy to do, and can? ensure consistency between hardware if everyone moves their joints to their full extent).
For degrees mode / sim alignment with the hardware if we don't want some breaking changes best to modify the mjcf/urdf to reflect the "not so natural" offsets.
There was a problem hiding this comment.
You're right, modelling the shift in the mjcf/urdf should be the way to go.
I modified both the xml and urdf files.
… joints limitis between URDF and XML files
… joints limitis between URDF and XML files
|
LGTM, tested the mujoco files locally |
5 participants
so101_new_calib.urdfandso101_new_calib.xmlbaseframeandgripperframeto have proper frames for the base and end effector to be compatible with kinematics packages like placo. Check PR#1322