-
Notifications
You must be signed in to change notification settings - Fork 287
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
Consider supporting transmission constraints #1047
Comments
Hello, I am working on a robot where we would like to be able to model transmissions. I was wondering what the current progress on this topic is and if it is being pursued. We know that we can add a transmission property in our urdf, but it would be nice if DART can model this property as well. |
This sounds like mimic joints (defined by URDF), which is already implemented by @costashatz in #1178! @mxgrey Could you verify if you meant it and close this issue if so? |
Here is the urdf page on transmissions to clarify on what I meant by transmissions. |
I believe the mimic joint added in #1178 can satisfy what I meant by "transmission constraint" in this issue. The URDF concept of a "transmission" is a bit different, because it seems the joint force is being transmitted from an "actuator". DART doesn't currently make a significant distinction between an actuator and a joint. Also the mimic joint is a position-based constraint whereas the URDF transmission seems to be a power-based constraint. |
We can easily integrate the SimpleTransmission interface that ROS has (and is the most frequent). But then for each different transmission, we should create different constraints (as they do in ROS). If you want, I can do it for the simple transmission and see how it works.. |
@costashatz @mxgrey I guess another way to elaborate on this question is "Is it simulating a 1:1 mechanical gear between joints?" |
No it does not. Creating mimic joints in forces is "easy" and you can do it in your controller (just "mirror" the commanded torque/command). The implemented mimic joints are enforcing position constraints (taking into account all the limits of the robot: forces/velocities/joint limits) which is a harder problem and needs to go inside the optimization for the physics step. |
Thanks for the answer!
|
No.. You should:
This procedure is not perfect, but should get you close to what you want. |
@costashatz Thanks for the reply. If you just create the two joints with the Force type and copying the torque command, wouldn’t it preserve kinematic constraints between the two joints? |
Real robots often have transmissions between joints, which may have properties like gearing ratios and backlash. There can also be mechanisms where multiple joints are coupled. A common example of this is underactuated robot grippers where a 1-DOF motor controls several multi-jointed fingers simultaneously.
I don't know how difficult it would be to implement this type of constraint on top of Featherstone's ABA, but I think it would be good for us to investigate it, and implement it if it turns out to be feasible.
The text was updated successfully, but these errors were encountered: