WO2023154987A1

WO2023154987A1 - Control system and method for an autonomous vehicle

Info

Publication number: WO2023154987A1
Application number: PCT/AU2023/050118
Authority: WO
Inventors: Raymond Scott; Andrew FRAHN; Farbod TORABI
Original assignee: Applied Electric Vehicles Ltd
Priority date: 2022-02-21
Filing date: 2023-02-21
Publication date: 2023-08-24

Abstract

A control system for an autonomous vehicle comprising at least a first controller that periodically generates trajectory paths towards an intended travel goal of said vehicle on a continuous basis, and each of said trajectory paths terminates at rest. A second controller is in communication with the first controller, with the second controller controlling the drivetrain actuators of the vehicle to implement the trajectory paths to completion, without further input from the first controller if communication between the first controller and the second controller is lost.

Description

CONTROL SYSTEM AND METHOD FOR AN AUTONOMOUS VEHICLE

TECHNICAL FIELD

This invention relates to control system and method for an autonomous vehicle. In particular, the invention is described with reference to a control system having a first controller continually generating trajectory paths that terminate to rest, and a second controller in communication with the first controller. The second controller controlling the vehicle drivetrain actuators to completion without further input if communication between the first controller and second controller is lost.

BACKGROUND

An autonomous vehicle is one capable of sensing its own environment and operating without human involvement. A human is not required to take control of the vehicle at any time, nor is a human passenger required to be present in the vehicle at all. Such an autonomous vehicle, which is fully automated, relies on sensors, actuators, complex algorithms, machine learning systems and processors to execute software.

Autonomous vehicles rely on a variety of sensors for their operation. Radar sensors monitor the position of nearby vehicles. Video cameras detect traffic lights, read road signs, track other vehicles, and look for pedestrians. Lidar sensors bounce pulses of light off the surroundings to measure distances, detect road angles and identify lane markings. Ultrasonic sensors can be used to detect curbs and other vehicles when parking.

Sophisticated software is used to process all the sensory input, plots a path, and sends instructions to the car’s actuators, which control acceleration, braking, and steering. Hard- coded rules, obstacle avoidance algorithms, predictive modelling, and object recognition help the software follow traffic rules and navigate obstacles.

An autonomous vehicle will typically include a communication interface to enable the control system of the vehicle to communicate with a backend transport system.

For an autonomous vehicle to travel towards an intended travel destination (goal) it is relying on both externally sourced data and internally sourced data. External data is that typical being provided by the remotely located backend system, whilst internal data is that stored on board the vehicle and/or sensed data collected by the variety of sensors on the vehicle. A vehicle, whether autonomous or semi-autonomous relies on Advanced Driver Assistance Systems (ADAS) to prevent accidents, injuries and death and the serious impact of those accidents that cannot be avoided. In the case of a semi-autonomous vehicle, the vehicle may have a high-level of automation, where the vehicle performs all driving tasks but may require geofencing, and “human override” is an option. However, an autonomous vehicle as described by SAE J3016 level 4 and level 5 may have zero human attention or interaction and is considered highly or fully automated. As such an autonomous vehicle should be provided with a “fail-safe mode” should there be loss or disruption to its ADAS functionality.

A conventional (prior art) autonomous vehicle as shown in Fig. 1 will have autonomous driving hardware/software 50 with integrated ADAS. This integrated ADAS may include cameras 51, radars 52, Lidars 53, GPS/IMU 54, and Vehicle-to-Vehicle (V2V) communication 55a, Vehicle-to-Infrastructure(V2I) communication 55b, and Vehicle-to-Everything (V2X) communication 55c. These various components allow for various tasks to be carried out as shown flowing from left to right, namely Perception (detection, fusion, tracking) 56 and Localization (Map matching) 57, Prediction (agent modelling) 58, Planning (route planning, lawful driving) 59 and Controls (route execution) 60. All these tasks together allows for autonomous driving hardware/software 50 to control the various vehicle systems 70, namely battery system 71, motor control unit(s) 72, steering module 73, brake module 74 and body module 75. The problem with this prior art arrangement is that should there be a disruption, fault, or loss of one or more components of the autonomous driving hardware/software 50, it means that control of the various vehicle systems may cause the vehicle to be at risk of reduced, or complete loss of controllability. This could include a runaway vehicle or stopping in an unsafe location. Thus, increasing the risk of an accident, property damage, or injury.

There have been attempts in the prior art to ensure that vehicles can operate in a fail-safe mode and be safely stopped. For instance, US Patent 9994219 (Nilsson et al.) discloses a safety stoppage device for use with what is referred to as an autonomous vehicle. This prior art uses a dedicated processor to continually predict where a drivable space exists, and safely stores a safe trajectory to a stop within the drivable space. Whilst this prior art alleges to be for an “autonomous vehicle” it is really for use with a vehicle that is not fully automated. This is because the safety stoppage device of this prior first checks to see if a driver (human) can take control of the vehicle, and if not, the vehicle is then controlled to a safety stop. As such this, prior art is not suited to a “fully automated” vehicle, but rather one where human override is an option.

WO20 17/120057 Al (Waymo LLC) is directed to a method of controlling an autonomous vehicle. The method includes generating from a primary computing system a nominal trajectory from a location to achieve a mission goal and fallback trajectory from the location in order to safely stop the vehicle. The nominal and the fall back are identical between the location and a divergent point. However, they diverge after the divergent point. The fall-back trajectory is sent to and received by a secondary computing system. The secondary computing system waits for an updated trajectory from the primary computing system while controlling the vehicle according to the fall back. When the vehicle reaches a threshold point on the fall back and an updated trajectory has not yet been received by the secondary computing system, the secondary computing system continues to control the vehicle according to the fall-back trajectory in order to safely stop the vehicle. This method of controlling an autonomous vehicle has various disadvantages. Firstly, additional data is being both generated and communicated due to the requirement for multiple paths to be created. Secondly there is a requirement to overlap the data for both of the generated trajectories. Thirdly, updated trajectories are ignored by the secondary computer after the threshold. A substantial deviation from the intended path may occur during the process of implementing a path to completion if localisation data is also disrupted and an inability for the path planner to correct for drift , which may put the vehicle or surrounding environment at risk. Additionally, if new obstacles arise after the threshold, then there is no chance to account for them except to stop if data is received by sensors dedicated to the secondary computing system only.

US Patent 10139828 (Ho et al.) describes an autonomous vehicle operated with safety augmentation. With reference to its Fig. 16 a route planning component 1650, which is part of the vehicle’s ADAS is calculating both a primary trajectory 1651 and one or more separate fail-safe trajectories 1653. It discloses using controller 1644 (and possibly redundant controller 1648) with lower-level logic to implement both the primary trajectory 1651 along with one or multiple separate fail-safe trajectories 1653. In variations, the route planning component 1650 operates to calculate multiple fail-safe trajectories 1653 at one time, with each fail-safe trajectory 1653 providing assurance that the vehicle can reach safety (e.g., location for a safe stop) in response to a particular type of disabling failure or condition. A disabling failure may correspond to a malfunction or degradation of a vehicle component which limits or precludes operation of the vehicle beyond a predetermined threshold of operability. Likewise, a disabling condition may correspond to an external event (e.g., road spill, large debris on sensor) that similarly limits or precludes operation of the vehicle beyond a predetermined threshold of operability. In this arrangement where the system is calculating multiple fail-safe trajectories it is doing so to match them to potentially different failures, for example one fail-safe trajectory being calculated for steering failure, whereas another may be calculated for brake degradation. However, this prior art is faced with several disadvantages. Firstly, both controllers 1644, 1648 are part of the ADAS hardware, and should there be failure at the ADAS hardware level, controllers 1644, 1648, may not be able to signal the vehicle control subsystem 1630, that includes propulsion 1632, steer 1634, Brake 1636 and lights 1638 to carry out the fail-safe trajectory. Secondly, because the route planning component 1650 is generating primary trajectories, separate to one or more fail-safe trajectories, the controllers and other hardware/software is having to store and update multiple packets of data for these various trajectories becomes overly complicated.

US10394243 Al (Ramezani et al.) is directed to a method in which a computing system may generate a normal path plan for an autonomous vehicle, separate to a safe path plan or hybrid path plan including a normal path plan and safe path plan. When a fault condition occurs, the computing system may transition from executing the normal path plan to safe path plan to safely stop the vehicle. If the trajectory system fails to update the first movement by a given time, then the vehicle will transition to the second movement and stop the vehicle. There are two major disadvantages associated with this method. The first is that once the first movement has expired the second movement runs to completion, regardless of potentially new data being available. A substantial deviation from the intended path may occur during the process of following a path to completion if localisation data is also disrupted, and an inability for the path planner to correct for this after the path expires, may put the vehicle or surrounding environment at risk. Additionally, the topology of the system lacks redundancy as the path generator shares the system that implements the path. In many cases the failure for the path planner to develop a new path is likely to impact the movement implementation.

In consideration of the above, embodiments of the present invention aim to provide a control system and method for an autonomous vehicle that overcomes or reduces at least one of the abovementioned disadvantages of the known prior art. SUMMARY

In a first aspect the present invention consists of a control system for an autonomous vehicle comprising at least a first controller that periodically generates trajectory paths towards an intended travel goal of said vehicle on a continuous basis, wherein each of said trajectory paths terminates at rest, and a second controller in communication with said first controller, said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost.

Preferably during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest.

Preferably should said second controller identify that a newly generated trajectory path does not terminate at rest, said second controller will not continue motion of said vehicle beyond the previously generated trajectory path.

Preferably said second controller shares vehicle data at regular intervals with said first controller for the purposes of trajectory planning.

Preferably said vehicle data shared by said second controller with said first controller includes instantaneous acceleration, deceleration, and rotational limits.

Preferably each said trajectory path has a target speed communicated by said first controller for at least one point along the said trajectory path, allowing said second controller to optimise the acceleration and deceleration to match the environment.

Preferably said second controller assesses a newly generated trajectory path for validity based on instantaneous vehicle pose and vehicle handling characteristics.

Preferably said secondary controller shares the localization data from a global navigation system associated with said first controller on a redundant communication bus separate from the trajectory planning of said first controller, so that said secondary controller can use said localization data from said global navigation system for path implementation, if communication with said first controller is disrupted or lost.

Preferably in one embodiment a first global navigation system and a first object detection system are both in communication with said first controller. In this embodiment, a second global navigation system is in communication with said second controller and said second global navigation system is independent from said first global navigation system.

Preferably a second object detection system is in communication with said second controller and said second object detection system is independent from said first object detection system.

Preferably each of said first object detection system and said second detection system may include any one or more lidars, radars and cameras.

Preferably each trajectory path is made up of path data setting up a plurality of trajectory points and each sequentially generated trajectory path may share one or more common trajectory points from a previously generated trajectory path.

Preferably each trajectory path is made up of path data setting up a plurality of trajectory points and an integral safe exit portion is a sub-set of said plurality of trajectory points at the furthest end thereof.

In a second aspect the present invention consists of a control system for an autonomous vehicle comprising at least a first controller and an associated first global navigation system, said first controller periodically generates dual-purpose trajectory paths towards an intended travel goal of said vehicle on a continuous basis, wherein each of said trajectory paths has a first segment for trajectory and a second segment for a planned exit trajectory that terminates at rest, and said vehicle further comprising a second controller and an associated second global navigation system, said second controller in communication with said first controller and said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost, and during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it, and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest via said planned exit trajectory.

Preferably said secondary controller shares the first localization data from said first global navigation system redundant from the trajectory planning of said first controller, so that said secondary controller can either rely on first localization data from said first global navigation system or rely on the second localization data from said second global navigation system for path implementation, if communication with said first controller is disrupted or lost.

Preferably said first controller provides a corridor of travel for said planned exit trajectory, such that during a disruption event where said first said controller fails to communicate an updated trajectory path and localization data is compromised, said second controller will shorten said planned exit of trajectory such that the calculated cumulative error in localization data does not exceed the outer limits of said corridor of travel.

Preferably said corridor of travel during normal travel is narrower than it is when said disruption event has occurred, such that during normal travel said second controller can optimise the implemented trajectory path with minor deviation to allow for complex-motion if available.

Preferably if said second controller via its associated second object detection system determines that said corridor of travel is no longer valid because of detection of an object, second controller instigates a fall-back emergency stop.

In a third aspect the present invention consists of a method for operating an autonomous vehicle, said method comprising: a first controller on said vehicle periodically generates trajectory paths towards an intended travel goal of said vehicle on a continuous basis, based on localization data received from an associated first global navigation system and sensed data from an associated first object detection system, wherein each of said trajectory paths terminates at rest; and a second controller in communication with said first controller, and said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost. Preferably during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, and said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest.

Preferably said secondary controller shares the localization data from a global navigation system associated with said first controller on a redundant communication bus separate from the trajectory planning of said first controller, so that said secondary controller can use said location data from said global navigation system for path implementation, if communication with said first controller is disrupted or lost.

Preferably in one embodiment a first global navigation system and a first object detection system are both in communication with said first controller. In this embodiment a second global navigation system is in communication with said second controller and said second global navigation system is independent from said first global navigation system.

Preferably a second object detection system is in communication with said second controller and said second object detection system is independent from said first object detection system. Preferably each of said first object detection system and said second detection system may include any one or more lidars, radars and cameras.

Preferably said first controller provides a corridor of travel for said planned exit trajectory, such that during a disruption event where said first controller fails to communicate an updated trajectory path and localization data is compromised, said second controller will shorten said planned exit of trajectory such that the calculated cumulative error in localization data does not exceed the outer limits of said corridor of travel.

BRIEF DESCRIPTION OF THE DRAWINGS

Further disclosure, objects, advantages and aspects of the present invention may be better understood by those skilled in the relevant art by reference to the following description of preferred embodiment taken in conjunction with the accompanying drawing, which is given by way of illustration only and thus not limitative of the present invention, and in which:

Fig. 1 is a schematic block diagram of a prior art autonomous vehicle with integrated ADAS.

Fig. 2 is a schematic block diagram of an autonomous vehicle in accordance with an embodiment of the present invention. Fig. 3 is schematic diagram of dual-purpose trajectory paths for the autonomous vehicle of Fig. 2 being calculated at four different instances.

Fig. 4 is a schematic diagram where a disruption to communication between controllers has occurred during the execution of a dual-purpose trajectory path of Fig. 3, causing the failsafe mode of the trajectory path to commence, but when communication between the controllers is restored a newly generated path is adopted.

Figs. 5a and 5b are a schematic diagram of how a trajectory path of the type shown in Fig. 3 is provided with a corridor of travel (acceptable area of actual travel), and where a disruption to communication between controllers has occurred during the execution of a dualpurpose trajectory, and an object is detected nearby, the corridor (acceptable area of actual travel) is used to shorten a trajectory path to stay within the corridor of travel and in doing so avoid collision with the object.

DETAILED DESCRIPTION

In the present specification an “autonomous vehicle” is one capable of sensing its own environment and operating without human involvement. For the purposes of this specification the autonomous vehicle is “fully automated”.

With reference to the figures there is an autonomous vehicle (remote control platform) 10. Autonomous vehicle 10, may be an electrically powered vehicle of the type described in International Patent Publication No. WO 2022/082271 to the present applicant, having a low- profile platform which carries all the mechanical, electrical, and structural componentry necessary for a fully functional road vehicle, including the drive and steering system, and the braking system. Such autonomous vehicle 10 may typically have four wheels, namely two pairs of wheels, with each wheel driven by an independent electric motor. The electric motors, and any associated control units and sensors are powered by battery packs. However, autonomous vehicle 10 is not limited to that shown in International Patent Publication No. WO 2022/082271 and may have a different drivetrain configuration to that shown therein. For example, it may be a low-profile vehicle, or a delivery/haulage vehicle having more than four wheels, such as a semi-trailer truck, or even be a tracked vehicle.

Fig. 2 shows the layout of autonomous vehicle 10 having two distinct systems, namely autonomous driving hardware/software 150 in communication with automation system 170, via a communication bus 160. Autonomous driving hardware/software (or ADAS Stack) 150 comprises various components, namely cameras 151, radars 152, Lidars 153, a primary global navigation system (GPS/IMU) 154, along with the ADAS Vehicle-to-Vehicle (V2V) communication 155a, Vehicle-to-Infrastructure(V2I) communication 155b and Vehicle-to-Everything (V2X) communication 155c. These various components allow for various tasks to be carried out as shown flowing from left to right, namely Perception (detection, fusion, tracking) 156 and Localization (Map matching) 157, Prediction (agent modelling) 158, and Trajectory Planner (route planning and lawful driving) 159. Cameras 151, radars 152 and Lidars 153 form part of a “first object detection system” that is in communication with Trajectory Planner 159.

In the present specification, ADAS Stack 150 which includes Trajectory Planner 159, is considered the “first controller” of vehicle 10.

Automation system 170 comprises battery module 171, motor control unit(s) 172, steering module 173, brake module 174, body module 175 and Central Control Unit (CCU) 179.

On ADAS stack 150, Trajectory Planner 159 is a “trajectory generator” capable of generating dual-purpose trajectory paths 200a, 200b, 200c and 200d shown in Fig. 3. Hereinafter, these dual-purpose trajectory paths will simply be referred to as trajectory paths.

Each trajectory path has a “first segment” G for trajectory towards an intended travel goal, namely a first purpose, and a “second segment” S for fail-safe mode (safe exit), namely a second purpose. If such trajectory path is followed through first segment G and second segment S, vehicle 10 will terminate at rest.

So, in Fig. 3 the “first segments” of trajectory paths 200a, 200b, 200c and 200d are respectively shown as Ga, Gb, Gc and Gd and the “second segments”, namely the fail-safe segments, respectively shown as Sa, Sb, Sc and Sd. These second segments are in effect “a safe exit path to stop”. Where vehicle 10 is to come to rest at the furthest end of each second segment, is depicted schematically in Fig. 3 by a “stop symbol”. Each segment whether first or second segment is seen to have a plurality of trajectory points.

When a trajectory path, such as trajectory path 200a is generated by Trajectory Planner 159, it is generated with both its first segment” Ga for trajectory towards the intended travel goal X, and its second segment Sa for its “fail-safe mode” which preferably is “limited fail operational” terminating at rest. This trajectory path is being calculated based on data being processed within ADAS Stack 150. In use, once trajectory path 200a is generated, it is communicated from Trajectory Planner 159 via communication bus 160 to CCU 179 of automation system 170.

In the present specification CCU 179 is considered the “second controller” of vehicle 10.

In normal use, Trajectory Planner 159 is continually generating and communicating trajectory paths to CCU 179. The time interval between generation of trajectory paths is very small, say for example every 100 milliseconds. Each trajectory path will be time stamped, so that CCU 179 is only ever controlling the sub-systems of battery module 171, motor control unit(s) 172, steering module 173, brake module 174 and body module 175 based on the most recent trajectory path it has received.

With reference to Fig. 3, you will see that at time t = t₀ the trajectory path 200a is the one being executed by CCU 179. Subsequently and immediately thereafter at time t = ti, trajectory path 200b has replaced trajectory path 200a. This goes on with trajectory path 200c, replacing trajectory path 200b at time t = ti, and trajectory path 200d, replacing trajectory path 200c at time t = ts .

In normal use, because the trajectory paths are being generated and communicated at very small intervals, CCU 179 has only had time to execute the first segment of the most recently received trajectory path, namely its first purpose of travel towards its intended goal, before it is replaced by the subsequent trajectory path. With reference to Fig. 3, let us say vehicle 10 is travelling to a goal along a straight road. At t = t₀ the first segment Ga of trajectory path 200a is made of a plurality of trajectory points, making up a set of data, heading towards the goal in a substantially straight line, whereas the second segment Sa, namely the fail-safe mode, is made up of trajectory points, making up a different set of data, that deviate from the intended travel goal and would be the fail-safe path (or safe exit path to stop) at the instant it was generated. Because in normal use, vehicle 10 would have only travelled along a portion of first segment Ga of trajectory path 200a before it was replaced by the newly generated trajectory path 200b, vehicle 10 does not reach second segment Sa (the fail-safe mode) of trajectory path 200a and has now commenced on first segment Gb of trajectory path 200b which is travelling towards the intended travel goal. Likewise, as vehicle 10 would have only travelled along a portion of first segment Gb of trajectory path 200b before it was replaced by the newly generated trajectory path 200c, vehicle 10 does not reach second segment Sb (the fail-safe mode) of trajectory path 200b, and so on. You can see in Fig. 3 the progression of vehicle 10 towards the intended goal at the various time intervals.

What should be understood, is that for ease of reference and clarity the second segments Sa, Sb, Sc and Sd, namely the fail-safe mode segments of trajectory paths 200a, 200b, 200c and 200d in Fig. 3 are shown to deviate quite differently to the respective first segments Ga, Gb, Gc and Gd. However, the deviation of the second segments (fail-safe mode segments) may in reality be slight, or even simply provide a failsafe trajectory that brings vehiclelO to rest in a substantially straight line over a short distance.

Each trajectory path when generated has both the “intended travel” first segment and the “fail-safe mode” second segment based on the most recent data available to at the instant it was generated. Should a “disruption event” occur that disrupts the generation of trajectory paths by Trajectory Planner 159, then CCU 179 is acting on the most recent trajectory path that Traveller Planner 159 has communicated to it. Because there is no replacement trajectory path, CCU 179 now acting on the most recently generated trajectory path, is in “limited fail operation” which it follows from the first segment of the trajectory path to the second segment (fail-safe mode) until it terminates in rest.

A “disruption event” for the purposes of this specification, may be that caused by failure, damage, or limited operability of the ADAS Stack 150 in both its hardware or software, or to communication bus 160. It may also include but not be limited to environmental issues where operability of sensor hardware, such as for example cameras 151, may be affected by mud, rain, hail, snow etc, or an unexpected sensed environmental condition such as vehicle 10 encountering “black ice” etc. A “disruption event” may also occur due to loss of external data communication normally provided to vehicle 10, say from SCADA (not shown), GPS, V2V, V2X etc. The disruption event may also be due to an accumulation of a several issues which may impact on the ability for a trajectory path to be generated.

Regardless of what causes the “disruption event” to prevent the generation of trajectory paths, CCU 179 will only act on the most recently generated trajectory path received by it. For CCU 179 to act on the most recently generated trajectory path, that trajectory path must be complete. As such, should the most recently generated trajectory path be incomplete, say because the second (fail-safe mode) segment is missing or corrupted, then this recently generated path will not be acted upon by CCU 179, and it will instead act on the previously generated “complete” trajectory path.

In the same manner, if a “complete” trajectory path is provided to CCU 179 after a disruption has taken place and vehicle 10 has deviated from the travel goal towards a safe stopping location, namely the furthest end of a fail-safe second segment S, CCU 179 can adopt this newly generated trajectory path. This newly generated trajectory path might be a modification to the fail-safe second segment S or may bring vehicle 10 back towards the original travel path/goal. This will be discussed later with reference to Fig.4.

In normal use, to ensure that any generated trajectory path communicated to it from Trajectory Planner 159 is “complete”, CCU 179 determines if the path is plausible to adopt, based on the position, velocity and orientation of vehicle 10 and the dynamic capability of vehicle 10.

In allowing that trajectory path to be adopted by CCU 179 after vehicle 10 is approaching a stopping location, any variation in environmental conditions since the disruption occurred can potentially be accounted for. These might include previously unseen obstacles which might include people and animals. The newly adopted trajectory path may include corrections that account for drift from the fail-safe second segment S, namely the safe exit path.

In effect, you have Trajectory Planner 159 as part of ADAS stack 150 acting as a “first controller” communicating generated trajectory paths to a “second controller” namely the CCU 179. The purpose of this second controller (CCU 179) is for controlling the vehicle drivetrain actuators via motor control unit(s) 172, steering module 173, brake module 174, and allows vehicle 10 to follow the trajectory path to completion without further input from the “first controller” if communication is lost.

During normal use, CCU 179 (the second controller) shares the instantaneous acceleration, deceleration, and rotational limits at regular intervals with ADAS stack 150 (first controller) for the purposes of trajectory planning.

Each trajectory path has its first segment (the intended travel trajectory) that precedes the integral second segment (the fail-safe exit trajectory), and a target speed is communicated by ADAS stack 150 for the end of the first segment of the trajectory path, allowing CCU 179 to optimise the acceleration and deceleration to match the environment. CCU 179 stores the data of newly generated trajectory paths provided by simplest form once a newly generated trajectory path has been sent to CCU (179) and acted upon, the trajectory path immediately before is erased from storage. However, it might be desired to store several previously generated and executed trajectory paths over a period time in a “drive data recorder” before the older ones are erased.

It was earlier stated that CCU 179 can follow a trajectory path to completion without further input from the ADAS Stack 150 if communication is lost. However, CCU 179 may optionally share the data from primary global navigation system (GPS, IMU) 154 of the ADAS Stack 150 on a common redundant network, see communication link 161. As such, even if trajectory path data is disrupted or incomplete, CCU 179 can rely on primary global navigation system 154 for purpose of localisation during the completion of the last valid trajectory path. Likewise, communication links (not shown) may interconnect CCU 179 (secondary controller) with any of the Vehi cl e-to- Vehicle (V2V) communication 155a, Vehicle-to-Infrastructure(V2I) communication 155b and Vehicle-to-Everything (V2X) communication 155c.

In the same manner, automation system 170 which includes CCU 179 may preferably have a an “independent” secondary global navigation system 254 for the purposes of redundant localisation purposes. This secondary global navigation system 254 might in turn be used to provide redundancy to primary global navigation system 154 associated with ADAS Stack 150. Additionally, CCU 179 may preferably be in communication with an independent “second object detection system” which includes cameras 251, radars 252 and Lidars 253. This second object detection system provides a level of redundancy, to further aid in the completion of the last valid trajectory path received by CCU 179. It should be noted that it is preferable that if an object is detected, it is preferable to avoid deviation from the trajectory path if possible, and cause vehicle 10 to decelerate more quickly than planned, to stop prior to the object that is on the trajectory path.

Where CCU 179 has access to data from both primary global navigation system 154 and secondary global navigation system 254, it will rely on the data provided by primary global navigation system 154. CCU179 will only rely on data from secondary global navigation system 254 if it is not receiving data from primary global navigation system 154. Fig. 4 depicts how CCU 179 can adopt a new trajectory path for vehicle 10, if communication is disrupted between ADAS 150 and CCU 179 and the vehicle had already commenced implementation of safe segment of the previous path. In Fig. 4 vehicle 10 is initially following trajectory path 200a shown in Fig. 3. As vehicle 10 is travelling along first segment Ga of trajectory path 200a, a “disruption event” occurs between trajectory point P and the intended expiry of first segment Ga (of path 200a), namely trajectory point Q. Because of this “disruption event” path 200a is the last “complete” trajectory path received by CCU 179, and if communication with Travel Planner 159(of ADAS 150) was not re-established, CCU 179 would bring vehicle 10 to rest by following fail-safe second segment Sa. However, in this scenario depicted in Fig. 4, during the early implementation by CCU 179 of fail-safe second segment Sa between trajectory points Q and R, communication has been restored between Travel Planner 159 (of ADAS 150) and CCU 179, resulting in a newly general trajectory path being received by CCU 179 at point R. Now that this newly generated path has been adopted, vehicle 10 is no longer following fail-safe second segment Sa, but is now following this newly adopted trajectory path made up of first segment Gm and second (fail-safe) segment Sm.

As part of the trajectory planning, Trajectory Planner 159 of ADAS Stack 150 operationally sets an “acceptable area of actual travel” in which a trajectory path 200 may operate. This acceptable area of actual travel will for the purposes of this specification be referred to as a “corridor of travel”, hereinafter referred to as corridor 90, and it is a region of error that would be acceptable for vehicle 10 to occupy. Operationally, corridor 90 may vary in width, and it may for instance be narrower in normal travel, than when communication between CCU 179 and ADAS Stack 150 has been lost or disrupted. For example, where vehicle 10 is a “conventionally medium sized” passenger vehicle of say about 3.5m long and 1.5 metre long, corridor 90 may for example vary by about 0.5m between its narrower and wider widths. However, it should be understood that this variation may vary depending on size, application and environment in which vehicle 10 operates.

Fig 5(a) depicts a trajectory path 200 (of vehicle 10), when a disruption event has occurred and CCU 179 is controlling vehicle 10. Trajectory path 200 has a corridor 90 of acceptable tolerance, whose outer limits (edges) are depicted as dotted lines 91 and 92. Corridor 90 may be defined as a” constant value” or updated as vehicle 10 travels through different environmental conditions. The effective width of corridor 90 might be constant or become wider towards the end “stopping location” to allow vehicle 10 to travel a longer distance before it might “drift” towards an outer limit 91,92 of corridor 90.

During this disruption event, corridor 90 would act to ensure that vehicle 10 does not stray significantly from a “planned exit path” if sensor input to CCU 179 is limited and or road conditions are poor. A disruption event might cause the total loss of localisation data from the error corrected GPS (that forms part of global navigation system 254), and CCU 179 might need to determine its position based on a combination of wheel speed and data from the IMU. Unlike the error corrected GPS that has a fixed tolerance band for any received value, the combination of wheel speed and IMU data has an instantaneous error that integrates to a cumulative error over time. As such, the further vehiclelO travels, the larger the cumulative error will become if not corrected by the navigation system, and over time vehicle 10 is likely to stray outside of the acceptable limits of corridor 90. Preferably a planned exit path would have a length and corridor 90 that would allow vehicle 10 to terminate at rest at a planned location prior to reaching the limits of corridor 90.

In Fig 5(b) at point 90 of trajectory path 200, you can see “potential trajectory boundaries” 200x and 200y diverge from path 200, and they represent the potential error margin of the vehicle within corridor 90. These “potential trajectory boundaries” show where trajectory path 200 could be if vehicle 10 drifted within the acceptable outer limits 91,92 of corridor 90. Where an object 80 is detected by CCU 179, path 200 could potentially be at an outer limit of corridor 90 represented by these potential trajectory boundaries, such as potential trajectory boundary 200y near outer limit 92. This could expose, or potentially expose, vehicle 10 to a collision with object 80. To avoid traveling outside of corridor 90, vehicle 10 would shorten trajectory path 200 to come to rest at line 95 earlier than intended. Object 80 could be any hazard or obstacle, stationary or moving, which includes people and animals.

Also, should CCU 179 via its associated second object detection system determine that corridor 90 is no longer valid because of detection of object 80, CCU 179 may instigate fallback emergency stop.

As previously described during normal travel when ADAS 150 and CCU 179 are in normal communication with each other, corridor 90 for a trajectory path 200 may be narrowed and allow bounds (limits) for CCU 179 to optimise the path of travel and provide improved comfort for a passenger vehicle application. In the case where vehicle 10 is employing a “complex motion”, which might be the reduction of lateral or longitudinal acceleration for improved ride and handling or might be for the allowance for “four-wheel steer”, corridor 90 may provide allowance for the rear of vehicle 10 to steer, and in doing so deviate outside of the track of the front wheels and allow for a tighter steering circle.

The advantages of the utilising CCU 179 in the present embodiment are as follows:

• The provision of feedback of instantaneous vehicle capability for “complete” trajectories.

• Able to assess that trajectories are “complete”, and therefore capable of being implemented dynamically by vehicle 10, allowing it to come to rest.

• Allows use of trajectories that share common points or simply form trajectories that when combined are dynamically viable.

• Adopt a new valid trajectory path after a “disruption event” has led to the start of a fail-safe exit.

• in normal operation CCU 179 may act to optimise the speed and position within a corridor of travel 90 provided by ADS 150, for example with minor deviation to allow for complex-motion; and

• in a disruption event CCU 179 may act to assess its maximum localisation error and maintain vehicle 10 within corridor of travel 90 and stop early to avoid excessive drift.

Whilst the abovementioned embodiment is described with reference to secondary navigation and second object detection systems associated with CCU 179 for the purposes of redundancy, in the broadest form of the invention, CCU 179 does not require inputs from such secondary systems to implement trajectory paths to completion without further input from ADAS 150 if communication between ADAS 150 and CCU 179 is lost.

ADAS 150 and CCU 179 may be remote from each other in separate housings, or they may be co-located in a single housing.

In the abovementioned embodiment, the “secondary controller” has been referred to as the Central Control Unit (CCU) 179, because it is the “central controller” of automation system 170, and it alone controls the vehicle drivetrain actuators via motor control unit(s) 172, steering module 173, brake module 174, and allows vehicle 10 to follow the trajectory path to completion without further input from the first controller (Trajectory Planner 159 as part of ADAS stack 150) if communication therebetween is lost. However, what should be understood is that in an alternative not shown embodiment, you could replace CCU 179 of automation system 170 with two or more non-centralised “secondary controllers”, and each of these secondary controllers may control different drive train actuators independent of each other. Like CCU 179 of the abovementioned embodiment, these independent secondary controllers may by acting on their respective drivetrain actuators allow vehicle 10 to follow the trajectory path to completion without further input from the first controller (Trajectory Planner 159 as part of ADAS stack 150) if communication between the secondary controllers and first controller is lost. Whilst for the purposes of this specification, autonomous vehicle 10 is fully- automated for the purposes of operation and being brought to rest by the fail-safe mode provided by a dualpurpose trajectory, vehicle 10 may have the ability for human override for various reasons.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

Claims

1. A control system for an autonomous vehicle comprising at least a first controller that periodically generates trajectory paths towards an intended travel goal of said vehicle on a continuous basis, wherein each of said trajectory paths terminates at rest, and at least one second controller in communication with said first controller, said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost.

2. A control system as claimed in claim 1, wherein during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest.

3. A control system as claimed in claim 2, wherein should said second controller identify that a newly generated trajectory path does not terminate at rest, said second controller will not continue motion of said vehicle beyond the previously generated trajectory path.

4. A control system as claimed in claim 2, wherein said second controller shares vehicle data at regular intervals with said first controller for the purposes of trajectory planning.

5. A control system as claimed in claim 4, wherein said vehicle data shared by said second controller with said first controller includes instantaneous acceleration, deceleration, and rotational limits.

6. A control system as claimed in claim 5, wherein each said trajectory path has a target speed communicated by said first controller for at least one point along the said traj ectory path, allowing said second controller to optimise the acceleration and deceleration to match the environment. A control system as claimed in claim 3, wherein said second controller assesses a newly generated trajectory path for validity based on instantaneous vehicle pose and vehicle handling characteristics. A control system as claimed in claims 1 or 2, wherein said secondary controller shares the localization data from a global navigation system associated with said first controller on a redundant communication bus separate from the trajectory planning of said first controller, so that said secondary controller can use said localization data from said global navigation system for path implementation, if communication with said first controller is disrupted or lost. A control system as claimed in claims 1 or 2, wherein a first global navigation system and a first object detection system are both in communication with said first controller. A control system as claimed in claim 9, wherein a second global navigation system is in communication with said second controller and said second global navigation system is independent from said first global navigation system. A control system as claimed in claim 9, wherein a second object detection system is in communication with said second controller and said second object detection system is independent from said first object detection system. A control system as claimed in claim 11, wherein each of said first object detection system and said second detection system may include any one or more lidars, radars and cameras. A control system as claimed in claims 1 or 2, wherein each trajectory path is made up of path data setting up a plurality of trajectory points and each sequentially generated trajectory path may share one or more common trajectory points from a previously generated trajectory path. A control system as claimed in claim 13, wherein each trajectory path is made up of path data setting up a plurality of trajectory points and an integral safe exit portion is a sub-set of said plurality of trajectory points at the furthest end thereof. A control system for an autonomous vehicle comprising at least a first controller and an associated first global navigation system, said first controller periodically generates dual-purpose trajectory paths towards an intended travel goal of said vehicle on a continuous basis, wherein each of said trajectory paths has a first segment for trajectory and a second segment for a planned exit trajectory that terminates at rest, and said vehicle further comprising at least one second controller and an associated second global navigation system, said second controller in communication with said first controller and said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost, and during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it, and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest via said planned exit trajectory. A control system as claimed in claim 15, wherein said secondary controller shares the first localization data from said first global navigation system redundant from the trajectory planning of said first controller, so that said secondary controller can either rely on first localization data from said first global navigation system or rely on the second localization data from said second global navigation system for path implementation, if communication with said first controller is disrupted or lost. A control system as claimed in claim 16, wherein said first controller provides a corridor of travel for said planned exit trajectory, such that during a disruption event where said first said controller fails to communicate an updated trajectory path and localization data is compromised, said second controller will shorten said planned exit of trajectory such that the calculated cumulative error in localization data does not exceed the outer limits of said corridor of travel.

18. A control system as claimed in claim 17, wherein said corridor of travel during normal travel is narrower than it is when said disruption event has occurred, such that during normal travel said second controller can optimise the implemented trajectory path with minor deviation to allow for complex-motion if available.

19. A control system as claimed in claim 17, wherein if said second controller via its associated second object detection system determines that said corridor of travel is no longer valid because of detection of an object, second controller instigates a fallback emergency stop. 0. A method for operating an autonomous vehicle, said method comprising: a first controller on said vehicle periodically generates trajectory paths towards an intended travel goal of said vehicle on a continuous basis, based on localization data received from an associated first global navigation system and sensed data from an associated first object detection system, wherein each of said trajectory paths terminates at rest; and at least one second controller in communication with said first controller, and said second controller controlling the drivetrain actuators of said vehicle to implement said trajectory paths to completion without further input from said first controller if communication between said first controller and said second controller is lost. 1. A method as claimed in claim 20, wherein during normal travel of said vehicle, each newly generated trajectory path replaces the trajectory path calculated immediately before it and should a disruption event disrupt the communication of said trajectory paths from said first controller to said second controller, and said second controller relies on the most recently generated trajectory path communicated to it until it is replaced by a new valid trajectory path generated by said first controller and communicated to it, or said vehicle comes to rest. 2. A method as claimed in claim 21, wherein should said second controller identify that a newly generated trajectory path does not terminate at rest, said second controller will not continue motion of said vehicle beyond the previously generated trajectory path.

23. A method as claimed in claim 21, wherein said second controller shares vehicle data at regular intervals with said first controller for the purposes of trajectory planning.

24. A method as claimed in claim 21, wherein said vehicle data shared by said second controller with said first controller includes instantaneous acceleration, deceleration, and rotational limits.

25. A method as claimed in claim 24, wherein each said trajectory path has a target speed communicated by said first controller for at least one point along the said trajectory path, allowing said second controller to optimise the acceleration and deceleration to match the environment.

26. A method as claimed in claim 22, wherein said second controller assesses a newly generated trajectory path for validity based on instantaneous vehicle pose and vehicle handling characteristics.

27. A method as claimed in claims 20 or 21, wherein said secondary controller shares the localization data from a global navigation system associated with said first controller on a redundant communication bus separate from the trajectory planning of said first controller, so that said secondary controller can use said location data from said global navigation system for path implementation, if communication with said first controller is disrupted or lost.

28. A method as claimed in claims 20 or 21, wherein a first global navigation system and a first object detection system are both in communication with said first controller.

29. A method as claimed in claim 28, wherein a second global navigation system is in communication with said second controller and said second global navigation system is independent from said first global navigation system.

30. A method as claimed in claim 28, wherein a second object detection system is in communication with said second controller and said second object detection system is independent from said first object detection system.

31. A method as claimed in claim 30, wherein each of said first object detection system and said second detection system may include any one or more lidars, radars and cameras.

32. A method as claimed in claims in 20 or 21, wherein each trajectory path is made up of path data setting up a plurality of trajectory points and each sequentially generated trajectory path may share one or more common trajectory points from a previously generated trajectory path.

33. A method as claimed in claim 32, wherein each trajectory path is made up of path data setting up a plurality of trajectory points and an integral safe exit portion is a sub-set of said plurality of trajectory points at the furthest end thereof.

34. A method as claimed in claim 27, wherein said first controller provides a corridor of travel for said planned exit trajectory, such that during a disruption event where said first controller fails to communicate an updated trajectory path and localization data is compromised, said second controller will shorten said planned exit of trajectory such that the calculated cumulative error in localization data does not exceed the outer limits of said corridor of travel.

35. A method as claimed in claim 34, wherein said corridor of travel during normal travel is narrower than it is when said disruption event has occurred, such that during normal travel said second controller can optimise the implemented trajectory path with minor deviation to allow for complex-motion if available.

36. A method as claimed in claim 34, wherein if said second controller via its associated second object detection system determines that said corridor of travel is no longer valid because of detection of an object, second controller instigates a fall-back emergency stop.