nav_msgs/Odometry output

[tomlogan501]

Hi, Can you add a nav_msgs/Odometry optionnal output as a new feature (Ellipse D / N) ? It would be nice instead of everyone making a concat node.

[rsiryani]

Hi, Thank you for your request. We can indeed publish odometer info using the standard Odometry message.

However, it's not trivial due to frame id transformations. If you have already done the implementation, we could be interested to share with you information such as which frame id you would like.

Thanks,

[tomlogan501]

I haven't done it yet. I thought an update of the driver would be better than a proxy node.

[rsiryani]

Ok thanks, I am however a little bit concerned if nav_msgs/Odometry is really what you are looking at. Indeed, nav_msgs/Odometry is not the INS odometer velocity output but rather a relative position and a traveled distance.

It's not easy to implement from an INS that delivers latitude/longitude/altitude measurements on earth.

You can explain you use case so I can better understand what we can do to assist you?

Thank you,

[tomlogan501]

Sure ! I can talk about the use case. It's like most of the robots using ROS.

We have multiple sources of odometry on the machine : wheels, slam, gps. They are all converted to nav_msgs/Odometry in order to be merged (in node such as robot_localization UKF/EKF), to be compared and displayed in RVIZ.

I agree that using a relative position is not the best idea to place a robot but, aside from the GPS, all sensors provide a relative data of the robot.

Maybe another type such as geometry_msgs/PoseWithCovarianceStamped would fit better ?

[rsiryani]

Hi, Will it be fine for you if we publish a position using UTM projection? Which GNSS / driver are you using? We can align the implementation with it.

Thanks,

[tomlogan501]

We are using the RTK GNSS from the Ellipse D. About your UTM projection, I thought it was already the case with the topic /imu/pos_ecef. After that, about the correct format, I think "PoseWithCovarianceStamped" would be less work for you. That would be great to retrieve your EKF result

Thanks.

[rsiryani]

Hi,

The pos ECEF is not a projected position (not planar)

UTM however gives you a X/Y/Z planar position that is suitable for the Odometry message. It's better than a local tangent plane as you can travel greater distances.

We are planing to implement the Odometry message using UTM projection. The UTM projection (zone,origin) will be initialized as soon as the first valid INS position is returned.

As a result, the Odometry and Pose messages will only be sent by the INS once a first valid absolute INS position has been computed.

It will not be suited for indoor only navigation for instance.

Please feel free to get back to me if you have any remark or question.

Regards,

[tomlogan501]

Hi, Sounds good to me.

Regards.

[tomlogan501]

Hi, I have seen your new release but I couldn't spot a new Odometry message. Did you plan to make a feature branch ?

[rsiryani]

Hi,

We have indeed released a new version that aim to fix some issues and improve the overall implementation. We are going to start working on the Odometry message next week.

It will be done on a dedicated feature branch and it could be very helpful if you get a chance to test the Odometry implementation once it's done.

We will get back to you once we have a working version.

Thanks,

[JulienStanguennec-Leddartech]

I was looking at this:

"""/imu/odometry nav_msgs/Odometry

UTM projected position relative to the first valid INS position. Requires /sbg/imu_data and /sbg/ekv_nav and either /sbg/ekf_euler or /sbg/ekf_quat. Disabled by default, set odometry.enable in configuration file."""

I was not able to find odometry.enable in the config file : config/sbg_device_udp_default.yaml

Is it something that needs to be configured in the sbg ros driver some place else ?