Using another robot's odometry instead of ZED's

Software ROS1
,
1

I have ZED2i mounted on a robot with its own odometry node. Since TF trees have to be, well, trees, I’m sticking with the other robot’s odometry. From this Github issue, it seems as though the TF chain map → odom → base_link → zed2i_base_link is a mandatory chain, whereas in my case, I’m trying to do odom (other robot) → robot_base_link → zed2i_base_link. I’ve also modifed common.yaml to have position tracking disabled:

pos_tracking:
        pos_tracking_enabled:       false
        publish_tf:                 false
        publish_map_tf:             false

I modified zed2i.launch to have the static TF between ZED and the robot:

    <arg name="base_frame"           value="body" /><!-- The robot's base frame -->

    <arg name="cam_pos_x"             value="0.5541150717847408" /> <!-- Position respect to base frame (i.e. "base_link) -->
    <arg name="cam_pos_y"             value="0.00002916409135" /> <!-- Position respect to base frame (i.e. "base_link) -->
    <arg name="cam_pos_z"             value="0.1413133563415901" /> <!-- Position respect to base frame (i.e. "base_link) -->
    <arg name="cam_roll"              value="0.0038318163402699043" /> <!-- Orientation respect to base frame (i.e. "base_link) -->
    <arg name="cam_pitch"             value="0.034986497068765145" /> <!-- Orientation respect to base frame (i.e. "base_link) -->
    <arg name="cam_yaw"               value="-0.0009843428622626003" /> <!-- Orientation respect to base frame (i.e. "base_link) -->

The TF tree looks like we’d like it to now, with zed2i_base_link connected to the robot’s body frame. The lack of a map frame shouldn’t break anything/cause a low framerate as experienced in the linked issue, right?

Edit: I originally wrote pos_tracking arguments as true, changed them to false as they are in my common.yaml

2

If you must use external odometry you do not have to disable positional tracking, but simply pos_tracking.publish_tf
You must also be sure that some other node publishes a TF chain map → zed2i_base_link otherwise the ROS 2 Wrapper node will get stuck waiting for valid TF.

3

So I could just publish a static transform map → odom that’s unit (x, y, z, roll, pitch, yaw = 0) and it’ll be fine?

4

If the robot does not move that’s ok

5

Wouldn’t a unit transformation between the mapping and odometry frames just imply that the odometry has no drift/is perfect, not that the robot isn’t moving?

6

Yes, that could work.