/tf frames relationship misunderstanding

[clementyver]

Hello,

I use the Noetic ROS driver for an SBG Ellipse D. I noticed several inconsistencies in the /tf management.

First of all, we are asked to name 4 frames in the config file, so I expected to have 3 published /tf: init_frame=>odom_frame, odom_frame => base_link, base_link => imu_link. It turns out that only odom_frame => base_link was published. I solved the problem of publishing init_frame=>odom_frame by deleting the line in the message_wrapper.cpp file:
m_tf_broadcaster_.sendTransform(refTransformStamped);
in the fillTransform function, which duplicated the m_static_tf_broadcaster_.sendTransform(transform); called in the createRosOdoMessage function.

To this date, only base_link => imu_link remains unpublished. What interests me is that, still in the createRosOdoMessage function, the odometry message: odo_ros_msg.pose.pose is used to define the /tf between odom_frame and base_link BUT also to publish the odometry between odom_frame and m_frame_id_(i.e. imu_link).

So I'm not sure what odo_ros_msg.pose.pose contains, whether it contains information directly on the SBG frame or whether it's information recalculated on the center of the robot (defined as a parameter in the .yaml file).

Furthermore, the /tf between init_frame=>odom_frame contains only one translation (this structure doesn't take ENU and NED markers into account, and doesn't comply with ROS REP105, which defines, among other things, "Relationship between Frames").

What's more, in this /tf, it omits to add an orientation of w for the quaternion to be valid, such as:

geometry_msgs::Pose pose;
pose.position.x = m_utm0_.easting;
pose.position.y = m_utm0_.northing;
pose.position.z = m_utm0_.altitude;
pose.orientation.w = 1;

I'll be glad to have any info on thoses topics so I can submit a patched version of this driver 😃

Thank you in advance,

Clément

[tolesam]

@clementyver
Thank you for your feedback.
The issue about odoemtry /tf publisher should be fixed in the latest driver version.
The /tf between init_frame=>odom_frame is only published in ENU so the orientation should already be good.
odo_ros_msg.pose.pose contains information directly from SBG frames (imu_data, ekf_nav and ekf_quat or ekf_euler) and is not recalculated on the center of the robot by the driver.