dartsim: Add support for the <kinematic> tag

[jcmayoral]

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

🎉 New feature

Bring back the kinematic tag available in gazebo classic.

Summary

Adding the kinematic tag feature for dartsim physics engine. The dart joints used in gz-physics are called FreeJoints, available in dart upsteam repository in this file FreeJoint.cpp . However, as it can be observed, this joint is designed to integrate accelerations over time to calculate speed, and integrate speed to get positions. Therefore, other type of joint is needed to achieve the behavior of the Kinematic tag which ignores Forces.

In this MR for dart, an attempt to integrate this joint to the upstream repository can be found, but it seems the use case is really gazebo-related, also it will require to bump the dart version used on gz-physics. Therefore, those changes are integrated to this one MR, adding the KinematicJoint as a customization of dart (based on the feedback given on the dart MR (KinematicJoint.cc and KinematicJoint.hh).

Test it

In order to test, the MR can be compiled and using the following sdf (attached as a txt file):

kinematic-robot.sdf.txt

Once compiled, rename the file to kinematic-robot.sdf, and run

gz sim -v 4 kinematic-robot.sdf

A comparison between setting the kinematic tag (true/false) can be seen in the next video.

kinematic-tag-demo-2025-07-09_19.08.49.mp4

Checklis

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

[jcmayoral]

Same as #756

A comparison between kinematic and non-kinematic collision with static box

kinematic-tag-demo-2025-07-09_19.08.49.mp4

[azeey]

See #756 (comment)

[azeey]

@jcmayoral can you update the PR description?

[azeey]

cc @iche033

[jcmayoral]

@azeey Is there a feature list of a issue list I can refer to? So I can complete the description?

[jcmayoral]

Checking the test I found that the Bazel CI was failing because of this line:

[3,384 / 3,394] 48 / 57 tests, 1 failed; Compiling dartsim/src/KinematicsFeatures.hh; 7s processwrapper-sandbox ... (4 actions running)

But I did not modify that file. Is it part of the pipeline?

[azeey]

@azeey Is there a feature list of a issue list I can refer to? So I can complete the description?

If there's no issue, you can skip that, but please add more description on what this PR does, and the approach you are taking. Also remove the parts of the template that are not relevant (i.e, bug fix and release sections). You can look at other PRs in this repo for reference.

[jcmayoral]

@azeey I just updated it. Please, let me know if something is missing.

[azeey]

@jcmayoral After looking at the discussion in the upstream DART PR, I tested out what setting the joint actuator type to ACCELERATION would do and I think it does make the link "kinematic". For the quickest test, I added

  joint->setActuatorType(dart::dynamics::Joint::ACCELERATION);

to

gz-physics/dartsim/src/SDFFeatures.cc

Lines 725 to 726 in d604919

	joint->setTransform(tf);

right after joint->setTransform(tf); , which makes sets the actuator type of all free joints to ACCELERATION. With this, I ran the velocity_control.sdf Gazebo example. The vehicles respond to velocity commands, but are not affected by gravity or contacts.

Screen.Recording.2025-08-20.at.00.58.24.mp4

Can you give it a try? Maybe all we need need to do is detect if a link is kinematic and set the actuator type of it's parent joint to ACCELERATION.

cc @iche033

[azeey]

This would be a great addition to Gazebo, but it's a large change and we're not sure about the approach taken. With
Code freeze being Monday, 08-25-2025 (see https://discourse.openrobotics.org/t/feature-freeze-for-gazebo-jetty/48187/3?u=azeey), I don't think we'll have enough time to discuss, make changes and merge this PR. Therefore, I'll remove the "Jetty Release" milestone. This means, we can't merge this until Jetty is released, however, please continue making progress on the PR and we'll try to respond as much as we can.

[moriarty]

@azeey it's unfortunate that this will miss the code freeze.

We originally needed the kinematic tag and had been commenting and working on top of this MR: #618 from @iche033 which adds kinematic tag for bullet but as we moved further along with our migration we realized we had behaviors which require us to use Dartsim.

What are the possibilities or options to have something like this back-ported to jetty?

[azeey]

What are the possibilities or options to have something like this back-ported to jetty?

It's should be possible to backport since the changes shouldn't break API/ABI. We might even be able to backport it to Ionic/Harmonic.

[moriarty]

Great, Thanks. We've been testing Harmonic / Ionic via source builds but if this had made it into Jetty it would have clearly given us a reason to target Jetty ASAP...

Need to get over the migration we still have performance related issues where Gazebo Classic out performs Gazebo in most cases unless you have GPUs, but this <kinematic> tag support is a key blocker and is required to work around a bunch of other things.

[azeey]

Yes, I also really wanted to get this PR in, but I don't think it's realistic with the time constraints we have.

Regarding performance issues, not sure what y'all have already tried, but I would suggest trying:

1. Using the Ogre1 render engine if you don't have a GPU
2. Increasing the time step size. Most of our examples use 0.001, but DART can be stable at higher step sizes. For the SubT competition, we used 0.004 for example.

[moriarty]

Yes, I also really wanted to get this PR in, but I don't think it's realistic with the time constraints we have.

Regarding performance issues, not sure what y'all have already tried, but I would suggest trying:

1. Using the Ogre1 render engine if you don't have a GPU
2. Increasing the time step size. Most of our examples use 0.001, but DART can be stable at higher step sizes. For the SubT competition, we used 0.004 for example.

Yes we've switched to Ogre1 without the GPU

I'll chekc on the step size, thanks