[WIP] Add Kinematic Tag

[jcmayoral]

I am using dart together with the Gazebo Simulator. And there is a kinematic tag that allows certain links to ignore external forces, like inertia and acceleration.

---

Before creating a pull request

• [x] Document new methods and classes
• [x] Format new code files using ClangFormat by running make format
• [x] Build with -DDART_TREAT_WARNINGS_AS_ERRORS=ON and resolve all the compile warnings

Before merging a pull request

• [x] Set version target by selecting a milestone on the right side
• [x] Summarize this change in CHANGELOG.md
• [ ] Add unit test(s) for this change
• [ ] Add Python bindings for new methods and classes

[jslee02]

You may not need to add a new joint type in that case. Consider specifying the actuator type as either ACCELERATION, VELOCITY, or LOCKED and set the kinematic values (position, velocity, acceleration) as needed:

https://github.com/dartsim/dart/blob/56f0d4e9f6d6b0869fa76a1e6f221bb7afb956ae/dart/dynamics/Joint.cpp#L50-L56

The joint types (Free, Ball, Revolute) define the joint spaces and how to map the joint space to the joint motion in Cartesian space. However, whether the joint is treated as a kinematic or dynamic joint is determined by the actuator type. Actuator types such as FORCE, PASSIVE, SERVO, and MIMIC are used for dynamic joints, where the solver solves for forward dynamics given q, dq, and tau to find ddq. In contrast, other actuator types are used for kinematic joints, solving for inverse dynamics given q, dq, and ddq to find tau.

[jcmayoral]

Thanks for answering, I have been testing how to do that. However, I get into trouble when trying to set the velocity to a FreeJoint. It does not move for a reason when I set other actuator type. Anyhow, I want to ignore the acceleration and set the velocity on cartesian space directly. The FreeJoint seems to consider anyway the accelerations to be able to move.

The Kinematic Joint class that I am proposing ignores the acceleration and set the Velocities to the Joint directly. I wanted to add another class for that to avoid affecting the current behavior of dart.

[jslee02]

Hm, would setting the acceleration to zero not achieve the desired behavior in this case?

Regardless, it would be helpful if you could create a unit or integration test that demonstrates the behavior you're trying to achieve. This would make it easier to identify any bugs or gaps in the existing features and add new functionality as needed. Additionally, having a clear example of your desired outcome will help ensure that we understand your requirements correctly.

[jcmayoral]

I will handle your comments, and come back.

[jcmayoral]

What I need to accomplish is this tag for Gz sim simulator. Kinematic Tag. Which is a Link that is not affected by forces or accelerations, so essentially the Link I introduced here ignores the acceleration and set the speed to the joint. Meanwhile joint controls is not lost.

I plan to introduce this change over here Gz-Physics MR And it is likely by the way this is done to introduce this KinematicJoint.

[jslee02]

Thank you for sharing the context. However, I'm still not quite following why a new joint type is needed, as I believe it can be achieved by using a proper actuator type. To move forward, could you please add tests or examples that show what you want to achieve that fails with the current feature but succeeds with this new joint type?

[jslee02]

Or, as this code is not used directly in this repo, you could consider having it in a downstream repository as a stopgap solution to unblock your work. I'm still interested in addressing your issue using built-in DART code, so we can revisit this later whenever you're ready.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.6% Duplication on New Code

See analysis details on SonarQube Cloud

[jslee02]

Hi @jcmayoral -- thanks again for digging into this use case. I’ve opened https://github.com/dartsim/dart/pull/2112 that keeps the existing FreeJoint but fixes the workflow you described:

• FreeJoint::setSpatialVelocity and setSpatialAcceleration now route through the generic joint setters so VELOCITY (and ACCELERATION) actuator commands stay in sync instead of being overwritten.
• There’s an integration test added that zeroes gravity, drives a FreeJoint via setSpatialVelocity, reapplies the command each step, and checks both the spatial velocity and translation, matching the Gazebo scenario you outlined.

This should demonstrate that the existing joint fully supports the kinematic control you needed without introducing a new joint type. Let me know if you see anything missing or if there’s another corner case you’d like covered.