Comments (20)
@ipa-srd @HannesBachter
how about this?
front - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|
left - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|- (unifier) - scan_unified
right - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|
... scan_unified
- (range filter) - scan_unified_filtered
(10m) - (zone filter) - costmap_scan_filtered
pushing scan_unified
through additional filters, i.e. range filter and zone filter seems the easier thing to do (less nodes: 1vs.6 range filter 1vs.2 scan unifier)...in particular because scan_ranged
topics are nowhere used anyway...afaik
from cob_robots.
@ipa-srd
can you explain again, why it was necessary to avoid NaN
in the laser scan and replace it with max_range
?
from cob_robots.
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.
However, in the current setup, this would lead to an undesired behavior in the costmap which will discard those max range measurements for ray tracing. In open areas where you have a lot of max range measurements, this leads to the problem that dynamic objects are not cleared properly. With the feature implemented by @ipa-jba in ros-perception/laser_filters#56, this problem can be resolved. The filter sets all max range measurements to inf. Together with setting the inf_is_valid
param in the obstacle_layer to true, this fixes the problem.
from cob_robots.
Example config:
scan_filter_chain:
- name: self_meas
type: LaserScanAngularBoundsFilter
params:
lower_angle: 0.78
upper_angle: 3.91
- name: max_range
type: LaserScanRangeFilter
params:
use_message_range_limits: true
upper_replacement_value: .inf
Example node
+ <node pkg="laser_filters" type="scan_to_scan_filter_chain" name="laser_filter">
+ <rosparam command="load" file="$(find striml_hardware_config)/robots/$(arg robot)/config/laser_filter_chain.yaml" />
+ <remap from="scan" to="/base_laser_front/scan" />
+ <remap from="scan_filtered" to="scan" />
+ </node>
from cob_robots.
in the example config upper_replacement_value
should be on the same indentation level as use_message_range
from cob_robots.
once we use this filter_chain, i.e. setting out-of-range values to inf
, where (in which nav.yaml) is the inf_is_valid
param to be set?
from cob_robots.
the LaserScanAngularBoundsFilter
has weird behavior:
- it cuts away scan points in the given interval rather than keeping just those
- also negative values for the angle parameters seem not to cause problems
thus, I'm just adding the LaserScanRangeFilter
and keeping the current cob_scan_filter
for the angular bounds
from cob_robots.
http://wiki.ros.org/costmap_2d/hydro/obstacles
and add in pkg_nav_config/robots//nav/move_base_local_costmap_params.yaml in the respective obstacle layer
from cob_robots.
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 inf
in the laser scan used as a costmap observation source, does not really clear the costmap properly...
@ipa-srd has confirmed that the behavior seen is not correct
@ipa-jba can we have a look at this together sometime next week?
from cob_robots.
to debug raytracing, @ipa-srd suggested to temporarily remove the inflation layer to better see the actually blocked cells
from cob_robots.
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 LaserScanRangeFilter
setting max range to some value higher than costmap bounds but lower than obstacle_range param in costmap params and using this scan msg exclusively for move_base.
Example of the node:
<node pkg="laser_filters" type="scan_to_scan_filter_chain" name="laser_filter_planning">
<rosparam command="load" file="$(find striml_hardware_config)/robots/$(arg robot)/config/laser_filter_chain_planning.yaml" />
<remap from="scan" to="scan" />
<remap from="scan_filtered" to="scan_planning" />
</node>
and the laser filter config:
scan_filter_chain:
- name: max_range_to_finite
type: LaserScanRangeFilter
params:
use_message_range_limits: false
upper_threshold: 16.0
upper_replacement_value: 16.0
move_base_local_costmap_params.yaml:
# The parameters for the rolling_window (must be set if rolling_window = true)
width: 8.0 # default: 10
height: 8.0 # default: 10
resolution: 0.05 # default: 0.05
origin_x: 0.0 # default: 0.0
origin_y: 0.0 # default: 0.0
obstacle_layer:
# Definition of the sensors/observation sources
observation_sources: laser_scan_front
# Parameters of the source: laser_scan_front
laser_scan_front:
sensor_frame: base_laser_link # The frame of the origin of the sensor, default: ""
topic: /scan_planning # The topic on which sensor data comes in for this source, default: source_name
data_type: LaserScan # The data type associated with the topic, default: "PointCloud"
marking: true # Whether or not this observation is used to mark obstacles, default: true
clearing: true # Whether or not this observation is used to clear out freespace, default: false
# The default maximum distance from the robot at which an obstacle will be inserted into the cost map in meters
obstacle_range: 18.0 # default: 2.5
# The default range in meters at which to raytrace out obstacles from the map using sensor data
raytrace_range: 18.0 # default: 3.0
@ipa-fxm fyi
from cob_robots.
thanks, I will try this next week
are you actually using your pipeline/config on a real robot/agv?
from cob_robots.
yes, currently running on a customer agv in an industrial environment where a lot of max range measurements appear
from cob_robots.
I'll re-open, as this issue documents quite a bit regarding issues not yet solved:
- replace cob_scan_filter via http://wiki.ros.org/laser_filters#LaserScanAngularBoundsFilter
- implement proper
inf_is_valid
behavior (as it affects RangeFilter parameters
from cob_robots.
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 scan_unified
.
We suggest to have an additional filter at the end of the current chain which does the 10 m cut and the outcoming msg is named something like scan_costmap
or similar to make it clear.
from cob_robots.
I implemented this for the unity_robots...it's a pr still which @HannesBachter wanted to test together with slam...
that pr could be ported to cob_robots sidentically...
@ipa-srd @HannesBachter please see https://github.com/unity-robotics/unity_robots/pull/46
from cob_robots.
as discussed today with @ipa-srd @HannesBachter, the scan toolchain looks like this
front - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|
left - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|- (unifier) - scan_unified
right - scan_raw
- (cob_scan_filter) - scan
(i.e. 30m) -|
... scan
(30m)- (range filter) - scan_ranged
(10m) -|
... scan
(30m)- (range filter) - scan_ranged
(10m) -|- (unifier) - scan_unified_ranged
... scan
(30m)- (range filter) - scan_ranged
(10m) -|
... scan_unified_ranged
- (zone filter) - costmap_scan_filtered
like this scan_unified
is back to the long-range scan as before, e.g. used for planning, rviz, ...
like this scan_unified_ranged
is a new topic only used in the local_costmap layer_0 for planning
https://github.com/unity-robotics/unity_robots/pull/46 and https://github.com/unity-robotics/msh/pull/267 now implement this for unity_robots
after testing by @HannesBachter, I will migrate this to cob_robots
, too
from cob_robots.
@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 scan_unified_filtered
(instead of currently subscribing to the scan's individually). You see any problem with that?
from cob_robots.
I discussed it with @ipa-flg and I'm going to implement the second version both for unity_robots
and cob_robots
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 /scan_unified_filtered
rather than the three individual scans /base_laser_front/scan
, /base_laser_left/scan
, /base_laser_right/scan
!
The navigation configs still work without changing anything.
However, they still use the full-range scans and cannot benefit the improved costmap clearing behavior!
Note that there won't be individual, range_filtered scans with this approach!
from cob_robots.
the laser filter pipeline has been set up for scan_unified
in #757
now it could be used in the costmap.yaml - if desired...
thus, I'm closing this issue
from cob_robots.
Related Issues (20)
- cob4-7: head axis error HOT 8
- [Enhancement] Update xacro's according to latest syntax HOT 2
- Move base home offset configuration to cob_calibration_data
- Use CMake-Macro to retrieve sub-dir-list HOT 2
- Enable heartbeat producer for Schunk arms
- cob3-6 files missing HOT 6
- verify use of image_proc in indigo/kinetic HOT 1
- base_controller not running correctly in simulation HOT 10
- upload_robot.launch HOT 7
- cob3-2 tray not moving (0) HOT 7
- urdf_tutorial not compatible with the current cobs URDF (2) HOT 1
- review camera coordinate frames HOT 5
- [diagnostics_aggregator] fix aggregator groups for c++-based hz-monitor HOT 1
- Error while doing moveit setup assistance HOT 3
- cleanup after canopen migration of all robots using base_drive_chain
- cob_bringup 0.6.11 in kinetic fails on debian builds HOT 3
- delete EOL robots and EOL packages HOT 12
- raw3-x :Costmap2DROS transform timeout and Could not get robot pose, cancelling reconfiguration
- Prepare cob4-25 for Noetic Upgrade HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cob_robots.