Launch params and some other confusion

[zichunxx]

Hi! @DavidPL1

I have dived into this repo for a while and have some confusion. It would be great to get your guidance when you are free.

• In the launch_server.launch file, headless, render_offscreen, and no_x args are listed. I've tried some combinations between them when roslaunch. It seems to me that these parameters are all related to making Mujoco render in the background or not. If so, is it possible to use only one parameter?

• In the README.md file, I have noticed that

To prevent action servers ignoring actions for a limited time after resetting the simulation, until ros/actionlib#203 is merged, you need to build the PR branch and any packages implementing action servers (like MoveIt) yourself. Additionally, for the Franka Emika Panda robot, until frankarobotics/franka_ros#292 is merged, you need to build the PR branch yourself, otherwise controlling the robot after time resets is buggy.

Thus, I have built the PR branch of actionlib. However, I'm struggling to make the mujoco_node link against the source code of actionlib instead of the binary. Besides, I didn't find the dependence of the actionlib in this CMakeList.txt.

• I have little experience debugging such a big project. For some small projects, debugging with gdb is enough. I tried to debug this mujoco_node with the necessary launch prefix and gdb, but I think this is inefficient and unintuitive to watch some variables' values. Meanwhile, when debugging with gdb, I'm busy confirming the location of breakpoints and encountering some errors, like no such files. I'm used to debugging with the ROS extension in VSCode, but it seems that this extension has many bugs that make it unsuitable for this kind of big project. Certainly, I might be inexpert. I would like to get some advice about debugging such a big project from an expert like you.

Looking forward to your reply! Thanks in advance!

[zichunxx]

For this question,

Thus, I have built the PR branch of actionlib. However, I'm struggling to make the mujoco_node link against the source code of actionlib instead of the binary. Besides, I didn't find the dependence of the actionlib in this CMakeList.txt.

currently, I have realized this by configuring the workspace chain which includes the workspace for the PR branch of actionlib (actionlib_ws). Besides, I've tried to directly link against actionlib_ws in the CMakeLists.txt and it hasn't worked so far.

[DavidPL1]

I am planning to write a tutorial for the build process and the launchfile parameters, but due to my current workload that might take some time, so I'll give you the short version here:

---

In the launch_server.launch file, headless, render_offscreen, and no_x args are listed. I've tried some combinations between them when roslaunch. It seems to me that these parameters are all related to making Mujoco render in the background or not. If so, is it possible to use only one parameter?

There are two different types of rendering: offscreen and onscreen. Offscreen rendering is used to render images of cameras defined in a loaded mujoco model and to be able to broadcast them over ROS. Onscreen rendering means just rendering the GUI.
The default enables both on- and offscreen.
If you don't need the GUI (e.g. in an automated train or evaluation environment), you can toggle headless to save some resources and maybe speed up the simulation.
In case you don't need to broadcast camera images, you can disable render_offscreen, this will skip creating the resources needed to do so. Note though, that if you don't subscribe to the image topics, no images will be rendered anyway. So this is also more of a memory usage optimization.

Additionally there is no_x, which was included to disable any rendering. This was added in an earlier version, as with both headless mode and render_offscreen disabled the program would still try to setup glfw resources, which require a configured desktop. This option would then fully disable glfw. I am not sure this is still necessary after the recent rewrite (I should check on that), but at the least this can be used as a shorthand to disable both on- and offscreen rendering.

---

Thus, I have built the PR branch of actionlib. However, I'm struggling to make the mujoco_node link against the source code of actionlib instead of the binary. Besides, I didn't find the dependence of the actionlib in this CMakeList.txt.

I will add the dependency to ensure the correct build order in a shared workspace, thanks for the hint.

currently, I have realized this by configuring the workspace chain which includes the workspace for the PR branch of actionlib (actionlib_ws). Besides, I've tried to directly link against actionlib_ws in the CMakeLists.txt and it hasn't worked so far.

To make your mujoco_ros workspace use the results-space of actionlib_ws you should configre your mujoco_ros workspace to extend it. This can be done by running catking config --extend PATH_TO_ACTIONLIB_WS in your mujoco_ros workspace. Alternatively, you can just directly move the actionlib sources into the mujoco_ros workspace.

---

have little experience debugging such a big project. For some small projects, debugging with gdb is enough. I tried to debug this mujoco_node with the necessary launch prefix and gdb, but I think this is inefficient and unintuitive to watch some variables' values. Meanwhile, when debugging with gdb, I'm busy confirming the location of breakpoints and encountering some errors, like no such files. I'm used to debugging with the ROS extension in VSCode, but it seems that this extension has many bugs that make it unsuitable for this kind of big project. Certainly, I might be inexpert. I would like to get some advice about debugging such a big project from an expert like you.

I've also had problems using the vscode ROS extension for debugging. That's why I'm using gdb directly from the commandline. The launchfile offers using the debug option to start gdb in the running terminal and load mujoco_ros, and the debug_server option to start gdb as a server which you can connect to with either another gdb instance or some other program.

Hope this helps

[zichunxx]

Much appreciated! I totally understand the workload that you face in developing such a big project, so I appreciate that you took the time to answer my question! Likewise, I'm glad that some of my questions can give you some little hints, and I will try to debug as you said.

In addition to the above issues, I tried to launch the moveit_demo.launch directly. After some attempts, I found that use_sim_time:=true seems to prevent the MoveIt GUI from launching.

[DavidPL1]

In addition to the above issues, I tried to launch the moveit_demo.launch directly. After some attempts, I found that use_sim_time:=true seems to prevent the MoveIt GUI from launching.

I think that either setting unpause:=true, calling the unpause service, or unpausing using the GUI will solve that problem. Some components in the planning ecosystem wait for messages at a valid time (i.e. > 0), which will not happen until the simulation is unpaused. Using use_sim_time:=false in this case leads to serious issues when the $\Delta t$ you the controllers are using and the actual $\Delta t$ diverge (if your PC is too slow in calculating efforts for a timestep).

---

I've started setting up a wiki with some documentation currently located here. I just started writing some basic info, so it is quite empty yet, but feel free to have a look.

[zichunxx]

Thanks! @DavidPL1

Besides, I think this part should be added with

    <include file="$(find franka_mujoco)/launch/panda.launch" pass_all_args="true">
        <arg name="controller" default="$(arg transmission)_joint_trajectory_controller" />
    </include>

to successfully launch MoveIt along with the corresponding controller being found.

Btw, I have sent a PR for mujoco_ros_pkgs to fix the instruction in README.md, please check.

[DavidPL1]

Besides, I think this part should be added with

    <include file="$(find franka_mujoco)/launch/panda.launch" pass_all_args="true">
        <arg name="controller" default="$(arg transmission)_joint_trajectory_controller" />
    </include>

to successfully launch MoveIt along with the corresponding controller being found.

correct. I fixed it in ubi-agni/franka_ros_mujoco@19d8fce

Btw, I have sent a ubi-agni/mujoco_ros_demos#2 (comment) for mujoco_ros_pkgs to fix the instruction in README.md, please check.

Done