Switching the wrench compose to rely on two buffers (local and global)#1
Conversation
…nches would not be updated properly when the object would move.
|
@LoreMoretti could you take a look and let me know if this version of the PR works for you guys. I extended the test coverage quite drastically, but if you can think of some other tests let me know. This code is critical and should be bullet proof! |
LoreMoretti
left a comment
There was a problem hiding this comment.
Nice! I'll run a training to check whether our use case is working fine now.
I ran a training. I get a lot of the following warnings: Which do not appear, if I use the v2.3.2 tag of IsaacLab. For a lot of <link_names>. |
|
Hum something is exploding for sure. I could be that the torque correction is problematic when objects are far from the origin. |
|
@LoreMoretti I ran some more test trying the wrench correction at 2000 meters from the origin and comparing to 1 meter and the results are inline. Would you mind sharing a bit more about what's creating this issue? Something like the position at which the force is applied, the frame in which it's applied, and the magnitude? Would it be possible that since the wrenches are now working as expected you're getting increasingly larger wrenches as the robot moves away from the application point of the force. The global force doesn't track the body pose. So if you apply a global force on a body it will default to applying the force in (0,0,0). Which could apply very large torques to the robots far from the application point. |
|
We could make the global forces track the robot position but we'd need another set of buffers to enable that. The feature could be: if no position is provided, global forces are applied at the CoM position of the bodies, forces do not generate a resulting torque, but their magnitude/orientation is expressed in the global frame. |
I have to investigate more on the issue. What I can say is that it was working with no warnings also in v2.3.1, where there was not the wrench composer. I did not investigate on how forces were handled before the wrench composer. Weren't global forces tracking body position there? |
…re cleared on set.
|
They were I just pushed a fix for that: |
|
Let me know if these changes do help with your training. |
Indeed this is the use case I am working on (with also 0 torques) |
|
Early feedback: the behavior is different yet. I will try to provide more details as soon as I can. |
|
Just made these tests to compare to PhysX it looks good It creates two views one for raw PhysX calls, one for composer calls and checks that the behavior is the same. |
|
I would try maybe with the branch before the merge of the composer to see how that goes? Misread that, that would be 2.3.1... That's weird. |
|
I did some more digging, and I can't find the bug. Could you share the mdp you're using to apply forces? |
|
@LoreMoretti any chances you could share with me the mdp that causes problems :) |
|
@AntoineRichard I am sorry for my very late reply. Let me check what I can share and I'll come back to you |
|
Here the Which is called at |

Description
Following up on the comment i made on your PR, I think we need two buffers to handle permanent local and global wrenches properly.
Type of change
Checklist
pre-commitchecks with./isaaclab.sh --formatconfig/extension.tomlfileCONTRIBUTORS.mdor my name already exists there