Hi @dpetrini,
As far as I know (if this is not correct, please someone point it out), the navsat_transform_node
needs an IMU topic since with the GPS you are not able to provide a proper estimation of your orientation. If you take a look in rviz
at the odometry provided by a GPS, if you are static, the orientation is just plotted with a directed arrow with random orientation, this is due to the fact that the orientation is calculated taking into account the current GPS position and a random close position. With the IMU you can provide a high precisse orientation information, allowing the localization process to be more accurate.
However, since the nav_msgs/Odometry
input messages come usually from EFK
or UKF
nodes, you can activate the use_odometry_yaw
flag to avoid using an IMU topic as input for the navsat_transform_node
. Nonetheless, you will have to take into account that this last fussion needs to contain a proper orientation information. As I see, either your odometry contains a good orientation somehow, or you are forced to use the IMU data, either in the fussion process of UKF
/EFK
or directly as input in the navsat_transform_node
.
Originally posted by Weasfas with karma: 1695 on 2020-06-05
This answer was ACCEPTED on the original site
Post score: 0
Original comments
Comment by dpetrini on 2020-06-15:
hi @Weasfas, thanks for the answer, it clarifies the orientation issues. However my point was more high level in terms of the need to have IMU at all if I have GPS which is absolute. The point I found in other answer is that with GPS I could get orientation by integrating positions and thus knowing speed and direction. One comment here link text tells about that.
For my doubt I consider is ok with your answer and this comment. But I realize that if I manage to integrate GPS, the period is very low (1 Hz) so probably quality will be not good so I guess I will have to improve IMU magnetometer readings (MPU9250) by proper calibrating it.