ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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.
2 | No.2 Revision |
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.