Method and system for implementing double-layer state machine, electronic equipment and readable medium

Abstract

The invention discloses an implementation method and system of a double-layer state machine, electronic equipment and a readable medium, and belongs to the field of automobiles, and the implementation method of the double-layer state machine is characterized in that based on recognized scene changes, an outer layer state machine controls scene switching; based on the scene state of the outer-layer state machine, the inner-layer state machine controls switching of the vehicle state through the obtained environment information and the vehicle information, complex driving behaviors are decomposed into multiple levels through a double-layer state machine model, the complexity of the state machine is reduced, and maintenance and expansion are facilitated.

Description

Technical Field

[0001] This invention relates to the field of automotive technology, and in particular to a method, system, electronic device, and computer-readable medium for implementing a two-level state machine. Background Technology

[0002] In the field of autonomous driving technology, the driving planning module is a crucial component for ensuring the safe and efficient operation of vehicles. As autonomous driving technology continues to evolve, driving planning systems need to cope with increasingly complex traffic scenarios, such as urban roads, highways, intersections, and construction zones. These scenarios place higher demands on the real-time performance, accuracy, and flexibility of driving planning systems.

[0003] Traditional driving planning methods typically employ a single-state machine model, controlling vehicle behavior by defining a series of states and state transition conditions. However, with increasing scenario complexity, the single-state machine model faces numerous challenges. On one hand, the explosive growth in the number of states leads to a large and complex state machine structure, making it difficult to maintain and extend. On the other hand, the transition conditions between states become complex and difficult to manage, easily leading to logical errors and state conflicts, affecting the accuracy and reliability of driving planning.

[0004] Furthermore, the single-state machine model lacks flexibility and scalability when dealing with complex scenarios. When new traffic scenarios emerge or traffic rules change, large-scale modifications and refactoring of the state machine are required, which not only increases development costs and time but may also introduce new errors. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a method and system for implementing a two-level state machine.

[0006] In a first aspect, the present invention provides a method for implementing a two-level state machine, comprising:

[0007] Based on the identified scene changes, the outer state machine controls the scene switching;

[0008] Based on the scene state of the outer state machine, the inner state machine controls the switching of vehicle state by acquiring environmental and vehicle information.

[0009] In some embodiments, both the inner state machine and the outer state machine use a preset finite state machine template class for state switching and event distribution;

[0010] Furthermore, the state transition function Transit is implemented based on the template class Fsm. <s>Implement the event dispatch function Dispatch based on the template class Fsm. <e>.

[0011] In some embodiments, the outer state machine defines different stages according to different traffic scenarios, and each stage represents a macroscopic driving task or scenario type.

[0012] In some embodiments, the macroscopic driving task or scenario type includes:

[0013] LaneKeepStage: Straight-line driving scenario;

[0014] OvertakeStage: Overtaking scenario;

[0015] JunctionStage: Intersection Scene.

[0016] In some embodiments, a base class Stage is defined, making Stage a self-referential state machine;

[0017] Each Stage class contains specific logic for that scenario, used to determine whether to switch to another Stage.

[0018] In some embodiments, the inner state machine includes multiple Stages, each Stage defining a corresponding Scenario base class;

[0019] Each Scenario base class handles specific behavioral logic and responds to events.

[0020] In some embodiments, the Scenario base class includes:

[0021] LaneKeepScenario is the base class of Scenario in LaneKeepStage; and LaneKeepDefaultScenario represents the default, LaneKeepPreLaneChangeScenario represents pre-lane change, and LaneKeepThrottleOverrideScenario represents throttle control.

[0022] JunctionScenario is the base class for Scenario within JunctionStage; and

[0023] JunctionDefaultScenario represents the default setting, while JunctionOvertakeScenario represents overtaking.

[0024] Secondly, the present invention provides a system for implementing a two-level state machine, comprising:

[0025] Outer state machine: Controls scene switching based on recognized scene changes;

[0026] Inner state machine: Based on the scene state of the outer state machine, the vehicle state is switched by acquiring environmental and vehicle information.

[0027] Thirdly, the present invention also provides an electronic device, comprising:

[0028] One or more processors;

[0029] Memory, used to store one or more programs;

[0030] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods.

[0031] Fourthly, the present invention also provides a computer-readable medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps in any of the methods described.

[0032] This invention provides a method for implementing a two-layer state machine, which defines a general finite state machine template class; implements an outer state machine based on the general finite state machine template class; implements an inner state machine based on the general finite state machine template class; switches the outer state machine based on environmental information, and within each outer state machine, the inner state machine switches states based on specific events. This invention, through a two-layer state machine model, decomposes complex driving behavior into multiple layers, reducing the complexity of the state machine and facilitating maintenance and expansion. When new traffic scenarios or changes in traffic rules occur, only the states and transition conditions need to be added or modified in the corresponding Stage or Scenario, without requiring large-scale modifications to the entire state machine. The inner state machine (Scenario) can be finely adjusted according to specific driving behaviors and traffic rules, improving the system's adaptability to complex dynamic traffic scenarios. Through layered management and flexible switching, the probability of state conflicts and logical errors is reduced, improving the accuracy and reliability of driving planning, while ensuring the system's usability and maintainability. Attached Figure Description

[0033] Figure 1 This is a schematic diagram illustrating the steps of an embodiment of the two-layer state machine implementation method of the present invention;

[0034] Figure 2 This is a schematic diagram of an embodiment of the state switching of the present invention;

[0035] Figure 3 This is a schematic diagram of an embodiment of the dual-layer state cutting mechanism of the present invention;

[0036] Figure 4 This is a schematic diagram illustrating the steps of an embodiment of the two-layer state machine implementation system of the present invention;

[0037] Figure 5 This is a schematic diagram of the structure of an embodiment of the electronic device of the present invention. Detailed Implementation

[0038] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0039] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0040] As used herein, the term "and / or" includes any and all combinations of one or more related enumerated entries.

[0041] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms "a" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0042] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0043] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0044] In related technologies, the existing single-state machine model is complex in structure, difficult to maintain and extend, and the hierarchical finite state machine model is insufficient in terms of state transition logic and complexity.

[0045] To address at least one of the technical problems existing in the aforementioned related technologies, this invention provides a method for implementing a two-level state machine. The technical terms involved in this invention are as follows:

[0046] Terms / Abbreviations noun illustrate FSM Finite-State Machine Finite state machine HFSM Hierarchical Finite-State Machine Hierarchical Finite State Machine CRTP Curiously Recurring Template Pattern Curiosity Recursive Template Pattern

[0047] Figure 1 A flowchart illustrating the steps of implementing a two-level state machine according to an embodiment of the present invention includes the following steps:

[0048] Step S10: Based on the identified scene changes, the outer state machine controls the scene switching.

[0049] In this invention, two state machines need to be created in advance: an inner state machine and an outer state machine. The outer state machine is responsible for the overall management and scheduling of the scene, while the inner state machine is responsible for the state switching and driver behavior control in specific scenes.

[0050] In the specific creation method: first create a template class Fsm, which supports different state machine types through template parameters.

[0051] Provide the state transition function Transit <s>Used to switch to state S. It first calls the Exit method of the current state, then switches to the new state and calls the Entry method of the new state.

[0052] Provides the event dispatch function Dispatch <e>: Used to handle event E and call the React method for the current state.

[0053] Manage state instances using the singleton pattern: via _state_instance <s>Templates ensure that there is only one instance of each state type.

[0054] This FSM template is the base class for Stage and Scenario state machines, providing core state management functionality.

[0055] The specific implementation method is as follows:

[0056] FSM Design: Defines a generic Finite State Machine (FSM) template class designed to manage state transitions and event dispatch. It provides generalization support for different state machines through template parameters, allowing users to define their own states and events and implement the state machine logic through this template class.

[0057] FSM implements state switching and event dispatching through class template functions.

[0058] / / Fsm state transition function template

[0059] template<typename S>

[0060] void Fsm::Transit() {

[0061] current_state_ptr_->Exit();

[0062] current_state_ptr_ = &_state_instance <s>::value;

[0063] current_state_ptr_->Entry();

[0064] }

[0065] / / FSM event dispatch function template

[0066] template<typename E>

[0067] static void Fsm::Dispatch(E const &event) {

[0068] current_state_ptr_->React(event);

[0069] }

[0070] The specific implementation of the state instance template is as follows. Through template instantiation, different types S will generate different _state_instances. <s>Each instance has its own independent static variable, value.

[0071] / / State instance template (singleton pattern)

[0072] template<typename S>

[0073] struct _state_instance {

[0074] / / Defines a type alias value_type, which is equivalent to the template parameter type S.

[0075] using value_type = S;

[0076] / / Defines another type alias, type, which represents the current template instance itself (i.e., _state_instance). <s>)。

[0077] using type = _state_instance <s>;

[0078] / / Declare a static data member value

[0079] static S value;

[0080] };

[0081] This step is understandably fundamental to the entire state machine model, providing a unified state management framework for Stages and Scenarios. All state machines inherit from the FSM template, thereby gaining state transition and event handling capabilities.

[0082] For the outer state machine:

[0083] Define a base class Stage that inherits from Fsm <stage>(Using CRTP pattern) makes Stage a self-referential state machine.

[0084] Create multiple Stage-derived classes, each representing a macro-level driving scenario, including:

[0085] LaneKeepStage: Straight-line scenario.

[0086] OvertakeStage: Overtaking scenario.

[0087] JunctionStage: Intersection Scene.

[0088] Other scenarios (such as changing lanes, detouring, etc.).

[0089] Each Stage class contains specific logic for that scenario (such as conditional judgment methods) to determine whether to switch to another Stage.

[0090] Specifically, the outer state machine is implemented using the general finite state machine template class as follows:

[0091] Stage Design: A subclass state machine created using the Curious Recurring Template Pattern (CRTP). Different Stages are defined based on different traffic scenarios, such as going straight, changing lanes, intersections, and detours. Each Stage represents a macroscopic driving task or scenario type, such as "Lane KeepStage" or "Lane Change Stage".

[0092] The Stage is implemented as follows:

[0093] / / Base class

[0094] class Stage : public Fsm <stage>{}

[0095] / / ↓

[0096] / / Derived class

[0097] class LaneKeepStage : public Stage{}

[0098] As can be understood, a Stage, acting as an outer state machine, is responsible for the overall management and scheduling of the scene. It gains state transition capabilities by inheriting the Fsm template and implements polymorphism through CRTP, allowing each Stage to define its own state and behavior. Switching between Stages is based on high-level conditions (such as environmental information).

[0099] For the inner state machine:

[0100] Each Stage of the inner state machine defines a corresponding Scenario base class, which inherits from Fsm. <scenario>(Using CRTP mode). For example:

[0101] LaneKeepScenario is the base class of Scenario within LaneKeepStage.

[0102] JunctionScenario is the base class of Scenario within JunctionStage.

[0103] Create multiple Scenario-derived classes, each representing a specific behavioral state:

[0104] In LaneKeepStage: LaneKeepDefaultScenario (default), LaneKeepPreLaneChangeScenario (pre-lane change), LaneKeepThrottleOverrideScenario (throttle control), etc.

[0105] In the FunctionStage: FunctionDefaultScenario (default), FunctionOvertakeScenario (overtaking), etc.

[0106] Each Scenario class handles specific behavioral logic and responds to events (such as driver input).

[0107] Specifically, the Scenario design adopts the following approach:

[0108] The subclass state machine is created using the Curious Recurring Template Pattern (CRTP). Within each Stage, multiple Scenarios are defined based on specific driving behaviors and traffic rules. For example, in the "Lane Keep Stage", there are "Lane Keep:Default", "Lane Keep:Pre Lane Change", and "Lane Keep:Overtake".

[0109] The implementation method of Scenario is as follows:

[0110] / / Base class

[0111] class LaneKeepScenario : public Fsm <lanekeepscenario>{}

[0112] / / ↓

[0113] / / Derived class

[0114] class LaneKeepPreLaneChangeScenario : public LaneKeepScenario {}

[0115] class LaneKeepThrottleOverrideScenario : public LaneKeepScenario {}

[0116] class LaneKeepDefaultScenario : public LaneKeepScenario {}

[0117] It can be understood that the Scenario, as an inner state machine, performs fine-grained state management within the Stage. It gains state transition capabilities by inheriting the Fsm template and implements polymorphism through CRTP. The switching of the Scenario is triggered by the Stage or based on specific events (such as throttle control), thereby achieving fine-grained control of driver behavior.

[0118] S20. Based on the scene state of the outer state machine, the inner state machine controls the switching of vehicle state by acquiring environmental information and vehicle information.

[0119] When scene changes are detected, the inner state machine switches states according to specific events within each outer state machine.

[0120] Specifically, the stage switching logic: based on vehicle status (such as position and speed), environmental information (such as traffic lights and obstacles), and planning results, it realizes the switching between stages. Key methods include:

[0121] LaneKeepStage::WhetherEnterOvertakeStage(): Determines whether to enter the OvertakeStage. Conditions include:

[0122] Not near the intersection (is_near_junction is false).

[0123] Do not approach a red light (GetStopSByTrafficLight() returns a value greater than the threshold).

[0124] Not in a pre-lane change scenario (ScenarioType::PRE_LANE_CHANGE).

[0125] There is a stationary vehicle ahead (its speed is below the threshold and its distance is less than the threshold).

[0126] Other safety conditions (such as distance, speed, lane availability).

[0127] If the planning determines that the Overtake stage needs to be entered 5 times in a row, then Dispatch is called to switch to OvertakeStage.

[0128] OvertakeStage::WhetherEnterChangeStage(): Determines whether the lane change phase has begun. Conditions include:

[0129] Lane change is required (need_execution is true).

[0130] Lane change pipeline preparation complete (pipeline_statue_ == SUCCESS).

[0131] If the planning decision requires entry three times consecutively, switch to LaneChangeStage.

[0132] OvertakeStage::WhetherExitOvertakeStage(): Determines whether to exit to LaneKeepStage. Conditions include:

[0133] Implicit lane change successful (if entered from an implicit lane change and the pipe status is SUCCESS).

[0134] Approaching a red light (GetStopSByTrafficLight() returns a value less than the threshold).

[0135] There is no stationary vehicle ahead or the distance is too large, and the lateral offset is less than the threshold.

[0136] Approaching an intersection (distance less than a threshold).

[0137] If the planning system determines that it needs to exit after four consecutive attempts, then switch to LaneKeepStage.

[0138] Scenario switching logic: Within a Stage, the Scenario switches based on specific events and conditions. For example, in JunctionStage, it switches between Junction:Overtake and Junction:Default based on the driver's control of the accelerator. In LaneKeepStage, it switches between LaneKeep:PreLaneChange or LaneKeep:Default depending on whether it is approaching a stationary obstacle.

[0139] Please see Figure 2 and Figure 3 The state transition logic is as follows: the outer state machine (Stage) is responsible for scene switching and scheduling, while the inner state machine (Scenario) performs specific state transitions within its respective Stage based on vehicle status and environmental information. For example, when a vehicle enters an intersection scene, the outer state machine switches to "Junction Stage," and the inner state machine switches between "Junction:Overtake" and "Junction:Default" based on the driver's control of the accelerator. When a vehicle encounters a stationary obstacle, it determines whether to switch to "Overtake Stage" to detour based on whether it is approaching an intersection, approaching a red light, being in a pre-lane change scene, or whether there is a stationary vehicle in front.

[0140] The following is a detailed switching logic between LaneKeepStage and OvertakeStage states.

[0141] The main conditions for LaneKeepStage::WhetherEnterOvertakeStage() are as follows:

[0142] 1. Is it near an intersection?

[0143] If a vehicle is approaching an intersection (is_near_junction), it is not allowed to enter the Overtake phase.

[0144] 2. Are we approaching a red light?

[0145] If a vehicle approaches a red light (the return value of GetStopSByTrafficLight() is less than the threshold), it is not allowed to enter the Overtake phase.

[0146] 3. Is it in a pre-lane change scenario?

[0147] If the current scenario is a pre-lane change scenario (ScenarioType::PRE_LANE_CHANGE), entering the Overtake phase is not allowed.

[0148] 4. Is there a stationary vehicle in front?

[0149] If there are no stationary vehicles ahead (speed below the threshold and distance less than the threshold), the Overtake phase is not allowed.

[0150] 5. Other conditions:

[0151] This includes factors such as distance, speed, and lane availability to ensure the safety and rationality of overtake behavior.

[0152] If the planning determines that the process needs to enter the Overtake phase five times in a row, then the Dispatch state will be switched to Overtake.

[0153] If approaching an intersection, switch the state from Dispatch to Junction.

[0154] OvertakeStage::WhetherEnterChangeStage() primarily determines whether to enter the lane change phase based on the following conditions:

[0155] 1. Is lane change necessary at this time? (need_execution)

[0156] 2. Is the lane change pipeline for the corresponding direction ready (pipeline_statue_ == SUCCESS)?

[0157] If the above conditions are met, return true to trigger the lane change phase; otherwise, return false to remain in the overtaking phase.

[0158] If the planning determines that the LaneChange phase needs to be entered three consecutive times, then the Dispatch state will switch to LaneChange.

[0159] The conditions for using OvertakeStage::WhetherExitOvertakeStage() are as follows:

[0160] 1. Whether the vehicle transitioned from an implicit lane change to the overtaking phase.

[0161] If the current lane change is from an implicit lane change to the overtaking phase, then record the direction of the change (lc_direction_).

[0162] If the pipeline status for implicit lane change is SUCCESS, then the implicit lane change is considered successful.

[0163] 2. Are we approaching a red light?

[0164] If a vehicle approaches a red light (the return value of GetStopSByTrafficLight() is less than the threshold tf_stop_thresh), it needs to exit the overtaking phase.

[0165] 3. Is there a stationary vehicle in front?

[0166] If there are no stationary vehicles ahead and the lateral deviation is less than the threshold, it is assumed that all stationary vehicles ahead have been passed, and the overtaking phase must be exited.

[0167] If the distance to the stationary vehicle in front is too large and the lateral deviation is less than the threshold, it is also necessary to exit the overtaking phase.

[0168] 4. Is it near an intersection?

[0169] If a vehicle approaches an intersection (within the distance to the intersection of less than the threshold fobid_overtake_dist_thresh), it needs to exit the overtaking phase.

[0170] If the planning determines that the Overtake phase needs to be exited after 4 consecutive attempts, then the Dispatch state is switched to LaneKeep.

[0171] As can be understood, the state transition logic is the core connecting the two-layer state machine. The outer stage transition is responsible for macro-level scenario adjustments (such as changing from driving straight to overtaking), while the inner scenario transition is responsible for micro-level behavioral adaptations (such as changing behavior based on throttle control). Transition conditions are based on real-time sensor data, planning results, and driver input, ensuring the safety and rationality of the behavior. All transitions are implemented through the FSM's Transit and Dispatch methods, maintaining consistency in state changes.

[0172] It is understood that this embodiment adopts a two-layer state machine hierarchical architecture: including the division and collaborative working mechanism of an outer state machine (Stage) and an inner state machine (Scenario). This design method significantly reduces the complexity of the software architecture and the amount of code; it adopts a dynamic state switching mechanism, with state switching triggered by events (such as sensor data, map information, user commands) or timed triggers (such as periodic path planning); the switching logic is implemented through a state transition function, supporting condition judgment and priority arbitration.

[0173] The two-layer state machine implementation method provided by this invention decomposes complex driving behavior into multiple layers through a two-layer state machine model, reducing the complexity of the state machine and facilitating maintenance and expansion. When new traffic scenarios or changes in traffic rules occur, only the states and transition conditions need to be added or modified in the corresponding Stage or Scenario, without requiring large-scale modifications to the entire state machine. The inner state machine (Scenario) can be finely adjusted according to specific driving behaviors and traffic rules, improving the system's adaptability to complex and dynamic traffic scenarios. Through hierarchical management and flexible switching, the probability of state conflicts and logical errors is reduced, improving the accuracy and reliability of driving planning, while ensuring the system's usability and maintainability.

[0174] Please see Figure 4 The present invention also provides a system for implementing a two-level state machine. It is applied to the implementation method of the two-level state machine provided in the above embodiments, and specifically includes an outer state machine and an inner state machine.

[0175] The outer state machine controls scene switching based on the identified scene changes.

[0176] Define a base class Stage that inherits from Fsm <stage>(Using CRTP pattern) makes Stage a self-referential state machine.

[0177] Create multiple Stage-derived classes, each representing a macro-level driving scenario, including:

[0178] LaneKeepStage: Straight-line scenario.

[0179] OvertakeStage: Overtaking scenario.

[0180] JunctionStage: Intersection Scene.

[0181] Other scenarios (such as changing lanes, detouring, etc.).

[0182] Each Stage class contains specific logic for that scenario (such as conditional judgment methods) to determine whether to switch to another Stage.

[0183] Specifically, the outer state machine is implemented using the general finite state machine template class as follows:

[0184] Stage Design: A subclass state machine created using the Curious Recurring Template Pattern (CRTP). Different Stages are defined based on different traffic scenarios, such as going straight, changing lanes, intersections, and detours. Each Stage represents a macroscopic driving task or scenario type, such as "Lane KeepStage" or "Lane Change Stage".

[0185] The Stage is implemented as follows:

[0186] / / Base class

[0187] class Stage : public Fsm <stage>{}

[0188] / / ↓

[0189] / / Derived class

[0190] class LaneKeepStage : public Stage{}

[0191] As can be understood, a Stage, acting as an outer state machine, is responsible for the overall management and scheduling of the scene. It gains state transition capabilities by inheriting the Fsm template and implements polymorphism through CRTP, allowing each Stage to define its own state and behavior. Switching between Stages is based on high-level conditions (such as environmental information).

[0192] Inner state machine: Based on the scene state of the outer state machine, the vehicle state is switched by acquiring environmental and vehicle information.

[0193] In this embodiment, for each Stage, a corresponding Scenario base class is defined, which inherits from Fsm. <scenario>(Using CRTP mode). For example:

[0194] LaneKeepScenario is the base class of Scenario within LaneKeepStage.

[0195] JunctionScenario is the base class of Scenario within JunctionStage.

[0196] Create multiple Scenario-derived classes, each representing a specific behavioral state:

[0197] In LaneKeepStage: LaneKeepDefaultScenario (default), LaneKeepPreLaneChangeScenario (pre-lane change), LaneKeepThrottleOverrideScenario (throttle control), etc.

[0198] In the FunctionStage: FunctionDefaultScenario (default), FunctionOvertakeScenario (overtaking), etc.

[0199] Each Scenario class handles specific behavioral logic and responds to events (such as driver input).

[0200] Specifically, the Scenario design adopts the following approach:

[0201] The subclass state machine is created using the Curious Recurring Template Pattern (CRTP). Within each Stage, multiple Scenarios are defined based on specific driving behaviors and traffic rules. For example, in the "Lane Keep Stage", there are "Lane Keep:Default", "Lane Keep:Pre Lane Change", and "Lane Keep:Overtake".

[0202] The implementation method of Scenario is as follows:

[0203] / / Base class

[0204] class LaneKeepScenario : public Fsm <lanekeepscenario>{}

[0205] / / ↓

[0206] / / Derived class

[0207] class LaneKeepPreLaneChangeScenario : public LaneKeepScenario {}

[0208] class LaneKeepThrottleOverrideScenario : public LaneKeepScenario {}

[0209] class LaneKeepDefaultScenario : public LaneKeepScenario {}

[0210] It can be understood that the Scenario, as an inner state machine, performs fine-grained state management within the Stage. It gains state transition capabilities by inheriting the Fsm template and implements polymorphism through CRTP. The switching of the Scenario is triggered by the Stage or based on specific events (such as throttle control), thereby achieving fine-grained control of driver behavior.

[0211] Specifically, the stage switching logic: based on vehicle status (such as position and speed), environmental information (such as traffic lights and obstacles), and planning results, it realizes the switching between stages. Key methods include:

[0212] LaneKeepStage::WhetherEnterOvertakeStage(): Determines whether to enter the OvertakeStage. Conditions include:

[0213] Not near the intersection (is_near_junction is false).

[0214] Do not approach a red light (GetStopSByTrafficLight() returns a value greater than the threshold).

[0215] Not in a pre-lane change scenario (ScenarioType::PRE_LANE_CHANGE).

[0216] There is a stationary vehicle ahead (its speed is below the threshold and its distance is less than the threshold).

[0217] Other safety conditions (such as distance, speed, lane availability).

[0218] If the planning determines that the Overtake stage needs to be entered 5 times in a row, then Dispatch is called to switch to OvertakeStage.

[0219] OvertakeStage::WhetherEnterChangeStage(): Determines whether the lane change phase has begun. Conditions include:

[0220] Lane change is required (need_execution is true).

[0221] Lane change pipeline preparation complete (pipeline_statue_ == SUCCESS).

[0222] If the planning decision requires entry three times consecutively, switch to LaneChangeStage.

[0223] OvertakeStage::WhetherExitOvertakeStage(): Determines whether to exit to LaneKeepStage. Conditions include:

[0224] Implicit lane change successful (if entered from an implicit lane change and the pipe status is SUCCESS).

[0225] Approaching a red light (GetStopSByTrafficLight() returns a value less than the threshold).

[0226] There is no stationary vehicle ahead or the distance is too large, and the lateral offset is less than the threshold.

[0227] Approaching an intersection (distance less than a threshold).

[0228] If the planning system determines that it needs to exit after four consecutive attempts, then switch to LaneKeepStage.

[0229] Scenario switching logic: Within a Stage, the Scenario switches based on specific events and conditions. For example, in JunctionStage, it switches between Junction:Overtake and Junction:Default based on the driver's control of the accelerator. In LaneKeepStage, it switches between LaneKeep:PreLaneChange or LaneKeep:Default depending on whether it is approaching a stationary obstacle.

[0230] It is understood that this embodiment adopts a two-layer state machine hierarchical architecture: including the division and collaborative working mechanism of an outer state machine (Stage) and an inner state machine (Scenario). This design method significantly reduces the complexity of the software architecture and the amount of code; it adopts a dynamic state switching mechanism, with state switching triggered by events (such as sensor data, map information, user commands) or timed triggers (such as periodic path planning); the switching logic is implemented through a state transition function, supporting condition judgment and priority arbitration.

[0231] The two-layer state machine implementation system provided by this invention decomposes complex driving behavior into multiple layers through a two-layer state machine model, reducing the complexity of the state machine and facilitating maintenance and expansion. When new traffic scenarios or changes in traffic rules occur, only the states and transition conditions need to be added or modified in the corresponding Stage or Scenario, without requiring large-scale modifications to the entire state machine. The inner state machine (Scenario) can be finely adjusted according to specific driving behaviors and traffic rules, improving the system's adaptability to complex and dynamic traffic scenarios. Through hierarchical management and flexible switching, the probability of state conflicts and logical errors is reduced, improving the accuracy and reliability of driving planning, while ensuring the system's usability and maintainability.

[0232] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the two-level state machine implementation methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processors and the memory, configured to enable information interaction between the processors and the memory.

[0233] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0234] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0235] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0236] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in any of the two-level state machine implementation methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0237] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described two-level state machine implementation method.

[0238] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0239] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0240] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0241] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as "C" or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0242] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0243] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0244] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0245] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0246] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0247] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.< / lanekeepscenario> < / scenario> < / stage> < / stage> < / lanekeepscenario> < / scenario> < / stage> < / stage> < / s> < / s> < / s> < / s> < / s> < / e> < / s> < / e> < / s>

Claims

1. A method for implementing a two-level state machine, characterized in that, It includes: Based on the identified scene changes, the outer state machine controls the scene switching; Based on the scene state of the outer state machine, the inner state machine controls the switching of vehicle state by acquiring environmental and vehicle information.

2. The method for implementing a two-level state machine according to claim 1, characterized in that, Both the inner and outer state machines use a preset finite state machine template class for state switching and event distribution. Furthermore, the state transition function Transit is implemented based on the template class Fsm. <s>Implement the event dispatch function Dispatch based on the template class Fsm. <e> 。< / e> < / s> <s> 3. The method for implementing a two-level state machine according to claim 1, characterized in that, The outer state machine defines different stages according to different traffic scenarios, and each stage represents a macroscopic driving task or scenario type.

4. The method for implementing a two-level state machine according to claim 3, characterized in that, The macro-level driving tasks or scenario types include: LaneKeepStage: Straight-line driving scenario; OvertakeStage: Overtaking scenario; JunctionStage: Intersection Scene.

5. The method for implementing a two-level state machine according to claim 3, characterized in that, Define a base class Stage, and make Stage a self-referencing state machine; Each Stage class contains specific logic for that scenario, used to determine whether to switch to another Stage.

6. The method for implementing a two-level state machine according to claim 1, characterized in that, The inner state machine includes multiple Stages, and each Stage defines a corresponding Scenario base class. Each Scenario base class handles specific behavioral logic and responds to events.

7. The method for implementing a two-level state machine according to claim 6, characterized in that, The Scenario base class includes: LaneKeepScenario is the base class of Scenario in LaneKeepStage; and LaneKeepDefaultScenario represents the default, LaneKeepPreLaneChangeScenario represents pre-lane change, and LaneKeepThrottleOverrideScenario represents throttle control. JunctionScenario is the base class for Scenario within JunctionStage; and JunctionDefaultScenario represents the default setting, while JunctionOvertakeScenario represents overtaking.

8. A system for implementing a two-level state machine, characterized in that, include: Outer state machine: Controls scene switching based on recognized scene changes; Inner state machine: Based on the scene state of the outer state machine, the vehicle state is switched by acquiring environmental and vehicle information.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7. < / s>

Images