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

Robot_localization gps use only fix messages

asked 2022-07-20 14:00:37 -0500

PaddyCube gravatar image

Hello,

I was able to set up robot_localization to fuse wheel odometry, imu and rtk gps data of my two wheeled robot. It was a hard task to fuse imu, but after using vyaw only, it works https://github.com/HoverMower/ROSMowe...

However, my robot is equipped with RTK GPS. Right after startup, there is no gps fix solution. So my robot jumps around until a fix is available. While waiting for fix, I can travel around but localization is not exact for sure. As robot_localization subscribes to NavSatFix message, can we only fuse messages with gps status > 0, meaning only messages with a fix? Or do I need to Code a node which only re-publishes these messages?

Alternatively, gps driver provides a ublox/navrelposned message which contains the difference between base station and robot in X,Y,Z. Is is possible to fuse these data instead real gps data? Maybe by also a small node which publish them as odometry message?

Couldn't find an example with rtk gps.

BR Patrick

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2022-08-26 03:44:27 -0500

Tom Moore gravatar image

As robot_localization subscribes to NavSatFix message, can we only fuse messages with gps status > 0, meaning only messages with a fix? Or do I need to Code a node which only re-publishes these messages?

navsat_transform_node filters out messages with a status of STATUS_NO_FIX. Are you sure your GPS messages are correctly filling out the status field?

Alternatively, gps driver provides a ublox/navrelposned message which contains the difference between base station and robot in X,Y,Z. Is is possible to fuse these data instead real gps data?

Maybe, though there are gremlins to be found doing that. Those X, Y positions will define your world coordinate frame. So if you move away from the base station at 45 degrees for 1.41 meters, the RTK unit will say that you are at position (1, 1). But your EKF heading may not agree:

  • If you are fusing absolute yaw from the IMU, the IMU's 0 orientation needs to match the 0 orientation of your RTK coordinate frame (so if you face the +X axis int the RTK coordinate frame, the IMU would need to read 0).
  • If you are only fusing yaw velocity from the IMU, then during that same traversal above, the EKF will think it has a heading of 0, and it will integrate the velocity data from the encoders that way.

In both cases, the net effect will be that your robot will likely look like it is oriented in a different direction than it is travelling. n_t_n handles this issue for you, which is why I recommend it.

edit flag offensive delete link more

Comments

Thank you so much for your explanation. I initially had issues that the robot gets far off the map in all dimensions, when starting up. This is caused because it takes some minutes to get a RTK fix solution. But robot gets placed on the map as soon as all nodes are up and running. How gets this issue handeled in r_l with n_t_n? I already tried with setting a datum inside the launch file. Here I added the lat/lon of my gps base station, which is only a couple of meters beneath the robot. To my understanding, I either have to set a datum in launch file or I have to call the datum service, as soon as I get a gps fix solution. Or do I not have to provide a datum this way?

PaddyCube gravatar image PaddyCube  ( 2022-09-06 12:18:08 -0500 )edit

The datum will be provided automatically by the GPS fix if you don't bother setting the datum or calling the service. What is the status field of your GPS fix messages while it's settling down? You could always write some interim node that subscribes to the GPS messages and waits for some condition to be true before republishing the GPS messages for n_t_n to consume.

Tom Moore gravatar image Tom Moore  ( 2022-09-26 04:06:05 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2022-07-20 14:00:37 -0500

Seen: 112 times

Last updated: Aug 26 '22