Robotics StackExchange | Archived questions

navsat_transform_node UTM->map transform is highly inaccurate

I am trying to achieve gps waypoint navigation. I am using the UTM->map transform provided by the navsattransformnode to convert a Lat,Long into a goal for move_base. I am having wildly inaccurate results for where my goals are occasionally up to 10 meters (OR MORE) in any direction around the robot. Sometimes I will pick a point 10 meters in front of the robot and it will place the goal to the left of the robot.

The transform node I use is very similar to the gps_waypoint used in Nick Charrons' outdoor navigation. I use the same structure and change the way I receive the points (via a std_msgs::String topic).

The transform I listen to is utm->odom but even when I listen to utm->map and send m goal in the map frame I still get the same results? Is anyone able to recommend a specific tuning to fix this issue or perhaps an alternative package/approach?

I am experiencing "Initial odometry pose is " which I don't believe to be correct as you can see I have useodometryyaw false. This yaw that it receives from this message is drastically wrong and never changes. When I went into the source code and changed the "Initial orientation is" to a ros info not ros debug, I saw that this value was nothing like the odometry yaw that was being printed?

This is the navsat transform node params I use. My IMU has a calibration software which I used (to reduce the magnetic disturbance), I then aligned it to east and took a reading and accounted for an offset of +5.04deg.

navsat_transform:
frequency: 30
delay: 3.0
magnetic_declination_radians: -0.18884463 
yaw_offset: -0.0879795 
zero_altitude: true
broadcast_utm_transform: true
publish_filtered_gps: true
use_odometry_yaw: false
wait_for_datum: false

Thank you in advance

Asked by PG_GrantDare on 2019-01-16 00:33:00 UTC

Comments

Answers

A bunch of things:

  1. Please post the actual code you are using to look up the utm->map transform. Please also post your full EKF configs (maybe don't post the covariances), and sample messages for each sensor input.
  2. Regarding this: > I am experiencing "Initial odometry pose is " which I don't believe to be correct as you can see I have use_odometry_yaw false

Let's say you start your robot indoors, where there is no GPS signal. You drive around for a long time, then go outdoors. In order to properly create the utm->map transform, we need to know your map frame pose at the time the first GPS signal is received, so that we can invert that pose (transform) so that the first UTM coordinate that we receive cooresponds to that current map pose, and doesn't produce a (0, 0) position measurement.

In other words, this is normal and correct behavior.

  1. The reason I ask for (1) is that navsat_transform_node does this:
    • Waits for the initial GPS position. Converts it to UTM. Uses your robot's current world-frame heading, along with its map-frame pose, to create a transform from utm->map.
    • Now let's say you get another GPS fix a few seconds later. That GPS fix gets converted to UTM, passed through the transform, and turned into a pose. If that pose is consistent with your robot's map frame pose, that indicates that the utm->map transform is correct. Note that this chain of events is identical to what you're trying to do: take a GPS pose, pass it through the transform, and use the result. If there were an issue with the transform, I would expect the odometry/gps poses to vary as wildly as you are saying the goals do.

In the end, though, I can't comment without a lot more information.

Asked by Tom Moore on 2019-01-21 03:43:06 UTC

Comments

Hi Tom, this project has had to be shelved due to manufacturer hardware issues so I can't confirm any of the recommendations that you have made here. Thank you very much for taking the time to assist me with these issues.

Asked by PG_GrantDare on 2019-04-17 17:00:21 UTC