search

ixblue / ixblue_ins_stdbin_driver

ROS driver for iXblue inertial sensors supporting StdBin protocol
MIT License
9 stars 13 forks source link

Suggestion (feature request), support for nav_msgs/odometry #17

Open JFMatch opened 3 years ago

JFMatch commented 3 years ago

It would be great to have native support for the nav_msgs/odometry message.

adrienbarral commented 3 years ago

Hello, @JFMatch .

You're not the first one to ask us for that. And, we (the iXblue robotic's division) often has the same needs. And usually we do this in a separate node. But let me explain why I think this feature should not be in the INS driver.

The INS work on a georeferenced frame. Internal filter try to estimate the position of the device on hearth, so I guess that the filter state is a georeferenced position. To produce a nav_msgs/odometry we must transform this georeferenced position to a cartesian position. I see two way to perform this task :

  1. Integrating INS accelerations : We can start in 0,0 when the device is powered up, and integrate INS acceleration. By doing that we don't use the filter that is inside the INS, and odometry position will drif quickly. THis is not a good option.

  2. Project GeoReferenced coordinates : So we must project the georeferenced position. And there is no universal method to do so.

If you work on a small area, a simple Local Cartesian projection will be sufficiently accurate, so the LocalCartesian class of the LibGeographic will do the job (https://geographiclib.sourceforge.io/html/classGeographicLib_1_1LocalCartesian.html). If you plan to do a trans-atlantic trip with an USV, this kind of projection is not appropriate.

In a ROS point of view, the nav_msgs/Odometry can drift, but is "continuous". In a nav_msgs/Odometry we usually want to have a continuous coordinates (without jumps) to allow smooth control of a robot. Position given by the INS can have some discontinuity (if you loose the GPS during some minutes and the GPS is back again, you will have a jump in the position). This kind of discontinuity must be managed by the final application, because here again there is no universal way to properly manage this point.

If you think to a need that look like universal, I am open to implement it in the driver, let me know.

JFMatch commented 3 years ago

Hello @adrienbarral,

To be honest I probably haven't completely thought this through. I would think that UTM would be as close as you can get to a universal projected coordinate system. I am used to dealing with geo referenced coordinates and I haven't really tackled this problem yet but the way I think it should be done from my perspective (I may change my opinion) is to use UTM, and publish the transform that is being used and to either give the user the option to either extend UTM zones or handle the discontinuity themselves.

With respect to continuous vs discontinuous in respect to nav_msgs\odometry that is a good point however I thought that the ROS standard on that point is tied to the reference frame as opposed to the message. I was under the impression that the odometery frame is meant to be continuous whereas the world frame can be discontinuous. Is that not correct?

BTW you and your company make a great product!

Thank

Hello, @JFMatch .

You're not the first one to ask us for that. And, we (the iXblue robotic's division) often has the same needs. And usually we do this in a separate node. But let me explain why I think this feature should not be in the INS driver.

The INS work on a georeferenced frame. Internal filter try to estimate the position of the device on hearth, so I guess that the filter state is a georeferenced position. To produce a nav_msgs/odometry we must transform this georeferenced position to a cartesian position. I see two way to perform this task :

  1. Integrating INS accelerations : We can start in 0,0 when the device is powered up, and integrate INS acceleration. By doing that we don't use the filter that is inside the INS, and odometry position will drif quickly. THis is not a good option.
  2. Project GeoReferenced coordinates : So we must project the georeferenced position. And there is no universal method to do so.

If you work on a small area, a simple Local Cartesian projection will be sufficiently accurate, so the LocalCartesian class of the LibGeographic will do the job (https://geographiclib.sourceforge.io/html/classGeographicLib_1_1LocalCartesian.html). If you plan to do a trans-atlantic trip with an USV, this kind of projection is not appropriate.

In a ROS point of view, the nav_msgs/Odometry can drift, but is "continuous". In a nav_msgs/Odometry we usually want to have a continuous coordinates (without jumps) to allow smooth control of a robot. Position given by the INS can have some discontinuity (if you loose the GPS during some minutes and the GPS is back again, you will have a jump in the position). This kind of discontinuity must be managed by the final application, because here again there is no universal way to properly manage this point.

If you think to a need that look like universal, I am open to implement it in the driver, let me know.