Initial pose and odometry reuse about dynamic_robot_localization HOT 6 CLOSED

I have added a transform broadcaster here:
https://github.com/carlosmccosta/pose_to_tf_publisher/blob/melodic-devel/src/pose_to_tf_publisher.cpp#L411

So even if the last pose it not valid, TF from map to odom will continue to publish by just publishing the latest valid transform. It does not seem to help

from dynamic_robot_localization.

Hello,

For disabling the initial pose estimation algorithms you just need to set:
https://github.com/inesc-tec-robotics/dynamic_robot_localization/blob/noetic-devel/launch/dynamic_robot_localization_system.launch#L25

<arg name="yaml_configuration_pose_estimation_filename" default="$(find dynamic_robot_localization)/yaml/configs/empty.yaml" />

Then confirm that the yaml blocks associated with the initial pose estimation, namely keypoint detection, description and feature matching are not loaded in the ros parameter server:

rosparam get / -p

For keeping publishing TF continuously, you need to set a positive rate and a negative timeout
https://github.com/inesc-tec-robotics/dynamic_robot_localization/blob/noetic-devel/launch/dynamic_robot_localization_system.launch#L91
https://github.com/carlosmccosta/pose_to_tf_publisher/blob/melodic-devel/src/pose_to_tf_publisher.cpp#L416

<arg name="publish_pose_tf_rate" default="10.0" />
<arg name="publish_last_pose_tf_timeout_seconds" default="-3.0" />

Have a nice day,

from dynamic_robot_localization.

@carlosmccosta Thanks.

Btw, how can I handle the situatuins when only 2 degree of freedom is available for the DRL? For example going through the corridor? The problem I have is that my odometry is pretty accurate but when going through a long corridor, DRL constantly shifts my robot and at the end of the corridor it has shifted it quite a while and unable to recover because I have set the maximum correction to be less than a meter as my odometry is very accurate.

from dynamic_robot_localization.

Hello,

Point cloud registration algorithms do not model the dynamics / motions of robots (such as velocity and accelerations) and do not merge localization data from several sources.
For dealing with these issues, you can try to use unscented kalman filters with drl, by activating use_ukf_filtering.

This will activate the generation of the covariance matrix.
This is disabled by default because covariances are tricky to compute and typically are not very accurate.

You probably will need to explore the robot_localization for tuning it to your specific use case, namely for merging localization data from odometry and drl.

Have a nice day,

from dynamic_robot_localization.

Hi thanks. Also, in some situations you will get only dynamic objects around you or no laser scans due to large distances. Is it possible to spot such cases? As I want to just stop the robot or warn and do not update the pose

from dynamic_robot_localization.

Hello,

drl has transformation validators that allow to specify the maximum outlier percentage between the lidar data and the reference map.

When drl does not receive lidar data that allows an alignment that respects the outlier thresholds for 3 seconds (in relation to the time of the last valid pose), it will stop publishing the tf map -> odom.

This timeout to stop publishing tf is defined in argument publish_last_pose_tf_timeout_seconds.

As such, for detecting the scenarios that you describe, you just need to adjust the tf timeout and the max_outliers_percentage and then inspect the tf map -> base_footprint (or other base_link_frame_id that you specified to drl here).

You may also need to adjust the minimum_number_of_points_in_ambient_pointcloud and max_inliers_distance to values that are suitable to your use case.

Nota that drl_configs.yaml is for documentation only, specifying how you can configure the drl pipeline.

The yamls loaded are specified in the dynamic_robot_localization_system.launch

Have a nice day,

from dynamic_robot_localization.