# How do you dynamically set a known position in robot_pose_ekf when you encounter a landmark?

I have a turtlebot running ROS Indigo that I am using to navigate a floorplan. I am using the robot_pose_ekf package for odometry. However, it would be convenient if the the robot used an April tag as the origin rather than the position it is in when the robot_pose_ekf package launches. I would also like to be able to reset the position the robot thinks it is in when the robot encounters other landmarks (in this case, April tags placed in known locations). Right now, the fact that the origin of the robot in robot_pose_ekf is not precise is causing some errors to accumulate in the robot's location on a map, and the imprecision makes coordinate transformations tedious. I would like to use this zeroing to 1) make the starting location of the robot precise and predictable, and 2) help the robot course correct rather than drifting as the package continues to run.

Any information about how I might do this would be very much appreciated.

edit retag close merge delete

Sort by » oldest newest most voted

robot_pose_ekf, and kalman filters in general, are mostly used in robotics to provide improved odometry. They still drift a bit, but they're generally more accurate than any single relative motion sensor.

I don't think there's a way to force the EKF into a particular solution. Instead of forcing the EKF to take a particular value, most localization packages provide an additional transform from a global frame (usually /map) to the odometry frame (usually /odom or /odom_combined); this serves as a correction to the EKF data, and it can remain static if there are no localization updates (in your case, tag detections), while the EKF continues to publish relative position updates on top of the most recent localization result.

more

Should the map frame be published somewhere, or does it only exist on the tf topic? Is there are preferred way to access map data? Right now, the package isn't publishing a map topic.

( 2017-01-14 13:53:49 -0500 )edit

Like most frames, the /map frame is a TF frame and is published on the /tf topic. (odometry is an exception to this, because it's published as both a tf frame, and a topic that contains additional data such as position covariance and velocity)

( 2017-01-14 21:46:46 -0500 )edit

So if I want to access the map frame, I should use something like

position, orientation = self.transform_listener.lookupTransform(frame, "/base_footprint", rospy.Time(0))

correct? I'm worried I'm getting a relative transformation rather than the absolute map.

( 2017-02-02 13:27:34 -0500 )edit

That looks about right. Keep in mind that all transformations are the relative position between two coordinate frames.

( 2017-02-02 14:04:43 -0500 )edit

Without having worked with this extended kalman filter package, in general it should be possible to remove drift over time by feeding the filter with positions measurements that correspond to observations of landmarks.

It would roughly work like this: -Run the EKF normally -Whenever a tag is spotted, augment the observation matrix to account for a low-covariance position measurement (For a linear kalman filter, this corresponds to adding a row -If multiple tags are visible, keep adding rows -When the tag is lost again remove the entry that corresponds to the tag that was lost

You could also add bias-states to the filter, which are basically integrator states that are summed with the velocity state to estimate a position. In this way, it is possible to reduce the drift of the filter somewhat (if the drift is constant), using IMU's this helped me a lot.

kind regards

more