1_architecture_and_map.md

Architecture and Map

---

"BARK : Open Behavior Benchmarking in Multi-Agent Environments"

• [ 2020 ] [📝] [] [] [ 🎓 Technische Universität München ] [ 🚗 Fortiss, AID ]

• [ behavioural models, robustness, open-loop simulation, behavioural simulation, interactive human behaviors ]

Click to expand

The ObservedWorld model, reflects the world that is perceived by an agent. Occlusions and sensor noise can be introduced in it. The simultaneous movement makes simulator planning cycles entirely deterministic. Source.

Two evaluations. Left: Robustness of the planning model against the transition function. The scenario's density is increased by reducing the time headway IDM parameters of interacting vehicles. Inaccurate prediction model impacts the performance of an MCTS (2k, 4k, and 8k search iterations) and RL-based (SAC) planner. Right: an agent from the dataset is replaced with various agent behaviour models. Four different parameter sets for the IDM. Agent sets A0, A1, A2, A6 are not replaced with the IDM since this model cannot change lane. Maintaining a specific order is key for merging, but without fine-tuning model parameters, most behaviour models fail to coexist next to replayed agents. Source.

Authors: Bernhard, J., Esterle, K., Hart, P., & Kessler, T.

• BARK is an acronym for Behaviour BenchmARK and is open-source under the MIT license.

• Motivations:

  • 1- Focus on driving behaviour models for planning, prediction, and simulation.

    • "BARK offers a behavior model-centric simulation framework that enables fast-prototyping and the development of behavior models. Behavior models can easily be integrated — either using Python or C++. Various behavior models are available ranging from machine learning to conventional approaches."

  • 2- Benchmark interactive behaviours.

    • "To model interactivity, planners must employ some kind of prediction model of other agents."

• Why existing simulation frameworks are limiting?

  • "Most simulations rely on datasets and simplistic behavior models for traffic participants and do not cover the full variety of real-world, interactive human behaviors. However, existing frameworks for simulating and benchmarking behavior models rarely provide sophisticated behavior models for other agents."

  • CommonRoad: only pre-recorded data are used for the other agents, i.e. only enabling non-interactive behaviour planning.
  • CARLA: A CARLA-BARK interface is available.

    • "Being based on the Unreal Game Engine, problems like non-determinism and timing issues are introduced, that we consider undesirable when developing and comparing behavior models."

  • SUMO: Microscopic traffic simulators can model flow but neglect interactions with other vehicles and does not track the accurate motion of each agent.

• Concept of simultaneous movement.

  • Motivation: Make simulator planning cycles entirely deterministic. This enables the simulation and experiments to be reproducible.

  • "BARK models the world as a multi-agent system with agents performing simultaneous movements in the simulated world."

  • "At fixed, discrete world time-steps, each agent plans using an agent-specific behavior model in a cloned world – the agent’s observed world."

  • Hence the other agents can actively interact with the ego vehicle.

• Implemented behaviour models:

  • IDM + MOBIL.
  • RL (SAC).

    • "The reward r is calculated using Evaluators. These modules are available in our Machine Learning module. As it integrates the standard OpenAi Gym-interface, various popular RL libraries, such as TF-Agents can be easily integrated used with BARK."

  • MCTS. Single-agent or multi-agent.

    • [multi-agent] "Adapted to interactive driving by using information sets assuming simultaneous, multi-agent movements of traffic participants. They apply it to the context of cooperative planning, meaning that they introduce a cooperative cost function, which minimizes the costs for all agents."

  • Dataset Tracking Model.
    • The agent model tracks recorded trajectories as close as possible.

• Two evaluations (benchmark) of the behavioural models.

  • "Prediction (a discriminative task) deals with what will happen, whereas simulation (often a generative task) deals with what could happen. Put another way, prediction is a tool for forecasting the development of a given situation, whereas simulation is a tool for exploring a wide range of potential situations, often with the goal of probing the robot’s planning and control stack for weaknesses that can be addressed by system developers." (Brown, Driggs-Campbell, & Kochenderfer, 2020).

  • 1- Behaviour prediction:
    • What is the effect of an inaccurate prediction model on the performance of an MCTS and RL-based planner?
    • MCTS requires an explicit generative model for each transition. This prediction model used internally is evaluated here.

    • [Robustness also tested for RL] "RL can be considered as an offline planning algorithm – not relying on a prediction model but requiring a training environment to learn an optimal policy beforehand. The inaccuracy of prediction relates to the amount of behavior model inaccuracy between training and evaluation."

  • 2- Behaviour simulation.
    • How planners perform when replacing human drivers in recorded traffic scenarios?
    • Motivation: combine data-driven (recorded -> fixed trajectories) and interactive (longitudinally controlled) scenarios.

    • "A planner is inserted into recorded scenarios. Others keep the behavior as specified in the dataset, yielding an open-loop simulation."

    • The INTERACTION Dataset​ is used since it provides maps, which are essential for most on-road planning approaches.

• Results and future works.

  • [RL] "When the other agent’s behavior is different from that used in training, the collision rate rises more quickly."

  • "We conclude that current rule-based models (IDM, MOBIL) perform poorly in highly dense, interactive scenarios, as they do not model obstacle avoidance based on prediction or future interaction. MCTS can be used, but without an accurate model of the prediction, it also leads to crashes."

  • "A combination of classical and learning-based methods is computationally fast and achieves safe and comfortable motions."

  • The authors find imitation learning also promising.

---

"LGSVL Simulator: A High Fidelity Simulator for Autonomous Driving"

• [ 2020 ] [📝] [📝] [] [🎞️] [ 🚗 LG ]

• [ simulator ]

Click to expand

A bridge is selected based on the user AD stack’s runtime framework: Autoware.AI and Autoware.Auto, which run on ROS and ROS2, can connect through standard open source ROS and ROS2 bridges, while for Baidu’s Apollo platform, which uses a custom runtime framework called Cyber RT, a custom bridge is provided to the simulator. Source.

Authors: Boise, E., Uhm, G., Gerow, M., Mehta, S., Agafonov, E., Kim, T. H., … Kim, S.

• Motivations (Yet another simulator?):

  • "The LGSVL Simulator is a simulator that facilitates testing and development of autonomous driving software systems."

  • The main use case seems to be the integration to AD stacks: Autoware.AI, Autoware.Auto, Apollo 5.0, Apollo 3.0.
  • Compared to CARLA for instance, it seems more focused on development rather than research.
• The simulation engine serves three functions:
  • Environment simulation
  • Sensor simulation
  • Vehicle dynamics and control simulation.
• Miscellaneous:
  • LGSVL = LG Silicon Valley Lab.
  • Based on Unity engine.
  • A openAI-gym environment is provided for reinforcement learning: gym-lgsvl.
    • Default action space: steering and braking/throttle.
    • Default observation space: single camera image from the front camera. Can be enriched.
  • For perception training, kitti_parser.py enables to generate labelled data in KITTI format.
  • A custom License is defined.

    • "You may not sell or otherwise transfer or make available the Licensed Material, any copies of the Licensed Material, or any information derived from the Licensed Material in any form to any third parties for commercial purposes."

    • It makes it hard to compare to other simulators and AD software: for instance Carla, AirSim and DeepDrive are all under MIT License while code for Autoware and Apollo is protected by the Apache 2 License.

---

"Overview of Tools Supporting Planning for Automated Driving"

• [ 2020 ] [📝] [ 🚗 virtual vehicle research ]

• [ development tools ]

Click to expand

The authors group tools that support planning in sections: maps, communication, traffic rules, middleware, simulators and benchmarks. Source.

About simulators and dataset. And how to couple between tools, either with co-simulation software or open interfaces. Source.

About maps. ''The planning tasks with different targets entail map models with different level of details. HD map provides the most sufficient information and can be generally categorized into three layers: road model, lane model and localization model''. Source.

Authors: Tong, K., Ajanovic, Z., & Stettinger, G.

• Motivations:

  • 1- Help researchers to make full use of open-source resources and reduce effort of setting up a software platform that suites their needs.

    • [example] "It is a good option to choose open-source Autoware as software stack along with ROS middleware, as Autoware can be further transferred to a real vehicle. During the development, he or she can use Carla as a simulator, to get its benefits of graphic rendering and sensor simulation. To make the simulation more realistic, he or she might adopt commercial software CarMaker for sophisticated vehicle dynamics and open-source SUMO for large-scale traffic flow simulation. OpenDRIVE map can be used as a source and converted into the map format of Autoware, Carla and SUMO. Finally, CommonRoad can be used to evaluate the developed algorithm and benchmark it against other approaches."

  • 2- Avoid reinventing the wheel.
    • Algorithms are available/adapted from robotics.
    • Simulators are available/adapted from gaming.

• Mentioned software libraries for motion planning:

  • ROS (from robotics):
    • Open Motion Planning Library (OMPL)
    • MoveIt
    • navigation package
    • teb local planner.
  • Python: PythonRobotics
  • CPP: CppRobotics

• How to express traffic rules in a form understandable by an algorithm?

  • 1- Traffic rules can be formalized in higher order logic (e.g. using the Isabelle theorem prover) to check the compliance of traffic rules unambiguously and formally for trajectory validation.
  • 2- Another approach is to represent traffic rules geometrically as obstacles in a configuration space of motion planning problem.

  • "In some occasions, it is necessary to violate some rules during driving for achieving higher goals (i.e. avoiding collision) [... e.g. with] a rule book with hierarchical arrangement of different rules."

• About data visualization?

  • RViz is a popular tool in ROS for visualizing data flow, as I also realized at IV19.
  • Apart from that, it seems each team is having its own specific visualization tool, sometimes released, as AVS from UBER and GM Cruise.

• What is missing for the research community?

  • Evaluation tools for quantitative comparison.
  • Evaluation tools incorporating human judgment, not only from the vehicle occupants but also from other road users.
  • A standard format for motion datasets.

---

"Decision-making for automated vehicles using a hierarchical behavior-based arbitration scheme"

• [ 2020 ] [📝] [ 🎓 FZI, KIT ]

• [ hierarchical behavioural planning, cost-based arbitration, behaviour components ]

Click to expand

Both urban and highway behaviour options are combined using a cost-based arbitrator. Together with Parking and AvoidCollisionInLastResort, these four arbitrators and the SafeStop fallback are composed together to the top-most priority-based AutomatedDriving arbitrator. Source.

Top-right: two possible options. The arbitrator generally prefers the follow lane behaviour as long as it matches the route. Here, a lane change is necessary and selected by the cost-based arbitration: ChangeLaneRight has lower cost than FollowEgoLane, mainly due to the routing term in the cost expression. Bottom: the resulting behaviour selection over time. Source.

Authors: Orzechowski, P. F., Burger, C., & Lauer, M.

• Motivation:

  • Propose an alternative to FSMs (finite state machines) and behaviour-based systems (e.g. voting systems) in hierarchical architectures.
  • In particular, FSMs can suffer from:
    • poor interpretability: why is one behaviour executed?
    • maintainability: effort to refine existing behaviour.
    • scalability: effort to achieve a high number of behaviours and to combine a large variety of scenarios.
    • options selection: "multiple behaviour options are applicable but have no clear and consistent priority against each other."

      • "How and when should an automated vehicle switch from a regular ACC controller to a lane change, cooperative zip merge or parking planner?"

    • multiple planners: Each behaviour component can compute its manoeuvre command with any preferred state-of-the-art method.

      • "How can we support POMDPs, hybrid A* and any other planning method in our behaviour generation?".

• Main idea:

  • cost-based arbitration between so-called "behaviour components".
  • The modularity of these components brings several advantages:
    • Various scenarios can be handled within a single framework: four-way intersections, T-junctions, roundabout, multilane bypass roads, parking, etc.
    • Hierarchically combining behaviours, complex behaviour emerges from simple components.
    • Good efficiency: the atomic structure allows to evaluate behaviour options in parallel.

• About arbitration:

  • "An arbitrator contains a list of behavior options to choose from. A specific selection logic determines which option is chosen based on abstract information, e.g., expected utility or priority."

  • [about cost] "The cost-based arbitrator selects the behavior option with the lowest expected cost."

  • Each behaviour option is evaluated based on its expected average travel velocity, incorporating routing costs and penalizing lane changes.
    • The resulting behaviour can thus be well explained:

    • "The selection logic of arbitrators is comprehensive."

  • About hierarchy:

    • "To generate even more complex behaviours, an arbitrator can also be a behaviour option of a hierarchically higher arbitrator."

• About behaviour components.

  • There are the smallest building blocks, representing basic tactical driving manoeuvres.
  • Example of atomic behaviour components for simple tasks in urban scenarios:
    • FollowLead
    • CrossIntersection
    • ChangeLane
  • They can be specialized:
    • Dense scenarios behaviours: ApproachGap, IndicateIntention and MergeIntoGap to refine ChangeLane (multi-phase behaviour).
      • Note: an alternative could be to use one single integrated interaction-aware behaviour such as POMDP.
    • Highway behaviours (structured but high speed): MergeOntoHighway, FollowHighwayLane, ChangeHighwayLane, ExitFromHighway.
    • Parking behaviours: LeaveGarage, ParkNearGoal.
    • Fail-safe emergency behaviours: EmergenyStop, EvadeObject, SafeStop.
  • For a behaviour to be selected, it should be applicable. Hence a behaviour is defined together with:
    • invocation condition: when does it become applicable.

      • "[example:] The invocation condition of CrossIntersection is true as long as the current ego lane intersects other lanes within its planning horizon."

    • commitment condition: when does it stay applicable.
  • This reminds me the concept of macro actions, sometimes defined by a tuple <applicability condition, termination condition, primitive policy>.
  • It also makes me think of MODIA framework and other scene-decomposition approaches.

• A mid-to-mid approach:

  • "[input] The input is an abstract environment model that contains a fused, tracked and filtered representation of the world."

  • [output] The selected high-level decision is passed to a trajectory planner or controller.
  • What does the "decision" look like?
    • One-size-fits-all is not an option.
    • It is distinguished between maneuvers in a structured or unstructured environment:
    • 1- unstructured: a trajectory, directly passed to a trajectory planner.
    • 2- structured: a corridor-based driving command, i.e. a tuple <maneuver corridor, reference line, predicted objects, maneuver variant>. It requires both a trajectory planner and a controller.

• One distinction:

  • 1- top-down knowledge-based systems.

    • "The action selection in a centralized, in a top-down manner using a knowledge database."

    • "The engineer designing the action selection module (in FSMs the state transitions) has to be aware of the conditions, effects and possible interactions of all behaviors at hand."

  • 2- bottom-up behaviour-based systems.

    • "Decouple actions into atomic simple behaviour components that should be aware of their conditions and effects."

    • E.g. voting systems.
  • Here the authors combine atomic behaviour components (bottom/down) with more complex behaviours using generic arbitrators (top/up).

---

"A Review of Motion Planning for Highway Autonomous Driving"

• [ 2019 ] [📝] [ 🎓 French Institute of Science and Technology for Transport ] [ 🚗 VEDECOM Institute ]

Click to expand

The review divides motion-planning into five parts. The decision-making part contains risk evaluation, criteria minimization, and constraint submission. In the last part, a low-level reactive planner deforms the generated motion from the high-level planner. Source.

The review offers two detailed tools for comparing methods for motion planning for highway scenarios. Criteria for the generated motion include: feasible, safe, optimal, usable, adaptive, efficient, progressive and interactive. The authors stressed the importance of spatiotemporal consideration and emphasize that highway motion-planning is highly structured. Source.

Contrary to solve-algorithms methods, set-algorithm methods require a complementary algorithm should be added to find the feasible motion. Depending on the importance of the generation (iv) and deformation (v) part, approaches are more or less reactive or predictive. Finally, based on their work on AI-based algorithms, the authors define four subfamilies to compare to human: logic, heuristic, approximate reasoning, and human-like. Source.

The review also offers overviews for possible space configurations, i.e. the choices for decomposition of the evolution space (sampling-based decomposition, connected cells decomposition and lattice representation) as well as path-finding algorithms (e.g. Dijkstra, A*, and RRT). attractive and repulsive forces, parametric and semi-parametric curves, numerical optimization and artificial intelligence are also developed. Source.

Authors: Claussmann, L., Revilloud, M., Gruyer, D., & Glaser, S.

---

"A Survey of Deep Learning Applications to Autonomous Vehicle Control"

• [ 2019 ] [📝] [ 🎓 University of Surrey ] [ 🚗 Jaguar Land Rover ]

Click to expand

Challenges for learning-based control methods. Source.

Authors: Kuutti, S., Bowden, R., Jin, Y., Barber, P., & Fallah, S.

• Three categories are examined:
  • lateral control alone.
  • longitudinal control alone.
  • longitudinal and lateral control combined.
• Two quotes:

  • "While lateral control is typically achieved through vision, the longitudinal control relies on measurements of relative velocity and distance to the preceding/following vehicles. This means that ranging sensors such as RADAR or LIDAR are more commonly used in longitudinal control systems.".

  • "While lateral control techniques favour supervised learning techniques trained on labelled datasets, longitudinal control techniques favour reinforcement learning methods which learn through interaction with the environment."

---

"Longitudinal Motion Planning for Autonomous Vehicles and Its Impact on Congestion: A Survey"

• [ 2019 ] [📝] [ 🎓 Georgia Institute of Technology ]

Click to expand

mMP refers to machine learning methods for longitudinal motion planning. Source.

Authors: Zhou, H., & Laval, J.

• This review has been completed at a school of "civil and environmental engineering".
  • It does not have any scientific contribution, but offers a quick overview about some current trends in decision-making.
  • The authors try to look at industrial applications (e.g. Waymo, Uber, Tesla), i.e. not just focussing on theoretical research. Since companies do no communicate explicitly about their approaches, most of their publications should be considered as research side-projects, rather than "actual state" of the industry.
• One focus of the review: the machine learning approaches for decision-making for longitudinal motion.
  • About the architecture and representation models. They mention the works of DeepDriving and (H. Xu, Gao, Yu, & Darrell, 2016).
    • Mediated perception approaches parse an entire scene to make a driving decision.
    • Direct perception approaches first extract affordance indicators (i.e. only the information that are important for driving in a particular situation) and then map them to actions.

      • "Only a small portion of detected objects are indeed related to the real driving reactions so that it would be meaningful to reduce the number of key perception indicators known as learning affordances".

    • Behavioural reflex approaches directly map an input image to a driving action by a regressor.
      • This end-to-end paradigm can be extended with auxiliary tasks such as learning semantic segmentation (this "side task" should further improves the model), leading to Privileged training.
  • About the learning methods:
    • BC, RL, IRL and GAIL are considered.
    • The authors argue that their memory and prediction abilities should make them stand out from the rule-based approaches.

    • "Both BC and IRL algorithms implicitly assume that the demonstrations are complete, meaning that the action for each demonstrated state is fully observable and available."

    • "We argue that adopting RL transforms the problem of learnt longitudinal motion planning from imitating human demonstrations to searching for a policy complying a hand-crafted reward rule [...] No studies have shown that a genuine reward function for human driving really exists."

• About congestion:

  • "The AV industry has been mostly focusing on the long tail problem caused by corner errors related to safety, while the impact of AVs on traffic efficiency is almost ignored."

  • It reminds me the finding of (Kellett, J., Barreto, R., Van Den Hengel, A. & Vogiatzis. N., 2019) in "How Might Autonomous Vehicles Impact the City? The Case of Commuting to Central Adelaide": driverless cars could lead to more traffic congestion.

---

"Design Space of Behaviour Planning for Autonomous Driving"

• [ 2019 ] [📝] [ 🎓 University of Waterloo ]

Click to expand

Some figures:

The focus is on the BP module, together with its predecessor (environment) and its successor (LP) in a modular architecture. Source.

Classification for Question 1 - environment representation. A combination is possible. In black, my notes giving examples. Source.

Classification for Question 2 - on the architecture. Source.

Classification for Question 3 - on the decision logic representation. Source.

Authors: Ilievski, M., Sedwards, S., Gaurav, A., Balakrishnan, A., Sarkar, A., Lee, J., Bouchard, F., De Iaco, R., & Czarnecki K.

The authors divide their review into three sections:

• Question 1: How to represent the environment? (relation with predecessor of BP)
  • Four representations are compared: raw data, feature-based, grid-based and latent representation.
• Question 2: How to communicate with other modules, especially the local planner (LP)? (relation with successor (LP) of BP)
  • A first sub-question is the relevance of separation BP / LP.
    • A complete separation (top-down) can lead to computational redundancy (both have a collision checker).
    • One idea, close to sampling techniques, could be to invert the traditional architecture for planning, i.e. generate multiple possible local paths (~LP) then selects the best manoeuvre according to a given cost function (~BP). But this exasperates the previous point.
  • A second sub-question concerns prediction: Should the BP module have its own dedicated prediction module?
    • First, three kind of prediction are listed, depending on what should be predicted (marked with ->):
      • Physics-based (-> trajectory).
      • Manoeuvre-based (-> low-level motion primitives).
      • Interaction-aware (-> intent).
    • Then, the authors distinguish between explicitly-defined and implicitly-defined prediction models:
      • Explicitly-defined can be:
        • Integrated with the motion planning process (called Internal prediction models) such as belief-based decision making (e.g. POMDP). Ideal for planning under uncertainty.
        • Decoupled from the planning process (called External prediction models). There is a clear interface between prediction and planning, which aids modularity.
      • Implicitly-defined, such as RL techniques.
• Question 3: How to make BP decisions? (BP itself)
  • A first distinction in representation of decision logic is made depending based on non-learnt / learnt:
    • Using a set of explicitly programmed production rules can be divided into:
      • Imperative approaches, e.g. state machines.
      • Declarative approaches often based on some probabilistic system.
        • The decision-tree structure and the (PO)MDP formulation makes it more robust to uncertainty.
        • Examples include MCTS and online POMDP solvers.
    • Logic representation can also rely on mathematical models with parameters learned a priori.
      • A distinction is made depending on "where does the training data come from and when is it created?".
      • In other words, one could think of supervised learning (learning from example) versus reinforcement learning (learning from interaction).
      • The combination of both seems beneficial:
        • An initial behaviour is obtained through imitation learning (learning from example). Also possible with IRL.
        • But improvements are made through interaction with a simulated environment (learning from interaction).
          • By the way, the learning from interaction techniques raise the question of the origin of the experience (e.g. realism of the simulator) and its sampling efficiency.
      • Another promising direction is hierarchical RL where the MDP is divided into sub-problems (the lower for LP and the higher for BP)
        • The lowest level implementation of the hierarchy approximates a solution to the control and LP problem ...
        • ... while the higher level selects a manoeuvre to be executed by the lower level implementations.
  • As mentioned in my the section on Scenarios and Datasets, the authors mention the lack of benchmark to compare and evaluate the performance of BP technologies.

One quote about the representation of decision logic:

• As identified in my notes about IV19, the combination of learnt and non-learnt approaches looks the most promising.

• "Without learning, traditional robotic solutions cannot adequately handle complex, dynamic human environments, but ensuring the safety of learned systems remains a significant challenge."

• "Hence, we speculate that future high performance and safe behaviour planning solutions will be hybrid and heterogeneous, incorporating modules consisting of learned systems supervised by programmed logic."

---

"A Behavioral Planning Framework for Autonomous Driving"

• [ 2014 ] [📝] [ 🎓 Carnegie Mellon University ] [ 🚗 General Motor ]

• [ behavioural planning, sampling-based planner, decision under uncertainty, TORCS ]

Click to expand

Some figures:

Comparison and fusion of the hierarchical and parallel architectures. Source.

The PCB algorithm implemented in the BP module. Source.

Related work by (Xu, Pan, Wei, & Dolan, 2014) - Grey ellipses indicate the magnitude of the uncertainty of state. Source.

Authors: Wei, J., Snider, J. M., & Dolan, J. M.

Note: I find very valuable to get insights from the CMU (Carnegie Mellon University) Team, based on their experience of the DARPA Urban Challenges.

• Related works:
  • A prediction- and cost function-based algorithm for robust autonomous freeway driving. 2010 by (Wei, Dolan, & Litkouhi, 2010).
    • They introduced the "Prediction- and Cost-function Based (PCB) algorithm" used.
    • The idea is to generate-forward_simulate-evaluate a set of manoeuvres.
    • The planner can therefore take surrounding vehicles’ reactions into account in the cost function when it searches for the best strategy.
    • At the time, the authors rejected the option of a POMDP formulation (computing the control policy over the space of the belief state, which is a probability distribution over all the possible states) deemed as computationally expensive. Improvements in hardware and algorithmic have been made since 2014.
  • Motion planning under uncertainty for on-road autonomous driving. 2014 by (Xu, Pan, Wei, & Dolan, 2014).
    • An extension of the framework to consider uncertainty (both for environment and the others participants) in the decision-making.
    • The prediction module is using a Kalman Filter (assuming constant velocity).
    • For each candidate trajectory, the uncertainty can be estimated using a Linear-Quadratic Gaussian (LQG) framework (based on the noise characteristics of the localization and control).
    • Their Gaussian-based method gives some probabilistic safety guaranty (e.g. likelihood 2% of collision to occur).
• Proposed architecture for decision-making:
  • First ingredient: Hierarchical architecture.
    • The hierarchy mission -> manoeuvre -> motion 3M concept makes it very modular but can raise limitations:

    • "the higher-level decision making module usually does not have enough detailed information, and the lower-level layer does not have authority to re-evaluate the decision."

  • Second ingredient: Parallel architecture.
    • This is inspired from ADAS engineering.
    • The control modules (ACC, Merge Assist, Lane Centreing) are relatively independent and work in parallel.
    • In some complicated cases needing cooperation, this framework may not perform well.
      • This probably shows that just extending the common ADAS architectures cannot be enough to reach the level-5 of autonomy.
  • Idea of the proposed framework: combine the strengths of the hierarchical and parallel architectures.
    • This relieves the path planner and the control module (the search space is reduced).
    • Hence the computational cost shrinks (by over 90% compared to a sample-based planner in the spatio-temporal space).
• One module worth mentioning: Traffic-free Reference Planner.
  • Its input: lane-level sub-missions from the Mission Planning.
  • Its output: kinematically and dynamically feasible paths and a speed profile for the Behavioural Planner (BP).
    • It assumes there is no traffic on the road, i.e. ignores dynamic obstacles.
    • It also applies traffic rules such as speed limits.
  • This guides the BP layer which considers both static and dynamic obstacles to generate so-called "controller directives" such as:
    • The lateral driving bias.
    • The desired leading vehicle to follow.
    • The aggressiveness of distance keeping.
    • The maximum speed.