0
$\begingroup$

Rosanswers logo

My question is kind of similar to this one. I'm having trouble understanding how the transforms should be setup for the case I'm working on

My robot is a quad with a camera that can localise itself using markers. My goal is to fuse the pose from a slam package I'm using with the quad's IMU.

My slam package is outputting a transform tree : odom>base_link>camera>marker. The published odom>baselink transform contains the pose information of the robot in the world, so my world frame would be odom. setting my base_link frame to base_link causes the circular relationship that you mention and affects the published pose. If set my base_link frame to a something new like ekf_base,

The pose itself is published on a topic called /fiducial_pose which has a frame_id 'camera' (not odom). If I fed this topic into robot_localisation, will this be a problem? Does the frame_id of the pose data matter?

If I fed just this topic into the ekf in robot_localisation as a pose0 topic in the config file, I should be getting basically a smoother version of the same pose, correct? But my pose jumps all over the place getting even worse the original data plugged in. The covariances in /odometry/filtered jump all over the place. My /vpose frequency is about 20Hz, but I would like to use the ekf to make it higher.

My next step would be to add the IMU values.But i would like to know if what I'm doing is correct before adding the IMU into the equation.

Thanks!

UPDATE 1:

Fixed the frames issue and now I have a working filter that takes into account IMU measurements and visual odometry.

The way I have it setup currently is:

Slam package publishes map > odom, robot localisation as a state estimator node (converting IMU acceleration data to pose estimates) publishes odom>baselink and another instance of r_l is which fuses pose from the state estimator and visual odometry (with map as the world frame).

I have two questions:

  1. Is this the right way of doing it? Do I have to run two nodes in this way, or is possible to fuse IMU and visual odometry in one node without separate state estimation node? What would my odom>baselink transform be in this case?

In this setup, I notice that when visual odometry fails for even a second, the final ekf pose estimation immediately drifts away to very high values. On the surface, I can understand why this is happening (double integration). I just want to make sure I did not miss anything else. Do you have any quick tips as to how to slow down the drift by tweaking EKF rate, timeout or covariances?

  1. What do you think the best approach would be to go about using my own motion model? I think that you have used a 6DOF Kinematic model of a rigid body in 3D space. I would like to use a dynamic model of a quadrotor.

Originally posted by nav-go on ROS Answers with karma: 21 on 2018-01-05

Post score: 2

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

Rosanswers logo

My slam package is outputting a transform tree

If your SLAM package is already producing odom->base_link, then there's no need for the EKF. tf will not allow more than one node to publish the same transform, and the EKF will be trying to publish odom->base_link as well. Maybe you should back up a bit and explain what it is you're trying to accomplish with your robot?

The pose itself is published on a topic called /fiducial_pose which has a frame_id 'camera' (not odom). If I fed this topic into robot_localisation, will this be a problem? Does the frame_id of the pose data matter?

Yes, it matters a great deal. The EKF will need to know how to transform from camera to whatever you have your world_frame set to.

If I fed just this topic into the ekf in robot_localisation as a pose0 topic in the config file, I should be getting basically a smoother version of the same pose, correct? But my pose jumps all over the place getting even worse the original data plugged in.

I suspect this is because you have some serious misconfiguration going on. I'd do some in-depth reading about the tf library, and read over REP-105, if you haven't yet.

In any case, for me to make any useful recommendations, I'd need your full EKF config and sample input messages from every sensor.

EDIT in response to update:

Slam package publishes map > odom, robot localisation as a state estimator node (converting IMU acceleration data to pose estimates) publishes odom>baselink and another instance of r_l is which fuses pose from the state estimator and visual odometry (with map as the world frame).

If you're going to run two instances of the EKF, then typically one is doing odom->base_link and the other is doing map->odom. Since you are running a SLAM package, then your map->odom is already handled, and so you only need one instance computing odom->base_link. I'm not sure what you're getting from the second EKF instance. I'd get rid of it and just fuse the visual odometry with the first EKF instance. Visual odometry ought to be continuous, so that shouldn't be a problem.

For (1), I can't really comment much more without sample input messages and your EKF configuration.

(2) will be a challenge, especially if your state vector doesn't use the same variables as the current one. The package doesn't currently have a nice way to define your own state vector, though adding another filter class (again, assuming it uses the exact same state variables) is pretty straightforward.

Originally posted by Tom Moore with karma: 13689 on 2018-01-26

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by nav-go on 2018-01-30:
Thanks for your answer Tom! Since posting my question, I was able to figure out the frames issue and now I have a working filter that takes into account IMU measurements and visual odometry. I had few quick questions that I hope you can answer. Please see my updated post.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.