ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

navsat_transform_node UTM->map transform is highly inaccurate [closed]

asked 2019-01-15 23:33:00 -0500

PG_GrantDare gravatar image

updated 2019-01-18 23:15:46 -0500

I am trying to achieve gps waypoint navigation. I am using the UTM->map transform provided by the navsat_transform_node 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 use_odometry_yaw 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

edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by PG_GrantDare
close date 2019-04-17 17:04:29.987051

1 Answer

Sort by ยป oldest newest most voted
2

answered 2019-01-21 02:43:06 -0500

Tom Moore gravatar image

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.

  3. 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.

edit flag offensive delete link more

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.

PG_GrantDare gravatar image PG_GrantDare  ( 2019-04-17 17:00:21 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2019-01-15 23:33:00 -0500

Seen: 1,313 times

Last updated: Jan 21 '19