# Revision history [back]

The approach you are describing consists of running two instances of an EKF. One with odometry and GPS (ekf_localization_node2) and one only with odometry (ekf_localization_node1). This is done because the GPS data is subject to discrete discontinuities (jumps) and it is likely to be unfit for use by navigation modules. Therefore, we would use odometry/filtered for navigation and odometry/filtered_map for localization.

If you are operating the robot manually with a remote and you do not need navigation, you can only use one instance. The odom and map frames are fix frames. Typically, the map frame is fixed at a specific location and the odom frame starts wherever you start robot localization. If you are not navigating autonomously, you can provide a fix transform between map to odom and you can have the EKF2 publishing odom->base_link. You will have to bear in mind that this can have jumps and it is not desirable to have a transform that can jump around. But for instance, if you have RTK GPS with high precision, maybe this is not as problematic.

As for your specific questions: (1) Depending on the robot you have but you can add wheel odometry or visual odometry. (2) No, you should provide the odometry inputs separately for both EKF instances.

The approach you are describing consists of running two instances of an EKF. One with odometry and GPS (ekf_localization_node2) and one only with odometry (ekf_localization_node1). This is done because the GPS data is subject to discrete discontinuities (jumps) and it is likely to be unfit for use by navigation modules. Therefore, we would use odometry/filtered for navigation and odometry/filtered_map for localization.

If you are operating the robot manually with a remote and you do not need navigation, you can only use one instance. The odom and map frames are fix frames. Typically, the map frame is fixed at a specific location and the odom frame starts wherever you start robot localization. If you are not navigating autonomously, you can provide a fix static transform between map to odom and you can have the EKF2 publishing odom->base_link. For example:

<node pkg="tf2_ros" type="static_transform_publisher" name="map_odom" args="0 0 0 0 0 0 map odom" />


You will have to bear in mind that this can have jumps and it is not desirable to have a transform that can jump around. But for instance, if you have RTK GPS with high precision, maybe this is not as problematic.

As for your specific questions: (1) Depending on the robot you have but you can add wheel odometry or visual odometry. (2) No, you should provide the odometry inputs separately for both EKF instances.