[Collision_monitor] Approach polygon time=0 step is not processed about navigation2 HOT 7 CLOSED

This makes sense to me, I think the most straightforward fix would be to add something like

    if (getPointsInside(collision_points) >= min_points_) {
      return 0.0;
    }

at the beginning of getCollisionTime. What do you think?

Adding a test for this would be great

from navigation2.

That's what I was thinking about. (plus init time at simulation_time_step_ in the loop).

My only concern is that people may have used this bug as a feature to evade when the robot is touching a wall for example.

from navigation2.

My only concern is that people may have used this bug as a feature to evade when the robot is touching a wall for example.

This should have been implemented with #3313 afaik so I don't see the reason to keep this "feature" in that way

(plus init time at simulation_time_step_ in the loop

hmm, I'm not sure but I think this is not necessary since projectState first projection is at Time=0 + dt, no?
Alternatively to having an explicit check at time=0, we could initialize double time = -simulation_time_step_, although that looks a bit weird

from navigation2.

Actually, thinking about this again, I think there is no avoiding the collision monitor misbehaving if simulation_time_step is too big. Implementing what we just discussed would avoid moving if the robot is already in collision, but it would not avoid the collision if the robot is close to collision, simulation_time_step is big and the velocity sent is big enough.

It might still be worth it to check for collision at time=0 but essentially simulation_time_step still need to be small enough to avoid collisions reliably.

from navigation2.

Yes, but at least, when the robot is in collision it is not pushing anymore.

hmm, I'm not sure but I think this is not necessary since projectState first projection is at Time=0 + dt, no?

The issue is that the value returned is time (0.0) not time+dt

Alternatively to having an explicit check at time=0, we could initialize double time = -simulation_time_step_, although that looks a bit weird

Yes it will look weird and it will return -simulation_time_step_ when already in collision.

A better solution is to make the projectState() AFTER the getPointsInside check:

• the time 0.0 is tested
• The return time is valid

from navigation2.

A better solution is to make the projectState() AFTER the getPointsInside

Agree! Feel free to open a PR

from navigation2.

Seems rational, thanks for the thread on the European timezone. I have nothing further to add :-)

from navigation2.