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

new update robot_localization

asked 2015-07-31 05:25:20 -0500

Porti77 gravatar image

updated 2015-09-01 09:23:29 -0500

I have so time work with this package, last week i update this in other work_space and started to do test with old bags. I was surprised because a observation, now the front of base_link its Y???? Before was X. This is a modification? I link my rosbag https://www.dropbox.com/s/1kkzfjnf0bi...

-New package This is the two captures that i discovered that changes in the frame

-Old package image description

EDIT 2: I did a rosbag record https://www.dropbox.com/s/njkh0m9qox7... i launch a ekf with the same position and 4 times with each cardinal points, and the tf between utm and odom no changes the orientation.

EDIT 3: https://www.dropbox.com/s/ws428skxsg1...

I record a rosbag that during 12 minuts, the secuence is the next

MIN              ACTIONS
0
                     Only launched gps and compass
                     Compass pointing to north
1
                     Launch ekf, navsat, tf
3
                     Shutdown ekf, navsat, tf
                     Compass pointing to south
4
                     Launch ekf, navsat, tf
6
                     Shutdown ekf, navsat, tf
                     Compass pointing to east
7
                     Launch ekf, navsat, tf
9
                     Shutdown ekf, navsat, tf
                     Compass pointing to west
10
                     Launch ekf, navsat, tf
12

This route is a 8x8 square meters course 3 times, first north, second west, then south and finally east. Square route according to the right-hand rule. https://www.dropbox.com/s/2fyeh3k06qo...

This is the launch file:

<!-- Ekf -->
<launch>

   <param name="/use_sim_time" value="true" />
   <node pkg="rosbag" type="play" name="rosbagplay" args="/home/jorge_j/example.bag  --clock -d 3" required="true"/>

   <node pkg="tf2_ros" type="static_transform_publisher" name="bl_imu" args="0.0 0.0 0.0 0.0 0.0 0.0 1.0 base_link compass" /> 
   <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization" clear_params="true">

       <param name="frequency" value="30"/>
       <param name="sensor_timeout" value="0.1"/>
       <param name="two_d_mode" value="true"/>

       <param name="map_frame" value="map"/>
       <param name="odom_frame" value="odom"/>
       <param name="base_link_frame" value="base_link"/>
       <param name="world_frame" value="odom"/>

       <param name="transform_time_offset" value="0.0"/>

       <param name="odom0" value="/odometry/gps"/>
       <param name="imu0" value="/compass/data"/>

         <rosparam param="odom0_config">[ true,  true, false,
                                         false, false, false,
                                         false, false, false,
                                         false, false, false,
                                         false, false, false]</rosparam>

         <rosparam param="imu0_config">[false, false, false,
                                        false, false,  true,
                                        false, false, false,
                                        false, false, false,
                                        false, false, false]</rosparam>

       <param name="odom0_differential" value="false"/>
       <param name="imu0_differential" value="false"/>

       <param name="odom0_relative" value="false"/>
       <param name="imu0_relative" value="false"/>

       <param name="imu0_remove_gravitational_acceleration" value="true"/>

       <param name="print_diagnostics" value="true"/>

       <param name="odom0_queue_size" value="10"/>
       <param name="imu0_queue_size" value="10"/>

       <param name="debug"           value="false"/>
       <param name="debug_out_file"  value="debug_ekf_localization.txt"/>

         <rosparam param="process_noise_covariance">[0.05, 0,    0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                                     0,    0.05, 0,    0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                                     0,    0,    0.06, 0,    0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                                     0,    0,    0,    0.03, 0,    0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                                     0,    0,    0,    0,    0.03, 0,    0,     0,     0,    0,    0,    0,    0,    0,    0,
                                                     0,    0 ...
(more)
edit retag flag offensive close merge delete

Comments

Did you launch the EKF four times, or launch it once, and just turn the robot? Just trying to understand your process.

Tom Moore gravatar image Tom Moore  ( 2015-08-05 14:57:32 -0500 )edit

Launch it once, and just turn the robot

Porti77 gravatar image Porti77  ( 2015-08-21 02:33:43 -0500 )edit

The transform isn't going to change if you rotate the robot and don't stop the node. You need to stop it, rotate the robot, then start it again. The UTM->odom transform is static.

Tom Moore gravatar image Tom Moore  ( 2015-08-21 14:52:17 -0500 )edit

I stop the node, rotate and then start again and the tf between odom and UTM has the same quaternion in all times. And my imu sensor only have data of yaw, so the matrix only have a true the yaw. The imu when pointing to East yaw=0 and when pointing to north yaw=90, is correct with my launch?

Porti77 gravatar image Porti77  ( 2015-08-26 02:44:23 -0500 )edit

I already understand why need the imu data the navsat node. I want that the transform orientation between utm and odom is 0 and not a small amount. So that the Odom has the same orientation as the UTM.

Porti77 gravatar image Porti77  ( 2015-08-28 05:03:47 -0500 )edit

You should probably ask that last question in a new question. This one is getting a little too long.

Tom Moore gravatar image Tom Moore  ( 2015-09-01 19:00:17 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2015-07-31 07:22:36 -0500

Tom Moore gravatar image

updated 2015-08-29 09:16:52 -0500

This is due to a change in REP-103. Previously, navsat_transform_node assumed that a 0 reading on a compass was at magnetic north. Now we assume it's east ("magnetic east" in the sense that you still have to apply a magnetic declination to get true east). I simply didn't get around to changing that test launch file by applying a yaw_offset of pi/2.

EDIT: OK, I figured out your issue. Most of your problem is that you never remapped your /imu/data topic for navsat_transform_node. You needed to add this line to your navsat_transform_node launch:

 <remap from="/imu/data" to="/compass/data"/>

The reason you still got a utm->odom transform is a bug that I fixed in the repo a while ago. Even with the Debian package version, though, this worked for me:

<launch>

   <param name="/use_sim_time" value="true" />

   <node pkg="rosbag" type="play" name="rosbagplay" args="/home/tmoore/Desktop/porti.bag --clock -d 3" required="true"/>

   <node pkg="tf2_ros" type="static_transform_publisher" name="bl_imu" args="0.0 0.0 0.0 0.0 0.0 0.0 1.0 base_link compass" />

   <node pkg="robot_localization" type="ekf_localization_node" name="ekf_localization" clear_params="true">

       <param name="frequency" value="30"/>
       <param name="sensor_timeout" value="0.1"/>
       <param name="two_d_mode" value="true"/>

       <param name="map_frame" value="map"/>
       <param name="odom_frame" value="odom"/>
       <param name="base_link_frame" value="base_link"/>
       <param name="world_frame" value="odom"/>

       <param name="transform_time_offset" value="0.0"/>

       <param name="odom0" value="/odometry/gps"/>
       <param name="imu0" value="/compass/data"/>

         <rosparam param="odom0_config">[ true,  true, false,
                                         false, false, false,
                                         false, false, false,
                                         false, false, false,
                                         false, false, false]</rosparam>

         <rosparam param="imu0_config">[false, false, false,
                                         true,  true,  true,
                                        false, false, false,
                                         true,  true,  true,
                                         true,  true,  true]</rosparam>

       <param name="odom0_differential" value="false"/>
       <param name="imu0_differential" value="false"/>

       <param name="odom0_relative" value="false"/>
       <param name="imu0_relative" value="false"/>

       <param name="imu0_remove_gravitational_acceleration" value="true"/>

       <param name="print_diagnostics" value="true"/>

       <param name="odom0_queue_size" value="10"/>
       <param name="imu0_queue_size" value="10"/>

       <param name="debug"           value="false"/>
       <param name="debug_out_file"  value="debug_ekf_localization.txt"/>

   </node>

   <node pkg="robot_localization" type="navsat_transform_node" name="navsat_transform_node" respawn="true" output="screen">

       <!-- Frequency of the main run loop. -->
       <param name="frequency" value="30"/>

       <param name="delay" value="3"/>
       <param name="magnetic_declination_radians" value="0"/>
       <param name="yaw_offset" value="0"/>
       <param name="zero_altitude" value="true"/>
       <param name="broadcast_utm_transform" value="true"/>
       <param name="publish_filtered_gps" value="true"/>
       <param name="use_odometry_yaw" value="false"/>

       <remap from="/gps/fix" to="fix"/>
       <remap from="/imu/data" to="/compass/data"/>

   </node>

</launch>

EDIT in response to further questions/comments:

The reason the orientation in the transform from utm->odom is always near 0 is because your IMU and EKF orientations are almost identical (they have the same source, but the EKF output has, of course, been filtered). So no matter which direction you're facing, the orientation of those coordinate frames will match, and the rotational component of their transform will be near 0. So:

  • If you want the orientation in the utm->odom transform to be exactly 0, then set use_odometry_yaw to ...
(more)
edit flag offensive delete link more

Comments

Ok! Thanks for all, and a last question why navasat_transform_node need suscribe to a imu topic? The tf orientation publish between utm and odom is always 0, in my situation.

Porti77 gravatar image Porti77  ( 2015-08-03 10:01:33 -0500 )edit

GPS coordinates are reported in an earth-fixed frame. You need to know your heading within that frame in order to compute a transform to your world (odom or map) coordinate frame. See this for more details.

Tom Moore gravatar image Tom Moore  ( 2015-08-03 10:21:02 -0500 )edit

I launched the filter four times since the same position gps , and with the compass pointing to the four cardinals points, one for time, and i did tf_echo odom utm and i get the same transformation, the rotation between utm and odom is 0 always.

Porti77 gravatar image Porti77  ( 2015-08-04 12:02:01 -0500 )edit

Are you actually feeding it an IMU message with a compass in it, or just an IMU message with a 0 heading? Can you post an IMU message?

Tom Moore gravatar image Tom Moore  ( 2015-08-04 12:21:08 -0500 )edit

Can you please post your updated launch file? Your bag file does not contain an /imu/data topic, so I'm assuming you launch file above is out of date.

Tom Moore gravatar image Tom Moore  ( 2015-08-05 14:54:52 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2015-07-31 05:25:20 -0500

Seen: 1,132 times

Last updated: Sep 01 '15