Background
There are mainly two categories of users who need mujoco ros2 integration. The first category consists of people who are familiar with ros2 (and probably gazebo) but not with mujoco. The second category includes people who are familiar with mujoco (and probably ros2). When I first started this project, my primary focus was placed on the first user category, mainly because it aligned with my own experience when I was starting to learn mujoco.
I tried to make this package easily accessible to people who are familiar with ros2 and gazebo workflow. To achieve this, I made several design choices: 1) creating ros2_control node that launches mujoco, thereby eliminating the need for user to start it manually, 2) placing most configurations in urdf rather than mjcf files (to open up the possibility of using pure urdf in the future so that users don't need any knowledge on mujoco).
Recently, I'm starting to find that this approach may not use full functionality of mujoco which is very powerful and is the reason why people use mujoco. Also, because simulators such as mujoco are gaining popularity due to emerging technologies such as RL and IL, many users now fall into the second category which means they probably want advanced features than ease of accessibility. There is also standardized interface for ros2 and simulator, which allows users to easily switch between different simulators.
Ideas
Ideally, I want to support both categories of users but if this needs a lot of effort, I would support the second category of users moving forward.
The main idea is to use standard interface to interact with mujoco environment and topic based interface for hardware integration which will make them less coupled.
[This will be updated when I have clearer idea.]
Background
There are mainly two categories of users who need mujoco ros2 integration. The first category consists of people who are familiar with ros2 (and probably gazebo) but not with mujoco. The second category includes people who are familiar with mujoco (and probably ros2). When I first started this project, my primary focus was placed on the first user category, mainly because it aligned with my own experience when I was starting to learn mujoco.
I tried to make this package easily accessible to people who are familiar with ros2 and gazebo workflow. To achieve this, I made several design choices: 1) creating ros2_control node that launches mujoco, thereby eliminating the need for user to start it manually, 2) placing most configurations in urdf rather than mjcf files (to open up the possibility of using pure urdf in the future so that users don't need any knowledge on mujoco).
Recently, I'm starting to find that this approach may not use full functionality of mujoco which is very powerful and is the reason why people use mujoco. Also, because simulators such as mujoco are gaining popularity due to emerging technologies such as RL and IL, many users now fall into the second category which means they probably want advanced features than ease of accessibility. There is also standardized interface for ros2 and simulator, which allows users to easily switch between different simulators.
Ideas
Ideally, I want to support both categories of users but if this needs a lot of effort, I would support the second category of users moving forward.
The main idea is to use standard interface to interact with mujoco environment and topic based interface for hardware integration which will make them less coupled.
[This will be updated when I have clearer idea.]