dartsim / dart

DART: Dynamic Animation and Robotics Toolkit
http://dartsim.github.io/
BSD 2-Clause "Simplified" License
895 stars 286 forks source link

Consider supporting transmission constraints #1047

Open mxgrey opened 6 years ago

mxgrey commented 6 years ago

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.

acxz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

mxgrey commented 5 years ago

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 commented 5 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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