Skip to content

Conversation

@saikishor
Copy link
Member

@saikishor saikishor commented Dec 20, 2025

This PR bumps the mujoco version to 3.4.0.

The idea is once the CI is good here, I will also bump the mujoco_vendor and make releases

Closes: #22

@saikishor
Copy link
Member Author

saikishor commented Dec 20, 2025

@eholum @eholum-nasa The failing build is due to the removal of InjectNoise method in 3.1.4 to have determinisim in the simulator, however, if needed, the user can add noise manually to the sensors via XML tags : https://mujoco.readthedocs.io/en/3.1.4/changelog.html#general. However, it is back later

image

What should we do in this case?

Weirdly, it is failing now

P.S. I found the breaking API in version 3.3.7

@saikishor
Copy link
Member Author

I would like to take a decision before any further syncs

@saikishor
Copy link
Member Author

I later checked the codebase and realized that there was a commit introduced in 3.3.7 version of mujoco : google-deepmind/mujoco@401bf43#diff-3dc22ceeebd71304c41d349c6d273bda172ea88ff49c772dbdcf51b9b19bbd33R2943 has introduced a undocumented API break, but setting it to -1 everything works as usual. I'll open a PR to update their documentation

@saikishor
Copy link
Member Author

I've proposed to update their changelog : google-deepmind/mujoco#2996

@saikishor
Copy link
Member Author

@eholum-nasa everything good now ;)

Copy link
Contributor

@eholum eholum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! There are some nice updates in that changelog so looking forward to trying some of them out...

I still think the entire CMakeLists.txt will be cleaned up a bit when the vendor package comes out, but I'm not sure how different versions will affect the need for the macro?

// Use mjVERSION_HEADER and if it is greater than 337 then do one thing or another
// Needed due to
// https://github.com/google-deepmind/mujoco/commit/401bf431b8b0fe6e0a619412a607b5135dc4ded4#diff-3dc22ceeebd71304c41d349c6d273bda172ea88ff49c772dbdcf51b9b19bbd33R2943
#if mjVERSION_HEADER < 337
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgive my ignorance here, should we just enforce that the header version match exactly what we expect in the CMakeLists.txt file? Would that make this conditional go away?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but this allows people to go back to the older version and they don't have to touch the code to know what to fix. So, I would say it is better to have it handled also in the code

Copy link
Contributor

@eholum eholum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WFM!

@saikishor
Copy link
Member Author

Thanks. I'll go ahead and merge it then ;)

@saikishor saikishor merged commit d81dba5 into ros-controls:main Dec 21, 2025
5 checks passed
@saikishor saikishor deleted the bump_mujoco_version branch December 21, 2025 17:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Upgrade MuJoCo to v3.4.0

2 participants