Add transmission ratio to revolute joint

[sherm1]

It is common in actuated joints for there to be a transmission ratio between the input and output shafts (@rcory needs this now). In cases where the transmission details don't matter (typical), we can easily incorporate this ratio into a revolute joint at zero cost. Proposal with three separate tasks (just the first one would be a good start):

• add transmission_ratio (signed) to revolute joints, with a suitable API for setting it programmatically, and unit tests to prove that it actually works!
• read this from .sdf, where the closest thing is a gearbox joint with a gearbox_ratio parameter where output = -gearbox_ratio * input (see here).
• read this from .urdf. Looks like the <mechanicalReduction> tag in the <transmission> element is the closest match (see here). Not clear to me how the sign is treated.

Implementation

Currently the hinge matrix for a revolute joint is H=[0 0 1 0 0 0]ᵀ. A reduction of 100:1 would require only that we change to H=[0 0 0.01 0 0 0]ᵀ, with a matching change to to the pose calculation (a negative ratio would incorporate a direction change also). This will magically produce the expected reflected inertia, with no bogus messing with mass properties (as suggested, for example, in Featherstone 2008 at the end of §9.6).

(Nope, see discussion below. We'll use the r²I approximation instead where r is the reduction factor and I the inertia of the motor's hidden rotor.)

[sherm1]

Note (thanks to @yangwill): MuJoCo handles this in a crude way with a joint attribute called "armature" which simply adds a fixed value to the mass matrix diagonal for that joint dof's generalized coordinate.

[amcastro-tri]

As commented in #13657, I believe we'd like:

• JointActuator::motor_inertia and,
• JointActuator::gear_ratio

Those two values is what we'd need to compute proper reflected inertias and place them at the right dofs.

[sherm1]

@amcastro-tri can you clarify the semantics you have in mind? My understanding is that a motor on a revolute joint has two visible rigid bodies: a case attached to the parent body and an output shaft attached to the child (with internal gearing). The physical mass properties of those rigid bodies are normally included in the parent and child mass properties. Then the gear ratio incorporated in the H matrix accounts for the reflected inertia. So it's not clear to me what the "motor inertia" would be doing here?

In contrast the proposal in #13657 would be to add user-supplied inertias directly to the mass matrix diagonals, similar to MuJoCo's "armature" feature.

[amcastro-tri]

The physical mass properties of those rigid bodies are normally included in the parent and child mass properties.

Per f2f. What's missing in that picture is a third body, the motor's rotor. That body spins way faster than the output shaft and it effectively has the effect of an added or reflected inertia attached to the output shaft (the child body). In this approximation the small rotor inertia Im and gear ratio r are swapped by a simple model where there is no motor nor gears but we attach a fat heavy disk having inertia r²*Im rigidly attached to the outer shaft and spinning with it.

[sherm1]

I resurrected my branch that has the above (crossed out) hinge matrix modification hack (used in examples/multibody/pendulum/passive_simulation). As Alejandro explained, it does not represent the reflected inertia properly, just the torque magnification. Also a quick Slack survey of roboticists here makes it clear that they expect torque control and generalized velocity to represent the output torque and rate, not the torque and rate at the motor's rotor as I modeled above. So I think we should use the r²I approximation which can be added to the mass matrix diagonals or included directly during O(n) recursive sweeps for forward or inverse dynamics. When the approximation is not adequate, the rotor body should be included explicitly in the model with its own dof, and the rotor and output shafts coupled with a constraint. (We could optimize that away with no approximation later if we needed to.)

Thanks for straightening me out on this, @amcastro-tri !

[amcastro-tri]

ah, great! thanks for double checking @sherm1 and for following up on asking our local roboticists.

[yangwill]

Also a quick Slack survey of roboticists here makes it clear that they expect torque control and generalized velocity to represent the output torque and rate, not the torque and rate at the motor's rotor as I modeled above. So I think we should use the c²I approximation which can be added to the mass matrix diagonals or included directly during O(n) recursive sweeps for forward or inverse dynamics.

This sounds like exactly what I'm looking for, so feel free to close #13657. Before I was concerned that the torque and generalized velocities representing the motor torque and velocity would cause future headaches.

[mposa]

I'll add my thumbs up to the proposed solution (and choice of coordinates).

[mitiguy]

I am unclear about this issue and whether I fully understand the various viewpoints expressed previously.
My current understanding (through conversations with @sherm1 and @rcory) is summarized below.
The views below are my own (hopefully, not mischaracterizing Rick or Sherm).

1. Robot links can be connected by motors with gearboxes.
2. A motor and gearbox can be purchased as separate units.
3. A motor and gearbox can be purchased as a single unit.
4. The model of a motor is one thing.
5. The model of a gearbox is another thing.
6. The model of a combined motor with gearbox is yet another thing.

Three things that help characterize the connection between the robot links associated with the motor and gearbox.

1. Speed ratio.
2. Torque ratio.
3. Reflected inertia (e.g., appropriate entries in the mass matrix).

Note: Rick and I discussed this issue at HQ last Fall. Rick is not waiting for resolution of this issue. It is not blocking his progress. Currently, this issue is a very low priority for him. Rick responded to the Slack survey (mentioned above), but did not know it was related to this issue.

It would be helpful to know if this issue is for a motor or motor and gearbox combo.

[amcastro-tri]

@mitiguy, for "motor and gearbox combo" as you put it. The discussion above is about a very commonly used model by roboticists, see reference to Featherstone 2008 (chapter 9.6) in #13657. The book describes the approximation in detail.

The biggest thing, summarizing the discussions, is that given that gear ratios are usually very high in robotics, the "effective" inertia of the motor, which is spinning real fast due to this reduction, can now not be ignored. That is, it is pretty much as if I had just placed a heavy inertia wheel attached to the output shaft. Because of this, sims become a lot more stable (typical example; my very low mass finger grippers actuated by a very stiff PID controller. This today limits the step size in our sims. This would solve that).

[mposa]

Any updates/timeline on this issue? @yminchen and @yangwill are finding notable discrepancies between Cassie and sim, with more realistic performance out of MuJoCo which does capture this motor inertia.

We'd look at it ourselves, but I'm concerned that it's pretty far into the MBP weeds where we're not that familiar.

[sherm1]

Its not on the schedule yet, @mposa. @joemasterjohn what do you think about tackling this smaller project before the joint locking stuff? @mitiguy could advise on unit tests.

[edrumwri]

I see the reflected inertia being implemented (great!) Our robot has significant motor inertias and low gear ratios (10:1) but we still want to be able to model both more accurately than is capable at present in sim. So you have another eager customer!

Are you yet able to provide a timeline @joemasterjohn?

[mitiguy]

Hi Evan. @edrumwri. Joe is doing great -- and he is in front of this (I am lagging).I am currently on the critical path -- as a reviewer.
Thank you for voting in as an important issue. I will get to it ASAP and make it a top priority.

[joemasterjohn]

@yangwill @mposa @edrumwri Just wanted to let you know that #14167 merged this morning, and with that the reflected inertia feature is added. Please take it out for a test drive whenever you get the chance, the documentation can all be found in JointActuator class. I also have a PR in flight #14323 to add parsing for the added parameters to the SDF and URDF parsers.

[yangwill]

@joemasterjohn , thank you for implementing this! We've been using this PR in our Cassie simulation and the motions seems qualitatively much more similar to what we're seeing in hardware.

[akhilsathuluri]

Cannot access rotor_inertia and gear_ratio through the JointActuator class in python. Looks like they are not yet available in python and hence no associated documentation too. Will these be available in python soon or am I missing something?

[sherm1]

@joemasterjohn want to add these?

[sherm1]

Only the pybindings are left; replaced this with narrower #18335.