You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: nav2_collision_monitor/README.md
+24-6Lines changed: 24 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,7 @@
1
1
# Nav2 Collision Monitor
2
2
3
+
## Collision Monitor
4
+
3
5
The Collision Monitor is a node providing an additional level of robot safety.
4
6
It performs several collision avoidance related tasks using incoming data from the sensors, bypassing the costmap and trajectory planners, to monitor for and prevent potential collisions at the emergency-stop level.
5
7
@@ -12,7 +14,7 @@ The costmaps / trajectory planners will handle most situations, but this is to h
12
14
13
15

14
16
15
-
## Features
17
+
###Features
16
18
17
19
The Collision Monitor uses polygons relative the robot's base frame origin to define "zones".
18
20
Data that fall into these zones trigger an operation depending on the model being used.
@@ -23,7 +25,6 @@ The following models of safety behaviors are employed by Collision Monitor:
23
25
24
26
***Stop model**: Define a zone and a point threshold. If more that `N` obstacle points appear inside this area, stop the robot until the obstacles will disappear.
25
27
***Slowdown model**: Define a zone around the robot and slow the maximum speed for a `%S` percent, if more than `N` points will appear inside the area.
26
-
***Limit model**: Define a zone around the robot and clamp the maximum speed below a fixed value, if more than `N` points will appear inside the area.
27
28
***Approach model**: Using the current robot speed, estimate the time to collision to sensor data. If the time is less than `M` seconds (0.5, 2, 5, etc...), the robot will slow such that it is now at least `M` seconds to collision. The effect here would be to keep the robot always `M` seconds from any collision.
28
29
29
30
The zones around the robot can take the following shapes:
@@ -38,20 +39,19 @@ The data may be obtained from different data sources:
The Collision Monitor is designed to operate below Nav2 as an independent safety node.
44
45
This acts as a filter on the `cmd_vel` topic coming out of the Controller Server. If no such zone is triggered, then the Controller's `cmd_vel` is used. Else, it is scaled or set to stop as appropriate.
45
46
46
47
The following diagram is showing the high-level design of Collision Monitor module. All shapes (Polygons and Circles) are derived from base `Polygon` class, so without loss of generality we can call them as polygons. Subscribed footprint is also having the same properties as other polygons, but it is being obtained a footprint topic for the Approach Model.
47
48

48
-
49
-
## Configuration
49
+
### Configuration
50
50
51
51
Detailed configuration parameters, their description and how to setup a Collision Monitor could be found at its [Configuration Guide](https://navigation.ros.org/configuration/packages/configuring-collision-monitor.html) and [Using Collision Monitor tutorial](https://navigation.ros.org/tutorials/docs/using_collision_monitor.html) pages.
52
52
53
53
54
-
## Metrics
54
+
###Metrics
55
55
56
56
Designed to be used in wide variety of robots (incl. moving fast) and have a high level of reliability, Collision Monitor node should operate at fast rates.
57
57
Typical one frame processing time is ~4-5ms for laser scanner (with 360 points) and ~4-20ms for PointClouds (having 24K points).
@@ -66,3 +66,21 @@ The following notes could be made:
66
66
67
67
* Due to sheer speed, circle shapes are preferred for the approach behavior models if you can approximately model your robot as circular.
68
68
* More points mean lower performance. Pointclouds could be culled or filtered before the Collision Monitor to improve performance.
69
+
70
+
71
+
## Collision Detector
72
+
73
+
In some cases, the user may want to be informed about the detected obstacles without affecting the robot's velocity and instead take a different action within an external node. For example, the user may want to blink LEDs or sound an alarm when the robot is close to an obstacle. Another use case could be to detect data points in particular regions (e.g extremely close to the sensor) and warn of malfunctioning sensors. For this purpose, the Collision Detector node was introduced.
74
+
75
+
It works similarly to the Collision Monitor, but does not affect the robot's velocity. It will only inform that data from the configured sources has been detected within the configured polygons via message to the `collision_detector_state` topic.
76
+
77
+
### Features
78
+
79
+
Similarly to the Collision Monitor, the Collision Detector uses polygons relative the robot's base frame origin to define "zones".
80
+
However, unlike the Collision Monitor that uses different behavior models, the Collision Detector does not use any of them and therefore the `action_type` should always be set to `none`. If set to anything else, it will implicitly be set to `none` and yield a warning.
81
+
82
+
The zones around the robot and the data sources are the same as for the Collision Monitor, with the exception of the footprint polygon, which is not supported by the Collision Detector.
83
+
84
+
### Configuration
85
+
86
+
Detailed configuration parameters, their description and how to setup a Collision Detector could be found at its [Configuration Guide](https://navigation.ros.org/configuration/packages/configuring-collision-detector.html).
0 commit comments