ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Ok, lots of things:
/odometry/filtered
. You have two different state estimates going out over the same topic.frame_id
on the rtabmap
data is odom, yet you are fusing it in both instances. That means that for the EKF instance where world_frame_id
is map, it's going to transform the data from odom to map, but that is the very transform that instance is trying to produce. I would avoid that.two_d_mode
on, yet you are fusing Z, roll, and pitch in a few places. It doesn't hurt anything, but it's better to let them be false.All that aside, though, I think you might not be using this correctly. Why do you need two instances? Your odom frame is meant to be continuous, yet rtabmap
will almost certainly give you positions that jump around a small amount. Perhaps you should give me more information about what you're trying to do. As it is, your map EKF instance is probably interfering with the operation of rtabmap
.
2 | No.2 Revision |
Ok, lots of things:
/odometry/filtered
. You have two different state estimates going out over the same topic.frame_id
on the rtabmap
data is odom, yet you are fusing it in both instances. That means that for the EKF instance where world_frame_id
is map, it's going to transform the data from odom to map, but that is the very transform that instance is trying to produce. I would avoid that.two_d_mode
on, yet you are fusing Z, roll, and pitch in a few places. It doesn't hurt anything, but it's better to let them be false.All that aside, though, I think you might not be using this correctly. Why do you need two instances? Your odom frame is meant to be continuous, yet rtabmap
will almost certainly give you positions that jump around a small amount. Perhaps you should give me more information about what you're trying to do. As it is, your map EKF instance is probably interfering with the operation of rtabmap
.
EDIT 1 in response to comments
It's not that the second instance is needed per se, but if you want to control your robot without it constantly changing direction when the pose jumps (and it will), you'll want to have two instances. For instance 1, fuse just the IMU and visual odometry data (just use the velocity). What is the LIDAR providing? I don't see that in your launch file.
My advice would be to start with the odom frame EKF, and add one sensor at a time. Make sure you are completely satisfied that it's behaving, then introduce another sensor. When you're done fusing all the continuous sensors into the odom instance, add the second map instance, and again, start with one sensor. Debugging these kinds of things gets very difficult when you have this many sensor sources, so it's critical to make sure each component is working and configured correctly.