Autoware Architecture WG Meeting (localization) 2022/05/10

[mitsudome-r]

Participants

Chaired by Ryohsuke

Goal of this WG

https://docs.google.com/presentation/d/1AhuCcScktgBwJreAjDspyf2OcKTNFbK-fFI1QT9NRLg/edit?usp=sharing

Discussion Topics:

Review Localization Interface Design

• Reference: https://github.com/orgs/autowarefoundation/discussions/1
• Current output of localization:
  • tf (map->base_link)
  • nav_msgs::Odometry http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/Odometry.html
  • diagnostic_msgs/DiagnosticArray
    new proposal feat(localization-messages): add autoware_localization_msgs autoware_msgs#16

Discussion

• Do we need covariance values for the outputs?
  • Currently, no nodes in planning or control use covariance to produce trajectory or control values in probabilistic algorithm
  • They are 6x6 matrix so it shouldn't be stressing bandwidth
  • We will still be providing diagnostic information to provide reliability information
• Should we keep pose, velocity, and acceleration as a single message or as a separate message?
  • Single message should be okay. The message size should be small enough, and we would have overhead of a header field.
• Can pose estimator be a single node or composition of multiple nodes?
  • Yes

Next Week Topic: Perception (Detection + Tracking), Prediction.

Action Items

• @mitsudome-r to create a wiki page for this WG.
• @mitsudome-r to create pull for localization design document

[TakaHoribe]

@mitsudome-r @xmfcx Thank you for today's mtg. Let me say one thing.

As in @Sharrrrk 's comment, "why does autoware not use the velocity information directly from CAN BUS?" is an essential question for the autoware architecture.
I totally agree with @mitsudome-r 's answer "to support multiple vehicles without architecture changes as a platform...", but many users may will think the same question.
So, I suggest having the example explained by @mitsudome-r in the architecture design document. It seems there already is an abstract description like "to support multiple sensors...", but a concrete example will help users better understand the architecture.

This would be like:

"One vehicle has a very accurate speed sensor, but one vehicle may not. In the former vehicle, we can use the speed information directly from CAN BUS, but in the latter vehicle, we need to create better speed information by combining other sensors like GNSS, IIMU, etc. To support the multiple sensor/vehicle configurations without architecture changes, all sensor information is sent to the localization module. If the CAN BUS speed sensor accuracy is very high, localization module will output almost same speed value as the CAN BUS by tuning the sensor's covariance information."

[Sharrrrk]

@TakaHoribe thanks for your comment, it is indeed the case for the design robustness to support different types of mobiles. I guess it's just the trade-off to be made. At current stage, Autoware as a reference platform do need to focus on the usability for various users. So I agree with the fusion architecture design.