Can you post a sample IMU message? At first glance, I'd say you should get rid of your xxx_rejection_threshold settings. As for your question about tf
, ekf_localization_node
publishes a tf
transform from the world_frame to the base_link_frame, and navsat_transform_node
(optionally) publishes a transform from the UTM grid to your world frame. Even though you have that parameter set to false, the TransformBroadcaster object gets declared anyway, and I'm guessing that's enough to cause the graph to draw the arrow.
EDIT in response to updates/comments: the rejection thresholds are intended to help reject outlier measurements. Given your measurement sources, I don't think you need them. Just delete them from your launch file.
I think you should back up and try one thing at a time. Just run ekf_localization_node
, and start with just your IMU. Make sure that it's producing output, and then move on to integrating the navsat_transform_node
. And to answer what I think you were asking, yes, if you have some other source of odometry for your robot, then you should definitely fuse that as well.
EDIT 2: The nav_msgs/Odometry message uses quaternions to represent orientations. This is common in ROS. If you want to transform it, you'll need to write a node that takes in the quaternion and converts it. Alternatively, you can use tf_echo
to listen to the world_frame->base_link_frame transform being broadcast by ekf_localization_node
. tf_echo
does the conversion for you.
For the GPS, no, you don't currently need a base_link->gps transform.
EDIT 3 (in response to comments): I'm afraid I don't understand. What do you mean by you "adapted an EKF"? ekf_localization_node
and navsat_transform_node
are all you should need. Do rostopic echo /odometry/gps
. If it's not publishing, then navsat_transform_node
isn't getting all the data it needs, or there's an issue with the data it's getting. As to whether I'll revise the code, if you meant that I should fix navsat_transform_node
, I think it's more likely that there's an issue with the data. If you meant can I revise your code, I'm afraid I don't have the spare time.
EDIT 4: After looking at your debug file, I have a few notes:
- Your position is definitely not 0. I don't know what topic you're listening to or for how long, but if you search through the debug file for "Corrected full state is," you'll see that it's definitely integrating your GPS and IMU data, and that your positions are not 0. Are you certain you're echoing the right topic?
- That said, the GPS odometry messages that are coming in are all over the place. Not sure why. Have you plotted raw data from all your sensors to make sure the incoming data is correct?
- Your IMU data has incorrect accelerations. If you have it mounted flat, then your linear acceleration should be +9.81 for Z. Are you using a Microstrain ...
(more)
Removed the comments for easier reading.
I simplified the nodes and included the rostopic echo. Thank you very much
I think you're going to need to be more descriptive than "is not correct." What exactly is wrong with it? Is it always zero? Does it jump around too much? Feel free to record and post a bag file and I'll take a look when I get a chance.
The odometry/filtered is giving a consistent value and suddenly begins to increase much and then returns to converge to values consistent . I leave a link with a rosbag where you can view all the topics . Thank You https://www.dropbox.com/s/rjqd6lc6tqt...
Cool, I'll check it out soon.