Skip to content
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

[collision_monitor] Add temporal axis to min_points behavior #4364

Open
gennartan opened this issue May 23, 2024 · 2 comments
Open

[collision_monitor] Add temporal axis to min_points behavior #4364

gennartan opened this issue May 23, 2024 · 2 comments
Labels
enhancement New feature or request in progress

Comments

@gennartan
Copy link
Contributor

Feature request

Feature description

The current behavior of min_points parameter is to apply a speed reduction (or whatever action is required by the collision monitor) when the last valid measurement point is triggers this behavior. In case of noisy measurement, one single measurement could cause the robot to slow down quickly, causing jerky motion.

The idea to add a temporal axis to this parameter would be to require a minimum of X positive consecutive measurement to trigger the collision monitor to slow / stop the robot. And also a minimum of Y negative consecutive measurement to continue normally.

Implementation considerations

Another idea could be to filter the output of the measurement source. But this would add imprecision and timing in the actual measurement. I am thinking of of robot driving on grass. Simply depending on wind conditions, ultrasonic sensors could detect leaves or higher weeds occasionally even with correctly calibrated / positioned sensors. So I think that adding this feature directly on the collision monitor could give the best results.

@SteveMacenski SteveMacenski added the enhancement New feature or request label May 23, 2024
@SteveMacenski
Copy link
Member

In case of noisy measurement, one single measurement could cause the robot to slow down quickly, causing jerky motion.

I suppose historically the kinds of sensors used for collision monitoring shouldn't be super noisy to cause such issues. However, given this isn't a safety-rated solution and it is useful for robots that may only have noisy sensors that are unable to be finely filtered due to computational / BOM considerations, I think this is a very good suggestion.

Another idea could be to filter the output of the measurement source.

I think that should be done by the user if that's the right answer so they can filter it as appropriate for their sensor modality / environment / application. Else, this project could have embedded a ton of unique filters that should probably just stand alone. As you mention with your grass example, thats would require a pretty unique filter, so its best that there's a node between the data & the collision monitor to perform that filtering pre-collision-monitoring.

So, I like adding the temporal element! And the filter bit is definitely still an option (maybe we can document that potential pipeline design?) in addition to temporal for those that that is a good solution.

Are you open to contributing that?

@gennartan
Copy link
Contributor Author

Yes I am open to contributing that ! I'll get started soon

gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
@gennartan gennartan mentioned this issue Jun 1, 2024
7 tasks
gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jun 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_consecutive_in` / `min_consecutive_out`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jul 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_time_in_sec` / `min_time_out_sec`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jul 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_time_in_sec` / `min_time_out_sec`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
gennartan added a commit to gennartan/navigation2 that referenced this issue Jul 1, 2024
…ation#4364)

The polygon action triggers when `min_points` from the detection sources
are inside the polygon under test. In case of noisy measurement close to
the threshold, this could cause jerks on the robot velocity command.

* Add polygon parameters `min_time_in_sec` / `min_time_out_sec`
  that defines the consecutive number of times the controller loop must
  detect `min_points` inside / outside the given polygon to activate its
  action. Those parameters act as a Schmitt trigger low and high
  threshold.

Signed-off-by: Antoine Gennart <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request in progress
Projects
None yet
Development

No branches or pull requests

2 participants