The difficulty in handling complex scenarios due to the hierarchical architecture of Planning and the modularization of functionalities

[yukkysaito]

Background

• The difficulty in handling complex scenarios due to the hierarchical architecture of Planning and the modularization of functionalities #5033

Related issue

• Enable generator-selector planning framework #6292

The issues with the current planner

The current Autoware planning architecture employs a parallel architecture that can switch according to the scenario, using a hierarchical architecture primarily for lane driving scenarios. Currently, most of the planning functions operate within this hierarchical architecture to handle lane driving scenarios.
One of the shortcomings of this hierarchical architecture is the discrepancy in decision-making that arises from separating behavior planning and motion planning. This issue was recognized as a challenge of the architecture since its proposal (following image).

https://github.com/tier4/AutowareArchitectureProposal.proj/blob/main/docs/design/software_architecture/Planning/DesignRationale.md

In practice, we have faced the shortcomings of the hierarchical architecture, such as implementing speed planning within behavior planning to improve decision-making accuracy. Additionally, based on the concept of micro-autonomy, we have modularized the Planning function into scene modules to enable the on/off switching and expansion of each function. However, in complex scenarios, the cooperation between scene modules becomes necessary, making it difficult for modules to operate independently.
As a result, the current Autoware architecture faces increased functional demands in complex scenarios, leading to higher coupling between scene modules and between behavior planning and motion planning. This makes it challenging to switch or expand each function, resulting in more complex code, increased bugs, and higher maintenance costs.

Proposal

To solve this problem, we propose building a higher-level concept, the Sampling-based Planner Framework, and treating the existing hierarchical architecture as part of the Sampler.

This will enhance the flexibility in developing the Sampler. In the Sampler, various implementations such as machine learning-based planners (e.g., End-to-End AI using World Models and Imitation Learning), optimization-based planners, and rule-based planners can be freely implemented and run simultaneously. Consequently, external planning can operate as part of the Sampler, and the introduction of machine learning-based Samplers becomes easier.
Introducing a machine learning-based Sampler, in particular, is expected to handle edge cases that rule-based approaches cannot address, thereby improving robustness.

Moreover, this approach aligns well with remote assistance, allowing for sampling near the area where remote instructions are given and potentially enhancing the evaluation function of the Selector near the remote instruction area in the future.
https://waymo.com/blog/2024/05/fleet-response/

TIER IV plans to prototype this architecture to verify its effectiveness, and if it works well, we intend to propose it as the new planning architecture.

References

DriveIRL: https://arxiv.org/pdf/2206.03004.pdf
Frenetix Motion Planner: https://arxiv.org/abs/2402.01443

[yukkysaito]

I would like to share the progress on this proposal. First, we have started by creating a prototype of the ranking algorithm. The role of the ranking is to select the best trajectory from those generated by the generator. By the time the trajectories reach the ranking stage, they are already guaranteed to comply with traffic rules, safety, and followability, so the process is similar to selecting a driving policy. For example, when deciding whether to choose a candidate trajectory that aggressively changes lanes or to continue driving straight, this decision is made by the ranking.

We are testing two types of ranking algorithms: one based on inverse reinforcement learning and another based on a rule-based approach. The inverse reinforcement learning-based approach has not yet yielded results that are ready to be shared. On the other hand, for the rule-based approach, we are implementing the ranking with the hypothesis that it can function reasonably well with the following five criteria.

• Safety: Is the risk of collision with other vehicles low?
• Comfortability: Does the vehicle provide a comfortable ride by avoiding sudden accelerations or decelerations?
• Efficiency: Does the vehicle maintain a high level of propulsion and speed?
• Achievability: How closely does the vehicle adhere to the navigation instructions?
• Consistency: Is there temporal consistency in the vehicle's decision-making?

Currently, we have collected imitation data from manual driving and are able to visualize Safety, Comfortability, and Efficiency.

Screencast from 2024年08月21日 23時24分51秒.webm

Moving forward, we plan to design a scoring function based on these criteria and verify whether the appropriate trajectory is selected.

[yukkysaito]

We are also prototyping the following Generators. However, it will take some time before we can report any results:

• An end-to-end system like GAIA-1 that includes Sensing, Perception, and Planning using a world model
• State Transformer
• PLUTO
• Diffusion-ES

[armaganarsln]

I am not sure if this will be the right place to discuss this but I believe planning cannot perform well without having a perception. I mean could a human drive without good eyesight? Even the best planning algorithm will suffer with the ever-changing bounding boxes in Autoware either blinking or changing its orientation or its position. Therefore I think the algorithms should be tested with ground truth perception if available from simulation not dataset which works with Autoware perception. Of course in the end perception should be fixed to achieve good results but with Autoware's current perception, the results of the tests might not be trustworthy since we won't know the reasons for failures which might really be depending on the perception outputs.

[armaganarsln]

@yukkysaito san, Is it possible for someone to update us and present the work that has been done so far at Planning & Control WG?

I have checked the papers you have shared and Frenetix looks like the old lattice planner that we had which I lost 2 years from my life I hope they are not similar.

Also is this testing open source? Can others also join the testing efforts?

I would like to learn more and join the efforts on testing in simulation. Let me know if that's a possibility and when it could be done.

[yukkysaito]

Apologies for the long silence on our progress. The framework and E2E development are finally starting to take shape. You can find the most up-to-date information on our wiki:

https://github.com/tier4/new_planning_framework/wiki

We plan to merge our work into Autoware in 5 main stages:

• 1. Merge message types into Autoware
• 2. Merge the Generator (Diffusion Planner)
  • Download model files
  • Merge Diffusion Planner into Autoware universe
• 3. Merge the Selector
  • Change planning output topic name from /planning/scenario_planning/trajectory to /planning/trajectory
  • Merge Selector into Autoware universe
• 4. Add Autoware launch support for the Generator (Diffusion Planner) + Selector
• 5. Migrate current planning component to generator framework.

Thank you for your continued support.

[yukkysaito]

@xmfcx @mitsudome-r I created the PR for P1. Could you review it?

[yukkysaito]

Phase 2 procedure is as follows

• On 8/4 (one week prior), submit a PR that replaces /planning/scenario_planning/trajectory with /planning/trajectory and complete the review so it can be merged on 8/11
• On 8/11, change the existing planning output to /planning/trajectory and add a relay node that republishes from /planning/trajectory to /planning/scenario_planning/trajectory

[xmfcx]

I will create an issue to track this within 1 hour, then I will approve and merge the first PR. The timeline and the progress could be tracked in this new issue and the PRs can be linked there, is that OK?

[yukkysaito]

I will create an issue to track this within 1 hour, then I will approve and merge the first PR. The timeline and the progress could be tracked in this new issue and the PRs can be linked there, is that OK?

@xmfcx Perfect 👍

[xmfcx]

@yukkysaito shared here, let's discuss in detail:

• Enable generator-selector planning framework #6292