[collision_monitor] Add temporal axis to min_points behavior

[gennartan]

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]

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]

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