Open VRichardJP opened 1 year ago
In the second image, it does seem like to non-target obstacle was ignored. But just in case, can you run
ros2 topic echo /planning/scenario_planning/lane_driving/behavior_planning/behavior_path_planner/debug/avoidance_debug_message_array
I think for the pedestrian ObjectIsNotType
will be printed in the second
avoidance_info:
- object_id: ''
allow_avoidance: false
longitudinal_distance: 0.0
lateral_distance_from_centerline: 0.0
to_furthest_linestring_distance: 0.0
max_shift_length: 0.0
required_jerk: 0.0
maximum_jerk: 0.0
failed_reason: ObjectIsNotType
- object_id: 6cee772d36247e61b13266516b53093b
allow_avoidance: true
longitudinal_distance: 24.38448885981013
lateral_distance_from_centerline: 1.5808671530619405
to_furthest_linestring_distance: 5.532324530608035
max_shift_length: 4.684824530608035
required_jerk: 0.005692831476198248
maximum_jerk: 1.0
failed_reason: ''
If it is so, then the pedestrian object was ignored.
Yes, the avoidance_info
contains one entry for the pedestrian with ObjectIsNotType
. So if I understand correctly it means the avoidance does not try to avoid the pedestrian. In practice however, the pedestrian is avoided.
Yes, pedestrians are avoided indirectly.If you consider avoiding dangerous operations,additional rules need to be added.
Yes, if pedestrian is registered as non avoidable object, the generated avoidance path will be consider them. In your second case, it just happens that the pedestrian is nearby the bus and it "seems" as if it is avoiding the pedestrian.
By default, if it is not avoidance's object, if it is still blocking ego's route, ego will decelerate and stop.
You can get further information by turning on the debug markers.
Yes, I understand how the avoidance logic is implemented.
My point is whether it makes sense for the avoidance to "ignore" some class of obstacles. If this is for the safety of the operation, then it totally makes sense in the 1st scenario, however it is counter-productive in the 2nd scenario.
Indeed, because the pedestrian is ignored by the avoidance algorithm in the 2nd scenario, it can make the ego vehicle drive super close to the pedestrian, which is certainly not safe at all:
I see. My apologies, before proceeding, let me correct my understanding as follows
Expected Behavior
since the vehicle never avoid non-target obstacle, which in this case is the pedestrian.Is these correct?
Based on your report, the current behavior is similar to the Expected Behavior since the vehicle never avoid non-target obstacle, which in this case is the pedestrian.
I think I have confused everyone with the word "avoid", because we understand different things:
So when I say the expected behavior is that the vehicle should never avoid non-target obstacles, I mean no trajectory should be able to go around the object, even if it is unintentional.
It is maybe just the way I interpret the target_object
parameter, but I think it does not make much sense to have any target_object.xxx=false
if the current behavior is correct. In other word, we should either:
target_object
option, and have the avoidance planner avoid everythingI see.
I think we cannot assume that all user always have access to good perception inputs, therefore it make sense to allow the object type to be configurable.
On the other hand, since we also have the run out
module in the behavior_velocity_planner
that suppose to handle the pedestrian's scenario.
@VRichardJP @zulfaqar-azmi-t4
I think there are limited things we can do in behavior_path_planner
(bpp) when we consider its coverage. Also run_out
module in behavior_velocity_planner
is not sufficient in this scenario. What it can be done might be an improvement in obstacle_stop_planner
. I prepared some videos to explain why I think so:
1) In the first case, there are a static pedestrian and a parked bus behind it. In this scenario ego vehicle avoids the parked bus -not the pedestrian- but at the end it drives very closely to the pedestrian anyway.
This is not what we want so as @xmfcx suggested in ASWG meeting yesterday; in bpp when it is deciding for shift points (in avoidance module) it can be checked if there are any objects on the path -which we don't wanna avoid such as pedestrians- existing closer than the target obstacle. And it would work on this case.
2) However if pedestrian appears next to the path after avoidance is done then there is nothing can be done in bpp layer. Because the pedestrian is not on the path. At the end ego vehicle would drive closely to the pedestrian.
3) We can launch run_out
module as @zulfaqar-azmi-t4 suggested. However it wouldn't solve the problem. Ego vehicle would drive closely to the pedestrian anyway.
As a solution we could increase lateral_margin
parameter in obstacle_stop_planner
:
However it would be valid for all the obstacle points and ego vehicle would stop for the cases we don't want it to stop (narrow roads, close vehicles on the opposite/neighbor lane). So what we can do is that in obstacle_stop_planner
for the points belong to the selected objects (pedestrians in this case) lateral_margin can be larger. I believe it would solve this problem.
What are your opinions on this?
I want to work on this approach. I will create an issue and PR about it.
@mehmetdogru Eventually, I think the planner should be able to reassess the situation and invalidate an avoidance path if it does not make sense anymore. For example, if the avoidance path is now blocked half-way, the vehicle should stay on its lane (or go back to it), and wait until the path is clear.
In your second video, if a pedestrian appears on the path (or if lateral_margin is high enough), the vehicle will stop in front of it and wait like this in the middle of the road. It is definitely better than driving 10cm away from the pedestrian, but it is not an ideal situation either.
@VRichardJP
I agree. Maybe avoidance path can be reverted in such cases.
Although, I am afraid just checking around the path will not be enough considering even though path is reverted, ego vehicle sometimes won't have time to go back to it and stay in the middle of the road anyways. So since run_out
module is supposed to handle pedestian scenarios as @zulfaqar-azmi-t4 said, maybe something like run_out
module can be implemented in bpp
which considers the predicted paths of target objects or in such scenarios bvp
can send a message back to bpp
so the avoidance path can be reverted on time.
@satoshi-ota
Could you kindly provide your ideas about the issue. I learnt that you are working on avoidance module for further improvements. I would really like to hear your opinion about this as well.
@VRichardJP @mehmetdogru @beyzanurkaya @shulanbushangshu @zulfaqar-azmi-t4
Thanks for the discussion. Let me check one thing.
You do not want the vehicle to drive near the pedestrian only when the vehicle is in avoidance maneuver, right ? Or, you don't want not only when the vehicle is in avoidance maneuver but also when the vehicle is driving lanes without avoidance.
If it is the former, then we have the following options:
In the latter case, then we have the following options:
obstacle_stop_planner
or improve obstacle_stop_planner
feature as @mehmetdogru said hereobstacle_cruise_planner
.The behavior of obstacle_cruise_planner
is basically the same as the function of obstacle_stop_planner
with respect to obstacle stopping, but by default it determines if the Ego should stop based on not pointcloud but object recognition.In the current architecture, the feature that generates avoidance paths is separated from the feature that stops for obstacles, and I do not want to merge those features, so I think it is better to fix this issue by improving the obstacle stop functions (obstacle_stop_planner
, obstacle_cruise_planner
, run_out
). cc @TakaHoribe
@satoshi-ota I think the vehicle behavior should be consistent over the several scenarios. For example:
Sorry it's just a bunch of disorganized ideas, but I guess it gives a good idea of the behavior I would expect from autoware in the avoidance situation. I think it shouldn't be too difficult to add the few extra rules above to make the avoidance more predictable/human-like.
This pull request has been automatically marked as stale because it has not had recent activity.
https://github.com/autowarefoundation/autoware/discussions/3097 Needs to be discussed after the planning arch is updated again.
This pull request has been automatically marked as stale because it has not had recent activity.
Checklist
Description
In
behavior_path_planner
module, it is possible to disable avoidance for some obstacles, such as pedestrian.For example in the following situation, a pedestrian is on the path and the vehicle does not try to avoid it:![Screenshot from 2022-10-18 15-57-11](https://user-images.githubusercontent.com/18645627/196358923-65ae5855-07d9-49f5-80d9-03c6b89658b0.png)
However, if there is another obstacle that can be avoided behind the pedestrian, then the vehicle tries to avoid both:![Screenshot from 2022-10-18 15-57-39](https://user-images.githubusercontent.com/18645627/196359776-1a7868ef-49f0-4c02-a5cf-2e02b7532c2d.png)
I guess "unavoidable" obstacles have been introduced to avoid risky manoeuver (e.g. the pedestrian will likely not stay on the middle of the road, so it is better to simply wait). In such case, the vehicle should stop in front of the pedestrian like in the first screenshot.
Expected behavior
The vehicle never avoid non-target obstacle.
Actual behavior
non-target obstacle is avoided under some circumstances
Steps to reproduce
see pictures above
Versions
No response
Possible causes
No response
Additional context
No response