# GPS + IMU + encoders for robot localization

Hey guys,

I want to fuse gps data i am getting from my piksi multi RTK system, and an IMU, and wheel encoders.

The GPS driver ( http://wiki.ros.org/swiftnav_piksi ) publishes the following:

sensor_msgs::NavSatFix gps/fix; nav_msgs::Odometry gps/rtkfix

the frame_id in the headers of those messages is set to "gps". the child_frame_id in the nav_msgs::Odometry message is not set to anything.

The IMU driver publishes imu/data, with the frame_id being "imu".

I plan on also having wheel encoders spitting out odometry data. I know that for those, the odom message should have a frame_id of "odom", and a child_frame_id of "base_link".

I am confused about how to prepare the data for robot_localization, in terms of frame ids. In the GPS system, the reported gps/rtkfix is the position/velocity of the rover relative the the base station. What should i set the frame_id and child_frame_id to for the RTK GPS? And what should i set the IMU frame_id to be?

Thanks,

edit retag close merge delete

Sort by » oldest newest most voted

It sounds like your GPS already provides data in a local world frame, thus eliminating the need for navsat_transform_node. If I were you, I'd set the gps/rtkfix frame_id and child_frame_id to map and base_link, respectively.

Then, make sure you have a static_transform_broadcaster that defines the transform from the robot's base_link frame to the imu frame.

I would then run two EKF instances:

1. In the first instance, set the world_frame to odom. Fuse wheel encoder odometry (I'd stick with velocities) and IMU data (again, I'd use velocities).
2. In the second instance, set the world_frame to map. Fuse the same data as in (1), but also fuse the gps/rtkfix data.

Does the gps/rtkfix data provide orientation? You need to be careful if you plan to fuse absolute IMU orientation instead of velocities, because what your IMU says is 0 radians may not agree with that the RTK unit says is 0 radians, so you'll get flip-flopping behavior. Even if the RTK unit doesn't provide orientation, you need to make sure that the orientation in the IMU is consistent with the RTK data. In other words, if the RTK says you went from (0, 0) to (1, 1), then your IMU should have a heading of pi/4. If that's not the case, I'd stick with fusing velocities from the IMU. If the RTK provides orientation, then you're golden: fuse the orientation from the RTK and angular velocity from the IMU.

more

Hey Tom. Thanks for the response. The RTK does not provide orientation, unfortunately. You would suggest i fuse wheel velocities, imu orientation, and rtk position? Or wheel velocities, imu ang. velocity, and rtk? In 2. Am i fusing the RTK data with the output of 1? Or with the same inputs as in 1?

( 2018-01-10 08:05:26 -0500 )edit

For (2), fuse wheel encoder odom velocity, IMU velocity, and RTK. Don't fuse the output of (1).

( 2018-01-10 08:20:29 -0500 )edit

Okay, so the purpose of 1 is to give me a odom->baselink transform. and 2 gives map->baselink, providing me with the full transform tree. correct?

( 2018-01-10 08:37:07 -0500 )edit

Yes, that's correct.

( 2018-01-10 08:39:28 -0500 )edit

Making the frame_id of the rtk gps odometry message "map" and the child frame id "base_link", assumes that the rover gps antenna is mounted in the same position as the base_link frame. If it is mounted on the side of the robot, then i should have the frame_id as "gps" and provide a gps->bl transfrom

( 2018-05-01 07:17:17 -0500 )edit

Sure, but be careful with that. I need to fix a bug with having non-zero GPS offsets. Make sure you only define the transform in XY coordinates; it's meaningless to define the GPS orientation w.r.t. base_link, and it won't use the Z offset.

( 2018-05-02 02:06:10 -0500 )edit

great, will do. I will only specify a static transfrom in the x and y dimensions

( 2018-05-02 09:39:14 -0500 )edit