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.
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:
- 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?
- 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.
Post score: 2