Navsat transform and robot_localization ekf implementation questions

asked 2019-09-03 09:21:47 -0500

SamsAutonomy
68 ●2 ●5 ●6

Two questions:

1) navsat_transform_node requires an accurate world heading, why?

a sensor_msgs/Imu containing an accurate estimate of your robot’s heading

Since GPS systems report a position (no orientation) I am unclear as to why the navsat_transform_node requires an orientation? I understand we are trying to get initial orientation of the vehicle to match so when a GPS position comes in, if after the initial state estimation, the following GPS odometry from /fix matches the coordinate frame of map. In our test area we have very weird magnetic disturbance due to metals etc. that are in the soil. This leads into question 2.

2) ekf_localization_node requires a world oriented heading reference (for the outer layer that is tied back into navsat_transform_node), why?

Shouldn't the EKF with position fused data be able to compute the vehicle orientation? For a comparison, certain Novatel GNS systems have no magnetometer in them. You drive the system forward for some distance, then in circles. It then computes an orientation from this. Is it possible to do this with ekf_localization_node?

3) navsat_transform_node only publishes the GPS messages at some set frequency, why doesn't it publish them as soon as they are received?

If the frequency param is low, there can be a little bit of latency between the received GPS message and the output of navsat_transform_node. I assume this implementation detail is due to the use of the publish_filtered_gps param.

edit retag flag offensive close merge delete

add a comment

answered 2019-10-08 07:39:55 -0500

Tom Moore

flag of United Kingdom of Great Britain and Northern Ireland

13689 ●74 ●240 ●232 http://github.com/ayrton04

See this page. The short answer is that the GPS coordinates get turned into a UTM pose, and that UTM pose needs to have a yaw so that we can generate a transform from the utm frame to your world frame (e.g., map). Forgetting GPS positions for a moment, the UTM grid is a world-fixed coordinate frame, just like map or odom in the EKF. If you want to transform coordinates from one frame into another, the orientations of those frames are required. You need to know, at the point your robot started, which way it was oriented in the utm frame, and where it was in the utm grid positionally. Those two things define the utm->map transform (or utm->your_world_frame, whatever that is).
That's only true if you turn use_odometry_yaw on for navsat_transform_node. The EKF itself doesn't care about earth-referenced headings. If that's in the documentation somewhere, can you point me to it? Sorry for the confusion.
navsat_transform_node will publish GPS messages at the rate at which you tell the node to run. It's running on a fixed update timer that runs at the rate you specify. The poses that it _outputs_ are driven by the latest EKF output. So it takes in the fused output from the EKF, transforms it back into GPS coordinates, and publishes.

edit flag offensive delete link

add a comment

Navsat transform and robot_localization ekf implementation questions

1 Answer

Question Tools

Stats

Related questions

Navsat transform and robot_localization ekf implementation questions edit

1 Answer

Question Tools

Stats

Related questions

Navsat transform and robot_localization ekf implementation questions