robot_localization using UTM grid as map

edit

Whew! Nice question. This answer might be a bit lengthy, so bear with me:

1. First, some history. The utm_transform_node originally published an odom->utm transform to the tf tree. Assuming your UTM data, which was reported as a nav_msgs/Odometry message, had a frame_id of utm, you could simply include it as an input to ekf_localization_node, and it would apply the transform before fusing the position. However, when a GPS device first starts up, it will naturally report some erroneous positions until it gets position information from enough satellites to give reasonable accuracy. The UTM data coming from utm_odometry_node in gps_common doesn't concern itself with that, so I added a new input to utm_transform_node, namely, the raw gps_common/GPSFix message. I used that information to determine if the fix was valid before computing the transform. At this point, though, I had redundant information, and so I nixed the requirement for UTM data, deprecated utm_transform_node, and created navsat_transform_node. navsat_transform_node still keeps a world_frame->utm transform internally, but it doesn't publish it. Instead, it outputs a nav_msgs/Odometry message with the data already converted to the world (in this case, map) coordinate frame. This provides two benefits:

   • Users can just start up the node and get global positions that are consistent with their robot's starting position and orientation.
   • rviz behaves a little strangely when you have a transform that's on the order of tens of thousands of meters, and this eliminated that issue.

   Having said that, if you need navsat_transform_node to publish that transform, I'd be happy to add it as an optional, configurable feature. Just submit a feature request.

2. This is a little harder to answer without a bag file, but I do see a few issues in your configuration and sensor data:

   • First, double-check your sensor data. To answer your question, yes, I am compensating for acceleration due to gravity. There's a parameter called remove_gravitational_acceleration, and it defaults to true. I should really make that a per-sensor configuration, but I digress. However, your IMU appears to be reporting negative Z acceleration on what I'm assuming is level ground. Is your IMU flipped upside-down, and if so, is that reflected in your base_footprint->imu transform? Double-check all of your signs for acceleration, because my correction could very well be causing your accelerations to increase. My assumptions about directions of acceleration readings are the same as this. If the IMU is on a level surface, it should report Z acceleration of +9.81 m/s^2. If you roll it +90 degrees, it should report a Y acceleration of +9.81 m/s^2. If you pitch it +90 degrees, it should report an X acceleration of -9.81 m/s^2.
   • Second, your navsat_transform_node configuration uses the /imu/pseaa topic, but in your ekf_localization_node configuration, you have its yaw value set to false. If that sensor doesn't have an absolute heading reference, it won't work. I would switch that to the imu ...