No, I don't think your setup will work, although I haven't thought through it in great depth. In any case, it's not the way it's intended to be used. The odometry input to navsat_transform_node can just be your ekf_localization_node output (it defaults to odometry/filtered). navsat_transform_node needs the third input (the odometry from your state estimate) because it converts the GPS data into the coordinate frame of that message. If your robot starts out, for example, indoors, and then moves outdoors, you need to know its pose estimate at the moment it starts receiving GPS in order to make the transformed GPS data consistent with your current state estimate.
For you, as soon as your IMU data is fed to the filter, ekf_localization_node will produce a state estimate, at which point navsat_transform_node will have all the data it needs.
EDIT in response to question:
Your final setup will be this:
ekf_localization_node
Inputs
- IMU
- Transformed GPS data as an odometry message (
navsat_transform_node output)
Outputs
- Odometry message (this is what you want to use as your state estimate for your robot)
navsat_transform_node
Inputs
- IMU
- Raw GPS (NavSatFix)
- Odometry (output of
ekf_localization_node)
Outputs
- Transformed GPS data as odometry message
The data path is circular, but it's necessary. Once navsat_transform_node gets the first IMU message, it drops the subscription.
Originally posted by Tom Moore with karma: 13689 on 2014-12-26
This answer was ACCEPTED on the original site
Post score: 13
Original comments
Comment by AK47 on 2014-12-26:
Tom, thank you very much. If I understand correctly, the correct setup is to feed IMU data to ekf_localization_node, and then feed the output of this node. along with IMU and GPS data, to the navsat_transform_node to get the final estimation. Is this the correct setup? Thanks!
Comment by Tom Moore on 2014-12-26:
No, sorry. See the answer edit.
Comment by AK47 on 2014-12-26:
Tom, many thanks! I configure my estimation in the way as you suggested, and it seems to be working!
Comment by Zoid on 2017-02-19:
Hello,
I am really interested in the topic! Could you please post your launch files here to familiarizamyselfof how to setup my similar project? Thank you!
Comment by rz on 2018-04-19:
Hello AK47
I am really interested in the topic! Could you please post your launch files here to familiarizamyselfof how to setup my similar project? Thank you!
Comment by rezafirouzi on 2019-10-22:
Hi Tom,
Are you sure the navsat_transform_node drops subscription to odometry message(after first message)?
What I see in source code is that the subscription to IMU is shutdown after the first message. But not the Odometry.
Please clarify this issue.
Comment by Tom Moore on 2019-11-04:
Yes, that is correct. Edited, thanks.
Comment by ClintQ on 2021-03-19:
Hi Tom,
The setup that you have captured would require another ekf_localization_node correct? To establish the odom->base_link transform and then this setup for the map->odom transform. My question is what is the right odometry message to use for the input to the ekf_localization_node that is creating the odom->base_link transform if the odometry/gps output is feeding into the odometry input of the ekf_localization_node creating the map->odom transform?
The circular reference gets a little confusing. Thank you.
Comment by Tom Moore on 2021-03-22:
@ClintQ if you haven't already, would you mind asking that as a new question? Thanks.
Comment by lxg on 2021-07-06:
@Tom Moore, please take a look at my question. Despite the navsat_transform node not publishing the transformed GPS data, I am having two robots both starting at [0 0 0], even if am sure this is wrong. How can I ensure that at least the GPS positioning is used? Because independent GPS alone is giving better results than fusion. which should not be the case at all. Thanks
