Zed2i robot integration in ros2

I’m integrating a Zed2i camera into a ROS2 environment robot. I would like to use the Positional Tracking engine fully (visual-inertial odometry + mapping with loop closure).
According to this: ZED integration on a Robot - Stereolabs the zed_camera_link must be the root frame of the robot. Basically the base_link is a child of zed_camera_link. Then I should put the robot in the right position so I set the ‘initial_base_pose’ parameter of common.yaml to the position of the camera (otherwise the robot is below the floor)
Below an example of the camera urdf:

 <joint name="$(arg camera_name)_joint" type="fixed">
      <parent link="$(arg camera_name)_camera_link"/>
      <child link="base_link"/>
        xyz="-0.7 0.0 -1.00"
        rpy="0 0 0"

and the related common.yaml parameter:
initial_base_pose: [0.7, 0.0, 1.0, 0.0, 0.0, 0.0] # Initial position of the `camera_link` frame in the map -> [X, Y, Z, R, P, Y]

the odom and pose topics, if I understood in the right way, are related to zed_camera_link and they are not related (directly) to base_link.

This architecture is a bit uncomfortable since the “main” link from a navigation point of view is the base_link (the “pivot” of the robot)

Actually I see a different approach in zed_wrapper for ROS1 . According to this: I'd like to change initial pose map to base_link - #4 by Myzhar

it’s possible to pass the position of the camera center as arguments in the main launch file zed2.launch keeping the TF chain as it should be: mapodombase_link

Should I do it in ROS2 the same as in ROS1? Change the urdf of the camera and put zed_camera_link superposed to base_link?

Thank you

Hi @andreacelani
welcome to the Stereolabs community.

We recently introduced this behavior in the ROS 2 wrapper to simplify the behavior and improve the performance when using the positional tracking module of the ZED SDK and no other localization/odometry sources.

We can consider adding a new parameter to provide the robot’s pose in the base_link frame (or any other robot frame).
This can easily achieved by using the TF2 tools.

Please add a “feature request” issue to GitHub so we can track it.

Ok thank you.
I tried to do it on my own and it worked, I mean “porting” the ROS1 implementation into ROS2 launch/urdf.
My main concern about it is if it was intended to be used like that and from your answer it seems to be.

1 Like