False positive of Emergency Stop

[Kim-mins]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

Hi team,

I'm currently running Autoware with Carla, and found a situation that Autoware activates emergency stop, and makes the vehicle immobile, even though there's no reason for stopping.
Here's the rviz video of the situation: [rviz]

As the video shows, while turning left, emergency stop is activated, and the vehicle eventually stops.

Actually, I could not get any error message, so I checked the message from /diagnostics, and I could observe the message below many times at the end of the simulation.

...
header:
  stamp:
    sec: 97
    nanosec: 300001449
  frame_id: ''
status:
- level: "\0"
  name: 'autonomous_emergency_braking: aeb_emergency_stop'
  message: '[AEB]: No Collision'
  hardware_id: autonomous_emergency_braking
  values: []
...

which could be related to this issue.

Here's more information of the situation:

• Starting/Goal pose (from launch.log)

initial pose - x: -74.345708, y: 17.612380, z: -0.063144
initial orientation - qx: -0.004035, qy: 0.003669, qz: 0.707917, qw: 0.706274
goal pose - x: -60.503540, y: -187.431732, z: 2.275307
goal orientation - qx: 0.000000, qy: 0.000000, qz: 0.952253, qw: 0.305310

• Map: Town03 [Town03]
• ros2bag file: [ros2bag]
• launch.log: [launch.log]

Expected behavior

I hope the vehicle to drive well to the goal point.

Actual behavior

But the vehicle could not drive to the goal point.

Steps to reproduce

1. Pull image from https://github.com/autowarefoundation/autoware/pkgs/container/autoware/321564631?tag=universe-devel-cuda-0.39.1-amd64 and run Autoware with Carla, using autoware_carla_interface.
2. Run ros2bag file above.

Versions

• OS: Ubuntu 22.04 (Docker), Ubuntu 20.04 (host)
• Autoware: 0.39.1
• Carla: 0.9.15
• autoware_carla_interface: link

Possible causes

No response

Additional context

No response

[maxime-clem]

Using the rqt_diagnostic_graph_monitor, I identified that the issue comes from the /autoware/localization/scan_matching_status diagnostic.
If I understand correctly, localization fails to find a good match between the lidar pointcloud and the pointcloud map.

One workaround is to remove the corresponding diagnostic from the configuration of the system_diagnostic_monitor (https://github.com/autowarefoundation/autoware_launch/blob/0.39.0/autoware_launch/config/system/system_diagnostic_monitor/localization.yaml#L11).