[Feature] Improved/fixed and somewhat tuned URDF for simulation

[StoneT2000]

I made the following changes to the original URDF in this repo, addressing #54

• Fixed joint limits to reflect real world behavior
• Fixed joint tags from continuous to revolute which permit joint limits
• Fixed joint directions and orientations to match the real robot's joints
• removed spaces in link names
• manual decomposition of gripper link collision meshes into simpler meshes for better simulation

I tested this URDF via our lab's simulator (maniskill), you can see what the visual and collision meshes look like: https://maniskill.readthedocs.io/en/latest/robots/so100/index.html

There is also some additional files provided which can be useful for motion planning. The .convex.stl extension of files.

[pkooij]

Hi @StoneT2000, Thanks you for the changes, I think they could be really helpful. Could you perhaps merge main again in your branch, or rebase? We already cleaned up some folders and just merged a cleaned up version of the urdf, thus if you can rebase than it's easier to review.

[StoneT2000]

Hi lemme try to get to this soon. I just saw that LeRobot had some huge changes which also break the old simulation URDFs since one of the axes is now flipped again and some joint angle's 0 position is changed

[StoneT2000]

I'm having issue with the simulation modelling where the "elbow_flex" joint in the real world seems to be off by 5-8 degrees.

I've tried calibrating my SO100 multiple times but each time when it is in this position, the elbow_flex joint reads out to be 97 degrees instead of 90.

This is a decently large discrepancy at the moment. I don't know whether 1. the URDF should reflect this behavior or 2. the calibration process is off by a bit.

Also asking around discord to see what other community members get after their calibration

[StoneT2000]

The position the robot is in, and the joint angle reads 97. I am not using the normalized -100 to 100 mode, using degrees.

I would expect this to read 90

[StoneT2000]

One more blocker I just found is that So100 in lerobot only has the option to output normalized joint angles from 0 to 100 for the gripper. Other joints can be configured to output raw joint angles.

This makes it incompatible with simulation unless the simulator writes lerobot specific code to read the calibration file as well. I feel like this is worth fixing in LeRobot to make the use_degrees mode for SO100 to mean also to use degrees for the gripper as well. I made an issue about that here: huggingface/lerobot#1259

[pkooij]

The new "0" position is the position in middel of the joints range. Shown 9 seconds in this video: https://huggingface.co/docs/lerobot/so101#calibration-video. But is set in middle of a robot range, Thus is range is -90 degrees to +100 degrees. The "0" will be at +5 degrees.

[StoneT2000]

Ah so the offset i saw earlier is the intended behavior

I will try to model this in the URDF as well then

Do the motors have some kind of absolute encoding? Is it exactly 5 degrees? I guess I am getting something like 7 degrees but that's also just me eyeballing the real robot to see how far it is from what I expect to be 90 degrees and comparing it with the printed outputs

[pkooij]

@StoneT2000 When you have to move tho the middle position as first step of calibration we explicitly set the virtual zero of ll motors at the other side of that position (180degrees). This is because the Feetech motors only work well in single turn mode thus we have to make sure to not cross the virtual zero boundary. But this is only the case with raw motor ticks. Not for the abstraction for the model which is just [-100...100] or [0..100]

[michel-aractingi]

Hey @StoneT2000 I just had a chat with @pkooij around the issue with the third joint.
The issue with that the current ranges not balanced for this joint, the middle pos will always be shifted by 5 degrees.

  <joint axis="0 0 1" name="3" type="hinge" range="-1.7453292519943286 1.5707963267948974" class="sts3215"/>

For now its better if we calibrate the third joint at a symmetric position for the max to the min and not flex it over the limit.

Or we can add an offset of 5 degrees for that joint.

[StoneT2000]

How would you calibrate it in such a way that it doesn't flex over the limit accurately?

I guess my concern is we would need some consistency between hardware. Being able to get everyone's robots calibrated by moving to the limit helps ensure some consistency?

and we can just model that 5 degrees offset as a result (and same thing to be done for gripper joint).

[StoneT2000]

Me and some students in my lab are doing more sim2real testing with so100 and so101, will open another PR based on the latest urdfs in this repo to verify the urdfs are accurate in the future.

I think we may have found a few issues in so 101 already, will update when we finalize it as well: haosulab/ManiSkill#1171