-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use laser_filter pipeline for scanner #732
Comments
@ipa-srd |
With https://github.com/ipa320/cob_driver/pull/358 max range measurements are properly set, i.e. their values are >= than the configured max_range of the respective laser scanner. This is needed so that a node can properly identify max range measurements within the ranges array. For example. the localization module normally filters out max range measurements to avoid matching those measurements against the map. |
Example config:
Example node
|
in the example config |
once we use this filter_chain, i.e. setting out-of-range values to |
the
thus, I'm just adding the |
http://wiki.ros.org/costmap_2d/hydro/obstacles |
I tested the related PRs today, i.e. "max_range" of sick_s300 + RangeFilter pipeline + inf_is_valid in costmap However, the behavior is not as expected, i.e. ranges that are set to @ipa-jba can we have a look at this together sometime next week? |
to debug raytracing, @ipa-srd suggested to temporarily remove the inflation layer to better see the actually blocked cells |
without having looked into code the chain: setting max range to inf -> using inf_is_valid in costmap does not help, i.e. occupied areas are not cleared although the ray tracing of max range measurements should go through the cell. A successfully tested workaround is to have a Example of the node:
and the laser filter config:
move_base_local_costmap_params.yaml:
@ipa-fxm fyi |
thanks, I will try this next week |
yes, currently running on a customer agv in an industrial environment where a lot of max range measurements appear |
I'll re-open, as this issue documents quite a bit regarding issues not yet solved:
|
as discussed with @ipa-fxm, the current solution should be reworked. Only the scan that is going into the costmap should be filtered to 10 m. The filter should have no effects on the standard scan and also not on |
I implemented this for the unity_robots...it's a pr still which @HannesBachter wanted to test together with slam... |
as discussed today with @ipa-srd @HannesBachter, the scan toolchain looks like this front - ... ... like this https://github.com/unity-robotics/unity_robots/pull/46 and https://github.com/unity-robotics/msh/pull/267 now implement this for |
@ipa-srd @HannesBachter front - ... pushing |
@ipa-jba @ipa-flg, I discussed this with @ipa-fxm and in our opinion the second chain makes more sense since it's more performant but we would need to change the costmap params in the way that the obstacle layer only subscribes to |
I discussed it with @ipa-flg and I'm going to implement the second version both for then - in order to use the range-filtered scans to improve costmap clearing - @ipa320/navigation-push will need to adjust their respective costmap yaml files to accept the single, range_filtered, unified scan topic The navigation configs still work without changing anything. |
the laser filter pipeline has been set up for thus, I'm closing this issue |
according to @ipa-jba, laser_filters is quite powerful
investigate setting up a proper filter_pipeline for e.g. the sick scanners that would replace:
max_range_fix via http://wiki.ros.org/laser_filters#LaserScanRangeFilter@ipa-bnm @ipa-fmw FYI
The text was updated successfully, but these errors were encountered: