[MuJoCo] enable to use mujoco simulator

[sugikazu75]

what is this

simulation interface for mujoco simulator.

usage

cd ~/ros/jsk_aerial_robot_ws
rosdep install -y -r --from-paths src --ignore-src --rosdistro $ROS_DISTRO
catkin build

then,

roslaunch dragon bringup.launch real_machine:=false simulation:=true headless:=false mujoco:=true 

mujoco_dragon.mp4

TODO

• test under actuated robots which use flight controller in spinal (e.g. hydrus)
• path CI test

[tongtybj]

@sugikazu75

I found that following command is not support in ubuntu:xenial with ros kinetic.

jsk_aerial_robot/aerial_robot_simulation/scripts/convert.py

Line 51 in 9828fd1

bpy.ops.wm.collada_import(filepath=input_file)

This cuase following error, which I think the version of blender (2.75) is too old or has some bug.

  File "/home/ros/aerial_robot_ws/src/aerial_robot_3rdparty/mujoco_ros_control/scripts/convert.py", line 49, in process_subdirectories
    bpy.ops.wm.collada_import(filepath=input_file)
  File "/usr/share/blender/scripts/modules/bpy/ops.py", line 189, in __call__
    ret = op_call(self.idname_py(), None, kw)
AttributeError: Calling operator "bpy.ops.wm.collada_import" error, could not be found

After a lot of trial and consideration, I decide to give up to convert collada to stl in kinetic distribution which is no longer used by our current active members.

But we still need to pass CI for kinetic distribution. So I am going to add a condition processing that skips the conversion in the CMakeLists.txt for each robot.

[sugikazu75]

But we still need to pass CI for kinetic distribution. So I am going to add a condition processing that skips the conversion in the CMakeLists.txt for each robot.

@tongtybj I agree with you.

[tongtybj]

@sugikazu75

can you add a rostest that uses MuJoCo for mini_quadrotor?

https://github.com/jsk-ros-pkg/jsk_aerial_robot/blob/master/robots/mini_quadrotor/test/CMakeLists.txt

[sugikazu75]

I found that mujoco model include error is occuring in rostest.
https://github.com/jsk-ros-pkg/jsk_aerial_robot/actions/runs/6562747138/job/17825420492#step:5:8831
https://github.com/jsk-ros-pkg/jsk_aerial_robot/actions/runs/6562747138/job/17825420492#step:5:8836
But it doesn't occur on real computer.

[tongtybj]

@sugikazu75

Yes, it is absolutely wired.
I am going to find reason with tongtybj@1bffcfb

[tongtybj]

@sugikazu75

Interesting result:

+ ls /home/runner/catkin_ws/src/jsk_aerial_robot/robots/mini_quadrotor/mujoco/
ls: cannot access '/home/runner/catkin_ws/src/jsk_aerial_robot/robots/mini_quadrotor/mujoco/': No such file or directory

https://github.com/tongtybj/aerial_robot/actions/runs/6605040325/job/17939813433#step:5:7544

[tongtybj]

#557 (comment) is solved by sugikazu75#3

[sugikazu75]

@tongtybj
Thank you for your contribution.
I added bug fix in mujoco_ros_control and confirm CI is passed in sugikazu75/jsk_aerial_robot@46049ae.

I want you to merge JSKAerialRobot/aerial_robot_3rdparty#14 and JSKAerialRobot/aerial_robot_3rdparty#15.

[tongtybj]

@sugikazu75

I have merged JSKAerialRobot/aerial_robot_3rdparty#14 and JSKAerialRobot/aerial_robot_3rdparty#15.

[tongtybj]

LTGM

[tongtybj]

This line causes following error in catkin-lint, because this directory would not appear before build.
https://github.com/jsk-ros-pkg/jsk_aerial_robot/actions/runs/6167161992/job/16737709229?pr=557#step:6:86

So, I suggest move the installation of mujoco to https://github.com/JSKAerialRobot/aerial_robot_3rdparty, and refer to https://github.com/JSKAerialRobot/aerial_robot_3rdparty/tree/master/3rdparty/osqp to insatall mujuco header files and libraries.

[tongtybj]

If you agree with this idea, we can also move aerial_robot_simulation/src/mujoco_ros_control.cpp and aerial_robot_simulation/src/mujoco_visualization_utils.cpp to https://github.com/JSKAerialRobot/aerial_robot_3rdparty/tree/master

[tongtybj]

@sugikazu75 Please consider the headless mode for mojuco. The most straightfoward way is to comment out the related codes if the headless flag is true. headless flag can be set from rosparam

[tongtybj]

@sugikazu75

Eventually, we succeed to merge this PR as a new milestone for our system. Thanks for your tremendous effort!

BTW, I hope you can draw a new diagram about our simulation system based on UML proposed in #565 .