[BUG] Error when including xacro file in my robot description

[flabrosse]

Ubuntu 22.04, ROS humble, gazebo11

I recently switched from a RealSense Camera to the Oak-D S2 camera. I am now trying to update my robot_description package. In lieu of the few lines to include the RS camera, I now have:

  <xacro:arg name="camera_name"   default="oak" />
  <xacro:arg name="camera_model"  default="OAK-D-S2" />
  <xacro:arg name="base_frame"    default="oak-d_frame" />
  <xacro:arg name="parent_frame"  default="camera_base" />
  <xacro:arg name="cam_pos_x"     default="0.0" />
  <xacro:arg name="cam_pos_y"     default="0.0" />
  <xacro:arg name="cam_pos_z"     default="0.0" />
  <xacro:arg name="cam_roll"      default="0.0" />
  <xacro:arg name="cam_pitch"     default="0.0" />
  <xacro:arg name="cam_yaw"       default="0.0" />
  <xacro:include
    filename="$(find depthai_descriptions)/urdf/depthai_descr.urdf.xacro" />

I soon as I add the xacro:include statement, I get:

[spawn_entity.py-4] [INFO] [1719494086.888412979] [urdf_spawner]: Waiting for entity xml on /robot_description

Something very similar for the RS camera just worked (the major difference being that the RS xacro file just defines the macro which then needs to be run in the external (my) xacro file, while the DepthAI xacro file defines (in self included) and runs the macro).

Any ideas?

[Serafadam]

Hi, could you post full log from the launch file? And would it be possible to see the resulting URDF file? From the looks of it I think it might be due to URDF spawner using /oak/robot_description parameter rather than robot_description which is done to avoid name clashing with multiple camera setups, you probably need to remap that parameter name in your launch file/script.

[flabrosse]

Here is the log, up until the message appears:

$ ros2 launch traethlin_gazebo gazebo.launch.py 
[INFO] [launch]: All log files can be found below /home/ffl/.ros/log/2024-07-03-15-36-46-670808-pcpffl-63252
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [gazebo-1]: process started with pid [63254]
[INFO] [robot_state_publisher-2]: process started with pid [63256]
[INFO] [joint_state_publisher-3]: process started with pid [63258]
[INFO] [spawn_entity.py-4]: process started with pid [63260]
[gazebo-1] Gazebo multi-robot simulator, version 11.10.2
[gazebo-1] Copyright (C) 2012 Open Source Robotics Foundation.
[gazebo-1] Released under the Apache 2 License.
[gazebo-1] http://gazebosim.org
[gazebo-1] 
[spawn_entity.py-4] [INFO] [1720017407.095404993] [urdf_spawner]: Spawn Entity started
[spawn_entity.py-4] [INFO] [1720017407.095613625] [urdf_spawner]: Loading entity published on topic /robot_description
[spawn_entity.py-4] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/qos.py:307: UserWarning: DurabilityPolicy.RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL is deprecated. Use DurabilityPolicy.TRANSIENT_LOCAL instead.
[spawn_entity.py-4]   warnings.warn(
[spawn_entity.py-4] [INFO] [1720017407.096761635] [urdf_spawner]: Waiting for entity xml on /robot_description
[gazebo-1] Gazebo multi-robot simulator, version 11.10.2
[gazebo-1] Copyright (C) 2012 Open Source Robotics Foundation.
[gazebo-1] Released under the Apache 2 License.
[gazebo-1] http://gazebosim.org
[gazebo-1] 
[ERROR] [robot_state_publisher-2]: process has died [pid 63256, exit code -6, cmd '/opt/ros/humble/lib/robot_state_publisher/robot_state_publisher --ros-args --log-level WARN --ros-args -r __node:=robot_state_publisher -r __ns:=/ --params-file /tmp/launch_params_8pmfidhe'].
[INFO] [robot_state_publisher-2]: process started with pid [63408]
[spawn_entity.py-4] [INFO] [1720017407.982737951] [urdf_spawner]: Waiting for entity xml on /robot_description

Edited to show a line that sometimes appears after the urdf_spawner message, that says that the robot state publisher crashes.

[flabrosse]

One thing I forgot to say is that nothing of the robot appears if I include the camera xacro file.

[flabrosse]

Unfortunately the whole urdf file is rather difficult as rather big. The relevant part is:

  <link name="camera_base"/>
  <!-- base_link of the sensor-->
  <link name="oak-d_frame"/>
  <joint name="camera_center_joint" type="fixed">
    <parent link="camera_base"/>
    <child link="oak-d_frame"/>
    <origin rpy="0.0 0.0 0.0" xyz="0.0 0.0 0.0"/>
  </joint>
  <!-- device Center -->
  <link name="camera_model_origin">
    <visual>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="package://depthai_descriptions/urdf/models/OAK-D-S2.stl"/>
      </geometry>
      <material name="mat">
        <color rgba="0.8 0.8 0.8 0.8"/>
      </material>
    </visual>
  </link>
  <joint name="camera_model_origin_joint" type="fixed">
    <parent link="oak-d_frame"/>
    <child link="camera_model_origin"/>
    <origin rpy="1.5708 0 1.5708" xyz="0 0 0"/>
  </joint>

I am not sure how to do the remapping, specifically where to put the command.

[flabrosse]

By the way, when I am running the launch file, there is no topic /oak/robot_description, only /robot_description. This is without a remapping.

[Serafadam]

Hi, just to be sure, robot_description spawns normally when not including the camera xacro?

[flabrosse]

Yes. Also spawns fine when including another camera model such as the realsense.

[Serafadam]

Hi @flabrosse, sorry for the late reply. I was wondering if you could provide some minimal ROS package that could be used to reproduce this issue? I was also wondering if this could be related somehow to STL files, I recall that some earlier versions of Gazebo had issues with that, could you replace the STL with, for example a small box? Also, what is the output if you parse the final file with raw xaxro command?

[flabrosse]

Sorry it took so long to come back to that...

It turns out that the Oak macro creates a link with the name of the parent frame ("camera_frame" in the code at the top). I thought this was supposed to be a link I create. This results in having two links that have the same name. If I give it a parent name that does not exist and then create a joint between my parent link and the one created by the Oak macro, then all is fine.

Quite misleading in my humble opinion.