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

Consider supporting transmission constraints #1047

Open
mxgrey opened this issue Mar 30, 2018 · 10 comments
Open

Consider supporting transmission constraints #1047

mxgrey opened this issue Mar 30, 2018 · 10 comments
Labels
help wanted Indicates wanting help on an issue or pull request priority: low no timeline yet tag: feature request Indicates new feature requests

Comments

@mxgrey
Copy link
Member

mxgrey commented Mar 30, 2018

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.

@mxgrey mxgrey added priority: medium should be resolved before the next release tag: feature request Indicates new feature requests comp: dynamics help wanted Indicates wanting help on an issue or pull request labels Mar 30, 2018
@acxz
Copy link
Contributor

acxz commented Feb 17, 2019

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.

@jslee02
Copy link
Member

jslee02 commented Feb 18, 2019

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?

@acxz
Copy link
Contributor

acxz commented Feb 18, 2019

Here is the urdf page on transmissions to clarify on what I meant by transmissions.

@mxgrey
Copy link
Member Author

mxgrey commented Feb 18, 2019

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.

@costashatz
Copy link
Contributor

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..

@junhyeokahn
Copy link

junhyeokahn commented Oct 18, 2021

@costashatz @mxgrey
Hello, just have a quick question on the mimic joints.
It looks like mimic joints enforce a position constraint, but does it also transmit the force?
In other words, if I apply 1N to one joint, is the same force applied to the other joint with the position (and velocity) mimicking satisfied?

I guess another way to elaborate on this question is "Is it simulating a 1:1 mechanical gear between joints?"

@costashatz
Copy link
Contributor

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.

@junhyeokahn
Copy link

Thanks for the answer!
So, if I want to simulate a 1:1 mechanical gear with two different joint axes, I could basically

  1. create two separate revolute joints (one actuator type is FORCE and the other actuator type is MIMIC,
  2. set the same amount of actuator force for two joints (e.g, 1Nm).
    Do I correctly understand?

@costashatz
Copy link
Contributor

2. Do I correctly understand?

No..

You should:

  1. Create two separate joints (revolute or whatever type)
  2. Both of them are of type FORCE
  3. In your controller, you only control the first joint (let's call it parent)
  4. Inside the controller (and after all commands have been computed), you get the parent's command force/torque and mimic it for the second joint (let's call it child)
  5. So the child's force/torque is: f_c = a*f_p + b, where a, b are constants (you choose them to enable proper mimicing, e.g. opposite directions), f_c is the control command of the child and f_p is the control command of the parent.

This procedure is not perfect, but should get you close to what you want.

@junhyeokahn
Copy link

@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?
For instance, if we simulate 1:1 gear, the joint velocity should be transmitted as well as the torque from parent to child.

@jslee02 jslee02 added priority: low no timeline yet and removed priority: medium should be resolved before the next release labels Jan 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Indicates wanting help on an issue or pull request priority: low no timeline yet tag: feature request Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

5 participants