The point of navsat_transform_node is to convert GPS data into world-frame coordinates in a nav_msgs/Odometry message. The sensor you are describing is not actually a GPS, and already provides the (X, Y) position of your robot, so just use that data directly as an input to the EKF (i.e., don't bother running navsat_transform_node).
Also, I don't recommend feeding the output of (1) into (2). Just fuse the same inputs that (1) has, and add the input for the indoor GPS sensor.
Remember that you don't want to have more than one EKF input measuring the same pose variable (X, Y, Z, roll, pitch, or yaw).
EDIT 1 to clarify previous answer:
Sure, you can run two state estimation nodes. You can do something like this:
- EKF (odom): fuse wheel encoder odometry (velocities) and IMU
- EKF (map): fuse wheel encoder odometry (velocities), IMU, and the nav_msgs/Odometry message that is being spit out by your indoor "GPS."
My point is that if you had a real GPS unit, the role of navsat_transform_node would be to convert latitude and longitude into a pose that you can fuse into the second EKF. Since you already have the indoor beacons spitting out pose data in a message type that the EKF can take in directly, you don't need navsat_transform_node.
Originally posted by Tom Moore with karma: 13689 on 2017-05-04
This answer was ACCEPTED on the original site
Post score: 0
Original comments
Comment by bluehash on 2017-05-04:
A little confused with the documentation here and what you said. Do I still use two state estimation nodes? The GPS is discontinuous.
- Cont. sensors with world_frame as odom.
- Cont. sensors + GPS with world_frame as map.
What happens to the output of 1. in this case?
Comment by Chrisando on 2019-06-06:
Please correct me if I am wrong, to my current understanding navsat_transfrom_node not only transforms GPS data into nav_msgs/Odometry message but also finds a transformation between the starting point of the robot and the first GPS measurement. My indoor GPS beacons report poses in the different coordinate frame then the starting frame of the robot. Is there any package that would take care of this transformation for me? Alternatively, what would be the most convenient way to achieve the same behavior? Modify navsat_transform_node to work with indoor GPS beacons instead of normal GPS?
Comment by Tom Moore on 2019-06-13:
You should just be able to create a simple python node that takes in the initial pose of your robot in your world frame, and the initial pose that comes from your indoor GPS beacons, creates a static transform between them, and publishes. Then the EKF can receive your GPS poses, transform them, and fuse them.
Comment by Chrisando on 2019-06-13:
Thank you Tom for answer! How about to orientation problem? (GPS only gives x,y,z position). Shall I make my robot move forward some distance and calculate orientation based on that? How is it usually done? Thank you!
Comment by Tom Moore on 2019-07-03:
If you lack an IMU, then yes, that seems like a valid approach.
