ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

robot_localization incorrect map->utm transform

Hello ,

I have some questions regarding robot_localization package using real map from Google or OSM.

Settings:

I have inputs from GPS sensor only - as a start for testing - generating 3 messages from it:

a- gpx/fix message (using lattitude , longitude from GPS)

b- sensor/imu message ( only orientation extracted from GPS )

c- nav_msg/odometry message ( using vx,vy from GPS )

I understand that the robot localization will be very inaccurate. However at this stage I am interested in getting the proper robot_localization settings and able to link the real map from google to the ROS localization (map_frame) and see it on RVIZ (note: google map is used as static obstacle map and I may use it later for goal settings as well. Main purpose of google map is static obstacles)

The issues / questions are:

1- How to tell robot localization that the origin of the map is at specific UTM co-ordinates? .................................................................................................................................................

2- I assumed that it can be done using datum parameter at navsat transform node as follows:

<param name="wait_for_datum"       value="true"/>
<rosparam param="datum">[30.070131 , 31.020022, 0.0]</rosparam>


I also set the following parameters for debugging.

<param name="broadcast_utm_transform" value="true"/>
<param name="publish filtered GPS" value="true"/>


When i run robot localization , These lines - from navsat transform.cpp - are printed:

Transform world frame pose is: Origin: (0 0 0) Rotation (RPY): (0, -0, 0) World frame->utm transform is Origin: (-3215764.3632935076021 911887.59913052641787 0) Rotation (RPY): (0, 0, -1.7544863270000004007)

and These UTM coordinates are not close to the map origin UTM coordinates: (latitude,longitude) = 30.070131 , 31.020022 should result ->(easting ,northing , zone) = 309151.07 , 3328209.18 , 36R

Accordingly on RVIZ the robot is not on the proper place on the map. So What is the problem? ...................................................................................................................................................................

3- In the datum param. I set the yaw to be 0 as the map is not tilted and the upper border is toward the north. I have no idea about the robot starting position nor orientation. So I set this value with respect to the map not to the robot.

<rosparam param="datum">[30.070131 , 31.020022, 0.0]</rosparam>

As mentioned earlier, navsat transform.cpp - is printed:

World frame->utm transform is Origin: (-3215764.3632935076021 911887.59913052641787 0) Rotation (RPY): (0, 0, -1.7544863270000004007)

Where did -1.7544863270000004007 came from?

...................................................................................................................................................................

Robot: Rbcar robot (at this stage it's irrelevant which robot is used)

ROS distro: Indigo in Ubuntu 14.04

Launch files: navsat_transform ekf_nodes move_base-map_server-rviz

map : yaml file

Frame tree: frames

rqt_graph_output: graph

Example bag file:

This bag file was recorded while moving around a building one turn until we reached same start point with only GPS sensor (without the robot itself). The bag file was recorded in the same configuration .

edit retag close merge delete

( 2017-11-28 01:28:34 -0600 )edit

-Make sure you have map server package(from navigation stack ) installed. -prepare a .png image of your map and follow this link to create a .pgm image and to update .yaml file -Have a look at the third attached launch file to add the map to move_base. -run rviz.

( 2017-11-28 02:17:07 -0600 )edit

Sort by » oldest newest most voted
1. Use the datum parameter, correct.
2. The reason for those values is that the map->UTM transform involves rotation. If you create a transformation matrix with the values you posted (MATLAB or Octave code shown):

mat = [cos(1.754486327)   -sin( 1.754486327)   309151.07
sin(1.754486327)    cos( 1.754486327)   3328209.18
0                   0                   1         ];
inv(rot)


...you'll get

-0.182658729774357         0.983176377074439          -3215747.5019837
-0.983176377074439        -0.182658729774357          911876.490213439
0                         0                         1


That's all we're doing in the code: we create a transform with the converted datum values and the yaw offset, and then invert it. I do note that the values aren't exactly what the node is producing, but that is almost certainly related to this. Also, you may have just copied and pasted this incorrectly, but the parameter should be publish_filtered_gps. Unrelated to your question, but it's worth mentioning.

3. The -1.754 value is the (negated) summation of your yaw_offset an magnetic_declination_radians parameters: 1.570796327 + 0.18369 = 1.754486327. Please see this page for details.
more