Active motion compute node takeback for autonomous vehicle fault recovery

Abstract

Techniques are discussed herein for restoring autonomous vehicle operations after one or more onboard computer systems have failed. An autonomous vehicle may comprise a primary compute node (PCN), an active motion compute node (MCN) and a backup MCN. In the event of a fault or failure at the active MCN, the backup MCN can take control of the autonomous vehicle, in an operation referred to herein as a "'backup MCN takeover."Subsequent "active MCN takeback" techniques can be applied to restore active MCN control of the autonomous vehicle, and to relinquish backup MCN control of the autonomous vehicle. If an active MCN takeback is successfully completed, the autonomous vehicle can return to an autonomous mission that was in place prior to the fault or failure at the active MCN.

Description

ACTIVE MOTION COMPUTE NODE TAKEBACK FOR AUTONOMOUS VEHICLE FAULT RECOVERYCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Application No. 18 / 991,215 filed on December 20, 2024 and entitled ‘ POSE INFORMATION CONTINUITY FOR AUTONOMOUS VEHICLE FAULT RECOVERY.” This application also claims priority to U.S. Application No. 19 / 419,706 filed on December 15, 2025 and entitled “ACTIVE MOTION COMPUTE NODE TAKEBACK FOR AUTONOMOUS VEHICLE FAULT RECOVERY.” Each of these applications are incorporated in their entirety herein by reference.BACKGROUND

[0002] Autonomous vehicle control systems may include multiple different computer systems. In the event of a fault or failure at one computer system, the other computer systems may remain available to perform at least limited autonomous vehicle control.

[0003] In some cases, a computer system that experienced a fault may be restored, and the restored computer system becomes available to resume its normal functions. In such scenarios, it is preferable to configure the autonomous vehicle to return to normal operation as quickly and smoothly as possible.

[0004] U.S. Pat. App. 18 / 991,215, filed Dec. 20, 2024, entitled “Pose Information Continuity For Autonomous Vehicle Fault Recovery,” is incorporated by reference herein and describes example techniques that may be used in connection with an autonomous vehicle return to normal operation.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] FIG. 1 is a pictorial diagram illustrating example vehicle control mode transitions of an autonomous vehicle which experiences a fault of one or more onboard computer systems, in accordance with one or more examples of the disclosure.

[0006] FIGS. 2A-2D illustrate example interconnected computer systems configured to cooperate to control an autonomous vehicle, an example fault and fault recovery experienced at one of the computer systems, and changes in communications in response to the fault and fault recovery, in accordance with one or more examples of the disclosure.

[0007] FIG. 3 illustrates example operations of an active motion control node (MCN), a backup MCN, and a primary compute node (PCN), to perform an active MCN takeback procedure in accordance with one or more examples of the disclosure.

[0008] FIG. 4 illustrates example computer systems configured to cooperate to control an autonomous vehicle, and components thereof involved in an active MCN takeback procedure, in accordance with one or more examples of the disclosure.

[0009] FIG. 5 depicts a block diagram of an example system including an autonomous vehicle, in accordance with one or more examples of the disclosure.

[0010] FIG. 6 is a flow diagram illustrating an example an active MCN takeback procedure, in accordance with one or more examples of the disclosure.DETAILED DESCRIPTION

[0011] This disclosure describes techniques for restoring autonomous vehicle operations after one or more onboard computer systems have failed. An autonomous vehicle may comprise multiple computer systems, including, e.g., at least one primary compute node (PCN) and at least two motion compute nodes (MCNs). The MCNs can include an active (or primary) MCN and a backup MCN.

[0012] In the event of a fault or failure at the active MCN, the backup MCN can take control of the autonomous vehicle, in an operation referred to herein as a “backup MCN takeover.’" After a backup MCN takeover, the backup MCN may be configured to bring the vehicle safely to a stop.

[0013] This disclosure is directed to “active MCN takeback” techniques that can be applied subsequent to a backup MCN takeover. The active MCN takeback techniques described herein can be used to restore active MCN control of the autonomous vehicle, and to relinquish backup MCN control of the autonomous vehicle. If an active MCN takeback is successfully completed, the autonomous vehicle can return to an autonomous mission that was in place prior to the fault or failure at the active MCN.Lee&Hayes^ 2 Attorney DocketNo. Z019-6340PCT

[0014] During a first “nominal’' mode, a controller associated with active MCN may have primary responsibility for executing a vehicle trajectory (e.g., a trajectory generated by the PCN) to move the vehicle through an environment. The active MCN can also include functionality to determine vehicle state information.

[0015] If the active MCN experiences a fault, the autonomous vehicle can enter a second “emergency’" or “safe’" mode. In the “safe"’ mode, the backup MCN assumes responsibility for executing a vehicle trajectory, e.g., a “safe” trajectory. The backup MCN can also include functionality to determine vehicle state information.

[0016] Generally, the backup MCN may be at least partially redundant of the active MCN. For instance, the backup MCN may be engaged when the active MCN is unavailable, untrustworthy, or the like, e.g.. because of a fault or other event. In one non-limiting example, in the event of a fault, the safe mode may be engaged in which the backup MCN may bring the vehicle to a stop.

[0017] While the vehicle is controlled in the safe mode, the active MCN may be restored to functionality and, once the restoration is successful, control of the vehicle may be “returned” to the active MCN, e.g., for continued operation in the normal mode. Aspects of this disclosure may be particularly directed to this restoration and return of functionality. A sequence of operations is described which can be employed to safely return the active MCN to control of vehicle systems such as brakes, propulsion, steering, and / or other systems.

[0018] In one example arrangement, an autonomous vehicle may have two PCNs as well as two MCNs. Each of these elements can optionally reside on a different computing device, and each can have a different role in autonomous vehicle control. Furthermore, the computing systems can be connected by a vehicle-based network, so the vehicles can communicate and cooperate to control the autonomous vehicle.

[0019] For example, a first PCN may be primarily equipped to perform prediction and planning functions, e.g., computing and selecting vehicle trajectories. A second PCN may be primarily equipped to perform perception functions, e.g., processing sensor inputs to build a representation of an environment surrounding the autonomous vehicle. The representation generated by the second PCN can be used by the first PCN in connection with its prediction and planning functions. Meanwhile, an example first (active) MCN can process selected trajectories produced by the first PCN and can translate the selected trajectories into control instructions for autonomous vehicleLee&Hayes^ 3 Attorney DocketNo. Z019-6340PCTsystems, such as steering and speed controls. An example second (backup) MCN can remain available in the event that the first MCN experiences a failure, allowing the autonomous vehicle to remain operable by the fully functioning first and second PCNs, even when the first MCN fails.

[0020] Autonomous vehicles can also optionally include a collision avoidance system (CAS) which is equipped to take over control of the vehicle in the event that an imminent collision or other imminent danger is detected. In such situations, the CAS may maneuver the vehicle in order to avoid the collision or other danger. The CAS may be implemented across one or more of the PCNs and MCNs.

[0021] Procedures described herein can implement an MCN takeback approach for a first, active MCN to take back control of an autonomous vehicle after a second, backup MCN takeover. The techniques described herein can optionally allow for MCN takeback without a full vehicle power cycle, if the active MCN is healthy enough to do so. The disclosed MCN takeback procedures can also optionally be initiated in part via remote control, e.g., by a teleoperator with a remote communication connection to an autonomous vehicle. One goal may be to continue an autonomous mission after a backup MCN takeover while a vehicle remains in service, without necessarily sending a recovery crew.

[0022] In some examples, after an autonomous vehicle executes a backup MCN takeover, which may include stopping the autonomous vehicle, e.g., in a stationary position in the middle of a lane, the autonomous vehicle may disengage from autonomous or “nominal” operation. To resume an autonomous mission after active MCN takeback, the autonomous vehicle may re-engage autonomous operation. After an active MCN takeback, the autonomous vehicle may be configured to attempt to resume a previous mission under autonomous operation. In the event that an active MCN takeback cannot successfully allow an autonomous vehicle to continue its mission in autonomous mode, the autonomous vehicle can be configured to enter a manual (human controlled), a teleoperated mode, or other control mode.

[0023] An example active MCN takeback procedure according to this disclosure can be performed after a backup MCN takeover in which the backup MCN takes control of the autonomous vehicle brings it to a safe stop. The backup MCN can be implemented via two different backup MCN components, referred to as backup MCN A and backup MCN B.Lee&Hayes^ 4 Attorney DocketNo. Z019-6340PCT

[0024] In an initial active MCN takeback operation, the backup MCN A can be configured to report it is ready for active MCN takeback, if it determines that the autonomous vehicle is in a state that is safe to do so. The backup MCN A can check a first set of conditions. The first set of conditions can include, e.g., one or more of a stationary' vehicle condition, a brake engaged condition, or a no crash detection condition.

[0025] In a subsequent active MCN takeback operation, the backup MCN B can be configured to receive backup MCN A reported ready for active MCN takeback status, and the backup MCN B can report the ready for active MCN takeback status it to the active MCN. The backup MCN B can thereby gateway or relay the backup MCN A’s ready for takeback status to the active MCN.

[0026] In another subsequent active MCN takeback operation, the active MCN can be configured to check a second set of conditions to evaluate if the active MCN is healthy enough to take back vehicle control from the backup MCN A. If all of the second set of conditions are met, the active MCN can perform a first action to enable communications between the active MCN and one or more electronic control units (ECU’s) onboard the autonomous vehicle. For example, the active MCN can unmute vehicle control area network (CAN) communications to gateway CAN messages from the active MCN to the backup MCNs and the ECUs.

[0027] The second set of conditions can comprise, e.g., one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

[0028] In another subsequent active MCN takeback operation, the backup MCN A can check a third set of conditions to evaluate if it is safe to handoff control to the active MCN. If all of the third set of conditions are met, the backup MCN A can transition to a state to handover the control of downstream ECUs back to the active MCN. The backup MCN A can be configured to perform a second action to enable communications between the active MCN and the ECUs. The second action can include, e.g., the backup MCN A stopping generating and sending its own commands to downstream ECUs. The second action can furthermore comprise the backup MCNLee&Hayes^ 5 Attorney DocketNo. Z019-6340PCTA muting its forwarding of CAN messages from the active MCN to the ECUs. After a predefined amount of time, the backup MCN A can transition to a standby state.

[0029] The third set of conditions can comprise, e.g., one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.

[0030] In another subsequent active MCN takeback operation, a vehicle steering system can be reset. The vehicle steering system can be reset automatically at the autonomous vehicle, or remotely, using an operation initiated by a teleoperator. Resetting the vehicle steering system can enable the active MCN to retake control of vehicle steering. In an example, a remote operator or automated vehicle system can be configured to request cycling a steering system to reset a multi-transceiver communication state.

[0031] In another subsequent and optionally final active MCN takeback operation, a remote operator can remotely attempt to reengage an autonomy system to autonomously control the vehicle to carry out a mission. If the autonomous vehicle is able to reengage the autonomy system, it can continue the mission, optionally with some constraints. If the attempt to reengage the autonomy system is unsuccessful, a physical recover}' of the autonomous vehicle may be performed. The remote operator can optionally check vehicle surroundings via vehicle cameras and other sensors to ensure the autonomous vehicle is in a safe environment from which to restart its autonomous mission.

[0032] The techniques described herein can be implemented in a number of ways. Examples are provided below with reference to the following figures. Although discussed in the context of an autonomous vehicle, the methods, apparatuses, and systems described herein can be applied to a variety of systems (e.g., a sensor system or a robotic platform), and are not limited to autonomous vehicles. In examples, similar techniques may be utilized in driver-controlled vehicles in which such a system may provide an indication of whether it is safe to perform various maneuvers.

[0033] FIG. 1 is a pictorial diagram illustrating example vehicle control mode transitions of an autonomous vehicle which experiences a fault of one or more onboard computer systems, in accordance with one or more examples of the disclosure. FIG. 1 illustrates an example environment 100 including a first lane 111, a second lane 112, a third lane 113. and a shoulder 114. An autonomous vehicle 101 is traveling in theLee&Hayes^ 6 Attorney DocketNo. Z019-6340PCTsecond lane 112, and the autonomous vehicle 101 has a trajectory 105. Other vehicles 121 and 122 are traveling in the first lane 111 and the third lane 113.

[0034] Prior to experiencing the fault, the autonomous vehicle 101 may be operating in a first mode 102, also referred to herein as a first vehicle control mode or a first operating mode. The first mode 102 can comprise a nominal or normal mode in which all computing systems onboard the autonomous vehicle 101 are substantially operational. In the first mode, vehicle control is implemented by the active MCN. The active MCN may generate first vehicle state information and supply the first vehicle state information for use by other systems, e.g., for use by a PCN (shown in FIGS. 2A- 2D).

[0035] As shown in FIG. 1, while the autonomous vehicle 101 is operating in the first mode 102, a fault is determined or detected at one or more of the computing systems. In an example according to this disclosure, the fault occurs at the active MCN.

[0036] In response to determining an occurrence of the fault, in the example of FIG. 1, a backup MCN takeover can occur within the autonomous vehicle 101. Pursuant to the backup MCN takeover, the autonomous vehicle 101 may enter a second mode 103, also referred to herein as an emergency or safe mode. In the second mode 103, vehicle control is implemented by the backup MCN (shown in FIGS. 2A-2D). The backup MCN can generate second vehicle state information and supply the second vehicle state information for use by other systems, e.g., for use by the PCN (shown in FIGS. 2A- 2D).

[0037] While in the second mode 103, the autonomous vehicle 101 can attempt to reset or restore operability of the failed or faulted computing system, e.g., operability of the active MCN. In an example, the autonomous vehicle 101 may be controlled by the backup MCN to maintain the current lane (lane 112) and bring the autonomous vehicle 101 to a stop therein. However, in some examples, the backup MCN may be configured to perform other emergency functions, such as maintaining lane and speed, or navigating to the shoulder 114 or an exit, or another safe stopping location, and bringing the autonomous vehicle 101 to a stop.

[0038] If the faulted computing system, e.g., the active MCN, is successfully restored while the autonomous vehicle 101 is in the second mode 103, then subsequent to controlling the autonomous vehicle 101 in the second mode 103, and optionally after the autonomous vehicle 101 is safely stopped, a resume 106 enables the autonomousLee&Hayes^ 7 Attorney DocketNo. Z019-6340PCTvehicle 101 to transition back into the first mode 102. The resume 106 may also be referred to herein as an active MCN takeback. After the resume 106. all of the computing systems onboard the autonomous vehicle 101 can return to normal, or at least limited normal functioning and the autonomous vehicle 101 can proceed under functioning autonomous control.

[0039] If the faulted computing system, e.g., the active MCN, is not successfully restored while the autonomous vehicle 101 is in the second mode 103, then other steps can optionally be taken, such as entering a teleoperation mode for remote operation by a teleoperator or calling a response team to repair and / or recover the autonomous vehicle 101.

[0040] FIGS. 2A-2D illustrate example interconnected computer systems configured to cooperate to control an autonomous vehicle, an example fault and fault recovery experienced at one of the computer systems, and changes in communications in response to the fault and fault recovery', in accordance w ith one or more examples of the disclosure. Each of FIGS. 2A-2D includes an example autonomous vehicle 200 equipped with a PCN 201, a PCN 202, a first, active MCN 203, and a second, backup MCN 204, all connected to a network 210. Also connected to the network 210 are example sensor(s) 205 and example vehicle controls 206.

[0041] In the illustrated example, the PCN 201 can be configured to include a first set of functions, e.g., perception functions, and the PCN 202 can be configured to include a second set of functions, e.g., prediction and planner functions. The sensor(s) 205 can comprise, e.g., vision sensors such as cameras and LIDAR sensors, as well as any other sensors. The sensor(s) 205 are connected to the network 210 and therefore sensor data can optionally be retrieved by any of the PCN 201, PCN 202. active MCN 203, or backup MCN 204. The vehicle controls 206 can comprise, e.g., a vehicle steering system and vehicle speed control systems such as braking and acceleration systems. The vehicle controls 206 may also be referred to herein as Electronic Control Units (ECUs). The vehicle controls 206 are connected to the network 210 and therefore can optionally be accessed by any of the PCN 201. PCN 202, first MCN 203, or second MCN 204.

[0042] In FIG. 2 A, PCN 201, PCN 202, active MCN 203, and backup MCN 204 are all substantially operable, no fault has been determined, and therefore the autonomous vehicle 200 can operate in the first, normal operating mode described yLLee&Hayes^ 8 Attorney DocketNo. Z019-6340PCTherein. In the first mode, sensor data from the sensor(s) 205 may be primarily consumed by the PCN 201 which comprises the perception functions in this example. The PCN 201 can provide environment information to the PCN 202 which comprises the prediction and planner functions in this example. The PCN 202 can generate trajectories, and PCN 202 can send generated trajectories to the active MCN 203 and / or the backup MCN 204. The active MCN 203 can control the autonomous vehicle 200 according to the generated trajectories by sending communications 211 comprising control inputs to the vehicle controls 206. The active MCN 203 can also send the communications 211 to the backup MCN 204, and the backup MCN 204 can gateway and resend the communications 211 to the vehicle controls 206 via a redundant communication channel. In the normal operating mode, the vehicle controls 206 can be configured to use the control inputs from communications 211 received from the active MCN 203.

[0043] FIG. 2B illustrates an example failure at the active MCN 203, represented by the gray shading of the active MCN 203. In FIG. 2B. a fault has been determined at the active MCN 203, however, the PCN 201, PCN 202, and backup MCN 204 remain substantially operable. In response to the fault, the autonomous vehicle 200 can engage a backup MCN 204 takeover in which the backup MCN 204 begins generating and supplying communications 212 to the vehicle controls 206, and the vehicle controls 206 switch from applying the control inputs in communications 211, as shown in FIG. 2A, to applying the control inputs from communications 212. The communications 212 from the backup MCN 204 can include commands for default, emergency autonomous vehicle 200, such as stopping the vehicle in-lane. Alternatively, the communications 212 from the backup MCN 204 can include commands based on emergency trajectories output from the PCN 202.

[0044] The active MCN 203 can optionally begin restoration / reset / re-initialization operations immediately after the fault, or the active MCN 203 can optionally wait for a predetermined interval prior to attempting reset. In some embodiments, the active MCN 203 can wait until the autonomous vehicle 200 has stopped prior to attempting reset.

[0045] In FIG. 2C, autonomous vehicle 200 is engaged in an active MCN takeback procedure, whereby active MCN 203 control of the vehicle controls 206 can be restored. In accordance with the active MCN takeback procedure, the backup MCN 204 can be configured to report via network 210 that it is ready for active MCN takeback, if theLee&Hayes^ Attorney DocketNo. Z019-6340PCTbackup MCN 204 determines that the autonomous vehicle 200 is in a state that is safe to do so. The backup MCN 204 can check a first set of conditions. The first set of conditions can include, e.g., one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition.

[0046] In some implementations, a separate component referred to herein as backup MCN B (not shown in FIGS. 2A-2D) can be configured to enable reporting by the backup MCN 204. The backup MCN B can report the status of the backup MCN 204 is ready for active MCN takeback.

[0047] After the backup MCN 204 has reported via network 210 that it is ready for active MCN takeback, the active MCN 203 can be configured to check a second set of conditions to evaluate if the active MCN 203 is healthy enough to take back vehicle control from the backup MCN 204. If one or more conditions of the second set of conditions are met, the active MCN 203 can perform a first action to enable the communications 211 between the active MCN 203 and one or more ECUs in the vehicle controls 206. For example, the active MCN 203 can unmute vehicle control area network (CAN) communications to gateway CAN messages from the active MCN 203 to the ECUs. The active MCN 203 can optionally report via network 210 that the active MCN 203 is ready for active MCN takeback.

[0048] The second set of conditions can comprise, e.g., one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

[0049] After the active MCN 203 has reported via network 210 that it is ready for active MCN takeback, or otherwise completed its takeback operations, the backup MCN 204 can check a third set of conditions to evaluate if it is safe to handoff control to the active MCN 203. If one or more conditions of the third set of conditions are met, the backup MCN 204 can transition to a state to handover the control of vehicle controls 206 back to the active MCN 203. The backup MCN 204 can be configured to perform a second action to enable communications 211 between the active MCN 203 and one or more ECUs of the vehicle controls 206. The second action can include, e.g., the backup MCN 204 stopping generating and sending its own communications 212 (see FIG. 2B) including commands to downstream ECUs in the vehicle controls 206. TheLee&Hayes^ 10 Attorney DocketNo. Z019-6340PCTsecond action can furthermore comprise the backup MCN 204 muting its forwarding of communications 211, e.g., muting forwarding of CAN messages from the active MCN 203 to the ECUs. After a predefined amount of time, the backup MCN 204 can transition to a standby state.

[0050] The third set of conditions can comprise, e.g., one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.

[0051] In FIG. 2D, the active MCN 203 control of the vehicle controls 206 has been restored. The active MCN 203 can again control the autonomous vehicle 200 according to generated trajectories by sending communications 211 comprising control inputs to the vehicle controls 206. The backup MCN 204 can also gateway and forward communication 211 to the vehicle controls 206 via a redundant channel. The vehicle controls 206 can be configured to use the control inputs from communications 211 received from the active MCN 203, while not using the control inputs from communications 211 forwarded from the backup MCN 204. Therefore, the active MCN 203 has control of most ECUs in vehicle controls 206, however, one or more additional systems, e.g., a steering system and an autonomy system, may require reset or reengagement in order to restore autonomous vehicle operations.

[0052] The instructions 213 and 214 can optionally be received from a remote operator via a wireless network. The instructions 213 and 214 can be received at any device in the autonomous vehicle 200. FIG. 2D illustrates the instructions 213 and 214 being received at the PCN 202. In another example, the instructions 213 and 214 can be received for example at a telematic control unit or other device, and optionally forwarded to other devices such as the PCN 202 or the MCN 203.

[0053] An instruction 213 can comprise a reset steering instruction from a remote operator. The instruction 213 can reset a vehicle steering system included among the vehicle controls 206. The reset may for example power cycle the vehicle steering system or alter a communication setting to enable the vehicle steering system to receive commands included in the communications 211. In an alternative implementation, the vehicle steering system can be reset automatically at the autonomous vehicle 200. In an example, a remote operator or automated vehicle system can be configured to request cycling of a steering system to reset a multi-transceiver communication state.

[0054] In some embodiments, resetting a vehicle steering system can compriseLee&Hayes^ 11 Attorney DocketNo. Z019-6340PCTcycling a vehicle’s ignition switched pow er supply, e.g., a Klemme 15 (KL15) ty pe power supply. The instruction 213 can for example comprise an instruction for the MCN 203 to cycle KL15, in order to reset an Electric Power- Assisted Steering (EP AS) to a multi-transceiver communication state. KL15 becomes active when an ignition is switched to the "ON" or accessory' position and can power many vehicle components such as the radio, dashboard, fuel pump, and / or wipers.

[0055] An instruction 214 can comprise a reengage autonomy instruction from a remote operator. The instruction 214 can be configured to reengage an autonomy system of the autonomous vehicle 200 to carry' out a mission. The autonomy system can be implemented at least in part at the PCN 201. If the autonomous vehicle 200 is able to reengage the autonomy system, it can continue the mission with active MCN 203 control of the vehicle controls 206, optionally with some vehicle operating constraints. If the attempt to reengage the autonomy' system is unsuccessful, a physical recovery' of the autonomous vehicle 200 may be performed. Prior to providing the instruction 214, the remote operator can optionally check vehicle surroundings via sensors 205 such as vehicle cameras to ensure the autonomous vehicle 200 is in a safe environment from which to restart its autonomous mission.

[0056] FIG. 3 illustrates example operations of an active motion control node (MCN) 310, a backup MCN 320, and a primary compute node (PCN) 330, to perform an active MCN takeback procedure in accordance with one or more examples of the disclosure. In FIG. 3, time is represented by the dotted arrows extending downward from the active MCN 310, backup MCN 320, and PCN 330. FIG. 3 therefore illustrates an example timing / sequence of operations performed by the active MCN 310, backup MCN 320, and PCN 330.

[0057] The operations illustrated in FIG. 3 include operations representing an initial fault 311 at the active MCN 310, a responsive takeover 321 by the backup MCN 320, a fault response 331 at the PCN 330. The fault 311, takeover 321, and fault response 331 can occur substantially simultaneously, although the takeover 321 and fault response 331 are in response to the fault 311 and therefore are initiated after, albeit immediately after, the fault 311. The fault 311, takeover 321, and fault response 331 are operations that can be referred to collectively as a backup MCN takeover.

[0058] The fault 311 can comprise any fault or failure that causes the active MCN 310 to relinquish control over vehicle controls, such as the vehicle controls 206 yLLee&Hayes12Attorney DocketNo. Z019-6340PCTillustrated in FIGS. 2A, 2B, 2C, and 2D, and ECUs included in the vehicle controls 206. In response to the fault 311. the backup MCN 320 assumes ECU control pursuant to the takeover 321. The backup MCN 320 can optionally control the vehicle according to predetermined emergency trajectories. Alternatively, the PCN 330 may generate an emergency trajectory' pursuant to its fault response 331, and the backup MCN 320 can optionally control the vehicle according to the emergency trajectory generated at the PCN 330. In an example, the backup MCN 320 can bring the vehicle to a stop, either in-lane, or at another location such as a roadway shoulder or a safe stopping location.

[0059] Subsequent to the backup MCN takeover, the active MCN 310 may initiate a restore 312. The restore 312 can comprise any of a variety' of operations designed to return the active MCN 310 to a normal, healthy state in which the fault 311 is cleared and the active MCN 310 is prepared to re-assume control of the vehicle. The restore 312 can optionally comprise a power cycling of the active MCN 310, or a reset of one or more settings, components, or data used by the active MCN 310. The restore 312 can be initiated immediately after the fault 311, or at a later time, e.g., after the vehicle is stopped pursuant to the backup MCN takeover.

[0060] Active MCN takeback operations can begin after the backup MCN takeover, and optionally after the backup MCN 320 has brought the vehicle to a stop. Active MCN takeback operations can optionally begin during the restore 312, or after the restore 312 is completed. In FIG. 3, the active MCN takeback operations begin with check first set of conditions 322, performed at the backup MCN 320.

[0061] Check first set of conditions 322 can comprise, generally, checking conditions indicating that the vehicle is in a safe state for active MCN takeback. The first set of conditions can include, e.g., one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition. These are example first conditions, and any conditions can be added or removed from the first set of conditions in some implementations.

[0062] The stationary' vehicle condition can comprise, e.g., the vehicle is stopped and not moving. The brake engaged condition can comprise, e.g., that one or more parking brakes of the vehicle are engaged or clamped. The no crash detection condition can comprise, e.g., that the vehicle has not experienced a crash or collision with another object, as may be detected by vehicle sensors. Some vehicles may differentiate betweenLee&Hayes^ 13 Attorney DocketNo. Z019-6340PCTdifferent types / severities of crashes, and the no crash detection condition can apply to any or all crash types.

[0063] In some implementations, the backup MCN 320 can report to a vehicle network that the backup MCN 320 is ready for active MCN takeback, only if all conditions in the first set of conditions are met. In other implementations, the backup MCN 320 can distinguish between essential and nonessential conditions, or the backup MCN 320 can optionally determine whether at least a threshold number of the first conditions are met. In some implementations, the backup MCN 320 can comprise at least two entities, one of which can check the first set of conditions, and the other of which can gateway or relay the backup MCN 320's ready for takeback status to the vehicle network.

[0064] Subsequent to the backup MCN 320 reporting that the first set of conditions are met, the active MCN 310 can be configured to check a second set of conditions 313. Check second set of conditions 322 can comprise, generally, checking conditions indicating that the active MCN 310 is healthy enough to take back vehicle control from the backup MCN 320.

[0065] The second set of conditions can include, e.g., one or more of a no fault condition, a stationary vehicle condition, an active MCN control of ECUs condition, an active MCN control of brake condition, an active MCN in parked state condition, or a backup MCN ready for active MCN takeback condition. These are example second conditions, and any conditions can be added or removed from the second set of conditions in some implementations.

[0066] The no fault condition can comprise, e.g., ensuring that one or more components of the active MCN 310. or other vehicle components, have not reported a fault. In particular, the no fault condition can comprise checking whether the fault 311 is resolved. The stationary vehicle condition can comprise, e.g., the vehicle is stopped and not moving. The active MCN control of ECUs condition can comprise, e.g., that active MCN 310 has a connection to the vehicle’s ECUs and ability to control the ECUs. The active MCN control of brake condition can comprise, e.g.. that active MCN 310 has a connection to the vehicle’s brakes, whether parking brakes or other brakes, and ability to control the brakes. The active MCN in parked state condition can comprise, e.g., that active MCN 310 is maintaining a parked, non-moving state. The backup MCN ready for active MCN takeback condition can comprise, e g., a yLLee&Hayes14Attorney DocketNo. Z019-6340PCTconfirmation that the backup MCN 320 has reported it is ready for active MCN takeback.

[0067] In some implementations, the active MCN 310 can report to a vehicle network that the active MCN 310 is ready for active MCN takeback, only if all conditions in the second set of conditions are met. In other implementations, the active MCN 310 can distinguish between essential and nonessential conditions, or the active MCN 310 can optionally determine whether at least a threshold number of the second conditions are met.

[0068] If the second set of conditions are met pursuant to check second set of conditions 313, then the active MCN 310 can perform a first action to restore active MCN 310 communications with ECUs 314. An example first action is unmuting the active MCN 310’s CAN communications, to enable CAN message transmission from the active MCN 310 to the ECUs and other vehicle components such as the backup MCN 320. The active MCN 310 can report to a vehicle network that the first action is complete, or the backup MCN 320 can be configured to detect that the first action is complete.

[0069] Subsequent to the active MCN 310 reporting that the second set of conditions are met, and the first action is complete, the backup MCN 320 can be configured to check a third set of conditions 323. Check third set of conditions 323 can comprise, generally, checking conditions indicating that it is safe to handoff control to the active MCN. The third set of conditions can include, e.g., one or more of a backup MCN ready for active MCN takeback condition, an active communication condition, or an active MCN control condition. These are example third conditions, and any conditions can be added or removed from the third set of conditions in some implementations.

[0070] The backup MCN ready for active MCN takeback condition can comprise, e.g., the backup MCN 320 has previously reported that it is ready for active MCN takeback. The active communication condition can comprise, e.g., that communications from the active MCN 310 have been unmuted. The active MCN control condition can comprise, e.g., that the active MCN 310 has reported it is ready for vehicle control.

[0071] In some implementations, the backup MCN 320 can report to a vehicle network that the third set of conditions are satisfied, only if all conditions in the third set of conditions are satisfied. In other implementations, the backup MCN 320 canLee&Hayes^ 15 Attorney DocketNo. Z019-6340PCTdistinguish between essential and nonessential conditions, or the backup MCN 320 can optionally determine whether at least a threshold number of the third conditions are met.

[0072] If the third set of conditions are met pursuant to check third set of conditions323, then the backup MCN 320 can perform a second action to restore active MCN communications with ECUs 324. An example second action is the backup MCN 320 muting its own communications or stopping generating and sending its own commands to downstream ECUs. The second action can furthermore comprise the backup MCN 320 muting its forwarding of CAN messages from the active MCN 310 to the ECUs. The ECUs can be configured to switch from backup MCN 320 control to active MCN 310 control in response to muting of communications from the backup MCN 320 while communications from the active MCN 310 are unmuted. The backup MCN 310 can optionally report to a vehicle network that the second action is complete.

[0073] After the second action to restore active MCN communications with ECUs324, the active MCN 310 has resumed control over most vehicle ECUs. However, some vehicle controls, e.g., a vehicle steering system, may require a separate reset operation to restore control by the active MCN 310. The PCN 330, or another onboard computer system, can therefore optionally perform reset steering for active MCN control 332. Reset steering for active MCN control 332 represents a reset of a vehicle steering system, or any other vehicle controls configured for separate reset operations, as needed.

[0074] In some examples, after the backup MCN 310 reports to a vehicle network that the second action is complete, the PCN 330 can be configured automatically reset steering for active MCN control 332. In other examples, a remote operator with a wireless communication link to the vehicle may initiate the reset steering for active MCN control 332. A reset can be performed in a variety of ways, depending on vehicle architecture. One example approach includes cycling an ignition-linked power supply to reset an electric power steering system’s multi-transceiver communication state.

[0075] Upon completion of the reset steering for active MCN control 332, the activeMCN 310 has been restored to control of vehicle movement, and the active MCN takeback procedure can be considered complete. However, the vehicle’s autonomy system has not been reset. Some active MCN takeback procedures according to this disclosure can be considered to include an autonomy system reset, while other activeLee&Hayes^ 16 Attorney DocketNo. Z019-6340PCTMCN takeback procedures can omit autonomy system reset, and the autonomy system reset can instead be considered a separate operation performed after completion of active MCN takeback.

[0076] At reengage autonomy system; resume mission 333, the PCN 330 or another onboard computer can receive a remote operator instruction to reengage an autonomy system. The remote operator can optionally provide the instruction after checking vehicle surroundings via vehicle cameras and other sensors to ensure the vehicle is in a safe environment from which to restart its autonomous mission. The PCN 330 can reengage the autonomy system in response to the instruction. The reengaged autonomy system can be configured to resume a mission that was in place prior to the fault 311. The mission may optionally be resumed with some constraints, e.g., ano new passenger constraint which prevents the vehicle from picking up new / additional passengers. If the autonomy system cannot be reengaged, a physical recovery of the vehicle may be performed.

[0077] FIG. 4 illustrates example computer systems configured to cooperate to control an autonomous vehicle, and components thereof involved in an active MCN takeback procedure, in accordance with one or more examples of the disclosure. FIG. 4 includes a PCN 410, a PCN 420, an active MCN 430, a backup MCN 440, sensor(s) 450, and vehicle controls 460 and a network 470. The illustrated PCN 410, PCN 420, active MCN 430, backup MCN 440, sensor(s) 450, and vehicle controls 460 can each provide functions to support autonomous vehicle operations and can communicate via the network 470. The illustrated example computer systems can implement the PCN 201, PCN 202, MCN 203, and MCN 204, vehicle controls 206, and sensors 205 introduced in FIGS. 2A-2D, in some embodiments.

[0078] In the example illustrated in FIG. 4, PCN 410 can implement perception functions, and the PCN 420 can implement a main artificial intelligence (Al). The PCN 420 can comprise a takeback manager 422, a remote operator interface 424, and an autonomy system 426. The active MCN 430 can comprise a takeback manager 432, a condition checker 434. and communication restoration 436. The backup MCN 440 can comprise a takeback manager 442, a condition checker 444, and communication restoration 446. The vehicle controls 460 can comprise an ECU 462, an ECU 464, and a steering system 466. yL-Lee&Hayes17Attorney DocketNo. Z019-6340PCT

[0079] In an example according to FIG. 4. following a backup MCN takeover, the takeback manager 422. takeback manager 432, and takeback manager 442 can manage operations at the PCN 420, active MCN 430, and backup MCN 440 to conduct an active MCN takeback. First the takeback manager 442 at the backup MCN 440 can apply the condition checker 444 to check a first set of conditions as described herein, and the takeback manager 442 can report via network 470 whether the backup MCN 440 is ready for active MCN takeback. Next, the takeback manager 432 at the active MCN 430 can apply the condition checker 434 to check a second set of conditions as described herein, and report via network 470 whether the active MCN 430 is ready for active MCN takeback.

[0080] Next, the takeback manager 432 at the active MCN 430 can apply the communication restoration 436 to perform a first action to restore communications between the active MCN 430 and one or more ECUs, e.g., ECU 462 and ECU 464, as described herein. If the first action succeeds in restoring communications, the takeback manager 432 can optionally report via network 470 that the active MCN 430 is successfully publishing ECU control communications.

[0081] Next, the takeback manager 442 at the backup MCN 440 can apply the condition checker 434 to check a third set of conditions as described herein, and the takeback manager 442 can report via network 470 whether the backup MCN 440 is ready for active MCN takeback. The takeback manager 442 at the backup MCN 440 can apply the communication restoration 446 to perform a second action to restore communications between the active MCN 430 and one or more ECUs, e.g., ECU 462 and ECU 464, as described herein. If the second action succeeds in restoring communications, the takeback manager 442 can optionally report via network 470 that the active MCN 430 is successfully publishing ECU control communications and that the ECU 462 and ECU 464 are now listening / applying control communications published by the active MCN 430.

[0082] The takeback manager 422 at the PCN 420 can respond to successful active MCN takeback of ECU 462 and ECU 464 by optionally notifying a remote operator that the vehicle is ready for a reset of the steering system 466. The remote operator interface 424 can receive a remote operator instruction to reset the steering system 466, and the remote operator interface 424 can optionally publish or carry out the instruction in order to reset the steering system 466, in order to return the steering system 466 toLee&Hayes^ 18 Attorney DocketNo. Z019-6340PCTcontrol by the active MCN 430. Alternatively, the takeback manager 422, the takeback manager 432, or the takeback manager 442 can automatically reset the steering system 466.

[0083] The takeback manager 422 at the PCN 420 can respond to successful active MCN takeback of ECU 462, ECU 464, and steering system 466 by optionally notifying a remote operator that the vehicle is ready for a reengagement of the autonomy system 426. The remote operator interface 424 can receive a remote operator instruction to reengage the autonomy system 426, and the remote operator interface 424 can optionally publish or carry out the instruction in order to reengage the autonomy system 426, in order to return the autonomy system 426 to a mission, or to engage the autonomy system 426 on a new mission.

[0084] FIG. 5 depicts a block diagram of an example system including an autonomous vehicle, in accordance with one or more examples of the disclosure. The system 500 can include the vehicle 502, which can correspond to an autonomous or semi-autonomous vehicle configured to perform various techniques described herein. As shown in this example, vehicle 502 may include components configured to perform an active MCN takeback in response to a backup MCN takeover.

[0085] The example vehicle 502 can be a driverless vehicle, such as an autonomous vehicle configured to operate according to a Level 5 classification issued by the U.S. National Highway Traffic Safety Administration, which describes a vehicle capable of performing all safety-critical functions for the entire trip, with the driver (or occupant) not being expected to control the vehicle at any time. In such examples, because the vehicle 502 can be configured to control all functions from start to completion of atrip, including all parking functions, it may or may not include a driver and / or controls for driving the vehicle 502, such as a steering wheel, an acceleration pedal, and / or a brake pedal. This is merely an example, and the systems and methods described herein may be incorporated into any ground-borne, airborne, or waterborne vehicle, including those ranging from vehicles that need to be manually controlled by a driver at all times, to those that are partially or fully autonomously controlled.

[0086] The vehicle 502 may include vehicle computing devices 504 A, 504B, 504C, and 504D, one or more sensor systems 506, one or more emitters 508, one or more communication connections 510, at least one direct connection 512, and one or more drive systems 514. yLLee&Hayes19Attorney DocketNo. Z019-6340PCT

[0087] The vehicle computing devices 504A-D can implement the computing devices described in connection with FIGS. 1-4 in some examples. For example, the vehicle computing devices 504A-D can comprise, e.g., a first PCN such as PCN 201 illustrated in FIGS. 2A-2D, a second PCN such as PCN 202 illustrated in FIGS. 2A- 2D, a first or active MCN such as MCN 203 illustrated in FIGS. 2A-2D, and a second or backup MCN such as MCN 204 illustrated in FIGS. 2A-2D. Each of the vehicle computing devices 504A-D can include one or more processors and a memory communicatively coupled with the one or more processors. For example, computing device 504A comprises one or more processors 516 and memory 520 communicatively coupled with the one or more processors 516. In the illustrated example, the vehicle 502 is an autonomous vehicle; however, the vehicle 502 could be any other type of vehicle or robotic platform.

[0088] In the illustrated example, the memory 520 of the vehicle computing device 504A can store various functions such as a localization component 521, a prediction component 522, system controllers 523, a perception component 524, a planning component 525, and one or more maps 526. These functions and others may combine to implement an autonomy system configured to autonomously control the vehicle on a mission. Some of the example functions 521-526 can be implemented on, e.g., the vehicle computing device 504A while others of the example functions 521-526 can be implemented on. e.g., another of the vehicle computing devices 504B-D. The vehicle computing device 504A can furthermore comprise, e.g., fail operational features 530, including atakeback managers 531, condition checkers 532, communication restoration 533, and remote operator interface 534. The takeback managers 531, condition checkers 532, communication restoration 533. and remote operator interface 534 can implement, e.g., the takeback managers 422, 432, 442 illustrated in FIG. 4. The condition checkers 532 can implement, e.g., the condition checkers 434, 444 illustrated in FIG. 4. The communication restoration 533 can implement, e.g., the communication restoration 436, 446 illustrated in FIG. 4. The remote operator interface 534 can implement, e.g., the remote operator interface 424 illustrated in FIG. 4.

[0089] Though depicted in FIG. 5 as residing in the memory 520 for illustrative purposes, one or more of the localization component 521, prediction component 522, system controllers 523, perception component 524, planning component 525, maps 526, and fail operational features 530 can additionally, or alternatively, be accessible to yLLee&Hayes20Attorney DocketNo. Z019-6340PCTthe vehicle 502 (e.g., stored on, or otherwise accessible by, memory remote from the vehicle 502).

[0090] As shown in this example, the vehicle 502 also may also include a vehicle safety system 535, such as a collision avoidance system. The vehicle safety system 535 may be configured to generate, validate, and select an output trajectory' for the vehicle 502. For instance, the vehicle safety system 535 may include a trajectory manager, which may include one or more trajectory generator(s), one or more trajectory validator(s), and / or a trajectory selector. The vehicle safety system 535 can be implemented separately from the fail operational features 530 disclosed herein.

[0091] By way of example, the vehicle computing device 504A may be considered to be a primary system, while the fail operational features 530 and the vehicle safety system 535 may be considered to be secondary systems. The primary system may generally7perform processing to control how the vehicle maneuvers within an environment. The primary7system within the vehicle computing device 504A may implement various artificial intelligence (Al) techniques, such as machine learning, to understand an environment around the vehicle 502 and / or instruct the vehicle 502 to move within the environment. The various components of the primary system, such as the localization component 521, prediction component 522, perception component 524, and planning component 525 may implement Al techniques to localize the vehicle, detect objects around the vehicle, segment sensor data, determine classifications of the objects, predict object tracks, generate trajectories for the vehicle 502 and the objects around the vehicle, and so on. In some examples, the primary system may process data from multiple types of sensors on the vehicle, such as light detection and ranging (lidar) sensors, radar sensors, image sensors, depth sensors (time of flight, structured light, etc.), cameras, and the like, within the sensor systems 506.

[0092] The fail operational features 530 and vehicle safety' system 535 in this example may operate as separate systems that receive state data (e.g., perception data) based on the sensor data and Al techniques implemented by the primary system (e.g., vehicle computing device 504A), and may perform various techniques described herein for improving vehicle safety and operation, such as managing an active MCN takeback procedure. The fail operational features 530 and vehicle safety' system 535 may implement techniques for determining predicted trajectories and predicting intersect! ons / collisions based on the predicted trajectories, as well as probabilistic yLee&Hayes21Attorney DocketNo. Z019-6340PCTtechniques that are based on positioning, velocity, acceleration, etc. of the vehicle and / or objects around the vehicle.

[0093] In some examples, the fail operational features 530 and vehicle safety system 535 may process data from sensors, such as a subset of sensor data that is processed by the primary system. To illustrate, the primary’ system may process lidar data, radar data, image data, depth data, etc., while the fail operational features 530 and vehicle safety system 535 may process just lidar data and / or radar data (and / or time of flight data). In other examples, however, the fail operational features 530 and vehicle safety' system 535 may process sensor data from any number of sensors, such as data from each of the sensors, data from the same number of sensors as the primary system, etc.

[0094] Although depicted in FIG. 5 as residing in the memory 520 for illustrative purposes, it is contemplated that the localization component 521, prediction component 522, system controllers 523, perception component 524, planning component 525, maps 526, and fail operational features 530 may additionally, or alternatively, be accessible to the vehicle 502 (e.g., stored on, or otherwise accessible by, memory remote from the vehicle 502, such as, for example, on memory 548 of a remote computing device 544).

[0095] In at least one example, the localization component 521 may include functionality to receive data from the sensor system(s) 506 to determine a position and / or orientation of the vehicle 502 e.g., one or more of an x-, y-, z-position, roll, pitch, or yaw). For example, the localization component 521 may include and / or request / receive a map of an environment and may continuously determine a location and / or orientation of the autonomous vehicle within the map. In some instances, the localization component 521 may utilize SLAM (simultaneous localization and mapping), CLAMS (calibration, localization and mapping, simultaneously), relative SLAM, bundle adjustment, non-linear least squares optimization, or the like to receive image data. LIDAR data, radar data, IMU data, GPS data, wheel encoder data, and the like to accurately determine a location of the autonomous vehicle. In some instances, the localization component 521 may provide data to various components of the vehicle 502 to determine an initial position and / or trajectory of the vehicle 502, as discussed herein. yLee&Hayes22Attorney DocketNo. Z019-6340PCT

[0096] In some instances, and in general, the perception component 524 can include functionality to perform object detection, segmentation, and / or classification. In some examples, the perception component 524 can provide processed sensor data that indicates a presence of an entity that is proximate to the vehicle 502 and / or a classification of the entity as an entity type (e.g., car, pedestrian, cyclist, animal, building, tree, road surface, curb, sidewalk, stoplight, stop sign, unknown, etc.).

[0097] In additional or alternative examples, the perception component 524 can provide processed sensor data that indicates one or more characteristics associated with a detected entity (e.g., a tracked object) and / or the environment in which the entity is positioned. In some examples, characteristics associated with an entity can include, but are not limited to. an x-position (global and / or local position), a y-position (global and / or local position), a z-position (global and / or local position), an orientation (e.g., a roll, pitch, yaw), an entity type (e.g., a classification), a velocity of the entity, an acceleration of the entity, an extent of the entity (size), etc. Characteristics associated with the environment can include, but are not limited to, a presence of another entity in the environment, a state of another entity in the environment, a time of day, a day of a week, a season, a weather condition, an indication of darkness / light, etc.

[0098] In general, the prediction component 522 can include functionality to generate predicted information associated with objects in an environment. As an example, the prediction component 522 can be implemented to predict locations of a pedestrian proximate to a crosswalk region (or otherwise a region or location associated with a pedestrian crossing a road) in an environment as they traverse or prepare to traverse through the crossw alk region.

[0099] As another example, the techniques discussed herein can be implemented to predict locations of other objects (e.g., vehicles, bicycles, pedestrians, and the like) as the vehicle 502 traverses an environment. In some examples, the prediction component 522 can generate one or more predicted positions, predicted velocities, predicted trajectories, etc., for such target objects based on attributes of the target object and / or other objects proximate the target object.

[0100] In general, the planning component 525 can determine a path for the vehicle 502 to follow^ to traverse the environment. The planning component 525 can include functionality to determine various routes and trajectories and various levels of detail. For example, the planning component 525 can determine a route to travel from a firstLee&Hayes23Attorney DocketNo. Z019-6340PCTlocation (e.g., a current location) to a second location (e.g., a target location). For the purpose of this discussion, a route can be a sequence of waypoints for travelling between two locations. As non-limiting examples, waypoints include streets, intersections, global positioning system (GPS) coordinates, etc.

[0101] Further, the planning component 525 can generate an instruction for guiding the autonomous vehicle along at least a portion of the route from the first location to the second location. In at least one example, the planning component 525 can determine how to guide the autonomous vehicle from a first waypoint in the sequence of waypoints to a second waypoint in the sequence of waypoints. In some examples, the instruction can be a trajectory', or a portion of a trajectory. In some examples, multiple trajectories can be substantially simultaneously generated (e.g., within technical tolerances) in accordance with a receding horizon technique, wherein one of the multiple trajectories is selected for the vehicle 502 to navigate.

[0102] In some instances, the planning component 525 can generate one or more trajectories for the vehicle 502 based at least in part on predicted location(s) associated with object(s) in an environment. In some examples, the planning component 525 can use temporal logic, such as linear temporal logic and / or signal temporal logic, to evaluate one or more trajectories of the vehicle 502.

[0103] In at least one example, the vehicle computing device 504A can include one or more system controllers 523, which can be configured to control steering, propulsion, braking, safety, emitters, communication, and other systems of the vehicle 502. These system controller(s) 523 can communicate with and / or control corresponding systems of the drive system(s) 514 and / or other components of the vehicle 502. The controllers 523 illustrated in FIG. 5 correspond to the vehicle controls 206 illustrated in FIGS. 2A- 2D.

[0104] For example, the planning component 525 may generate instructions based at least in part on perception data generated by the perception component 524 and transmit the instructions to the system controller(s) 523, which may control operation of the vehicle 502 based at least in part on the instructions. In some examples, if the planning component 525 receives a notification that a track of an obj ect was ’lost” (e.g. , an object no longer appears in perception data and isn’t occluded by any other objects), the planning component 525 may generate an instruction to bring the vehicle 502 to a safe stop and / or to transmit a request for teleoperator assistance. yLee&Hayes24Attorney DocketNo. Z019-6340PCT

[0105] The memory' 520 can further include one or more maps 526 that can be used by the vehicle 502 to navigate within the environment. For the purpose of this disclosure, a map can be any number of data structures modeled in two dimensions, three dimensions, or N-dimensions that are capable of including information about an environment, such as, but not limited to, topologies (such as intersections), streets, mountain ranges, roads, terrain, and the environment in general.

[0106] In some instances, a map can include, but is not limited to: texture information (e.g., color information (e.g., RGB color information. Lab color information, HSV / HSL color information), and the like), intensity' information (e.g., lidar information, radar information, and the like); spatial information (e.g., vectorized information regarding features of an environment, image data projected onto a mesh, individual ‘"surfels” (e.g., polygons associated with individual color and / or intensity)), reflectivity^ information (e.g., specularity' information, retroreflectivity information, BRDF information, BSSRDF information, and the like). In one example, a map can include a three dimensional mesh of the environment. In some instances, the map can be stored in a tiled format, such that individual tiles of the map represent a discrete portion of an environment and can be loaded into working memory as needed. In at least one example, the one or more maps 526 can include at least one map (e.g., images and / or a mesh).

[0107] In some examples, the vehicle 502 can be controlled based at least in part on the maps 526. That is, the maps 526 can be used in connection with the localization component 521, the perception component 524, the prediction component 522, and / or the planning component 525 to determine a location of the vehicle 502, identify objects in an environment, and / or generate routes and / or trajectories to navigate within an environment. In some examples, the one or more maps 526 can be stored on a remote computing device(s), such as within the memory 548 of the computing device(s) 544 and may be accessible to the vehicle 502 via network(s) 542. In some examples, multiple maps 526 can be retrieved from the memory 548, and stored based on, for example, a characteristic (e.g.. type of entity, time of day, day of week, season of the year, etc.). Storing multiple maps 526 can have similar memory requirements but can increase the speed at which data in a map can be accessed.

[0108] In at least one example, the fail operational features 530 can comprise a fault determination component configured to determine, by a first vehicle computing device yLee&Hayes25Attorney DocketNo. Z019-6340PCT504A, whether a fault has occurred at another of the vehicle computing devices 504B- D. Several technical approaches can be used to implement the fault determination component .

[0109] In an example technical approach, the fault determination component can be configured to monitor fault logs generated by vehicle computing devices 504B-D. The vehicle computing devices 504A-D can be configured to log any fault conditions that occur, including for example fault types, fault times, and affected systems. The fault determination component can monitor such logs continuously or periodically, and when a fault of one or more predetermined fault types occurs, the fault determination component can initiate a vehicle control mode switching component, e.g., to switch computer systems into an emergency operation mode.

[0110] In another example technical approach, the fault determination component can be configured to monitor heartbeat signals output from other vehicle computing devices 504B-D. If a computing device stops producing its heartbeat signal as expected, then the fault determination component can be configured to responsively initiate the vehicle control mode switching component.

[0111] As can be understood, the components discussed herein (e.g., localization component 521, prediction component 522, system controllers 523, perception component 524, planning component 525, maps 526, and fail operational features 530) are described as divided for illustrative purposes. However, the operations performed by the various components can be combined or performed in any other component. Further, any of the components discussed as being implemented in software can be implemented in hardware, and vice versa. Further, any functionality implemented in the vehicle 502 can be implemented in the computing device(s) 544, or another component (and vice versa).

[0112] The sensor system(s) 506 correspond to the sensor(s) 205 illustrated in FIGS. 2A-2D. In at least one example, the sensor system(s) 506 can include time of flight sensors, lidar sensors, radar devices and / or radar sensors, ultrasonic transducers, sonar sensors, location sensors (e.g.. GPS. compass, etc.), inertial sensors (e.g., inertial measurement units (IMUs), accelerometers, magnetometers, gyroscopes, etc.), cameras (e.g., RGB, IR, intensity, depth, etc.), microphones, wheel encoders, environment sensors (e.g., temperature sensors, humidity' sensors, light sensors, pressure sensors, etc.), etc.Lee&Hayes^ 26 Attorney DocketNo. Z019-6340PCT

[0113] The sensor system(s) 506 can include multiple instances of each of these or other types of sensors. For instance, the time-of-flight sensors can include individual time of flight sensors located at the comers, front, back, sides, and / or top of the vehicle 502. As another example, the camera sensors can include multiple cameras disposed at various locations about the exterior and / or interior of the vehicle 502.

[0114] The sensor system(s) 506 can provide input to the vehicle computing devices 504A-D. Additionally or alternatively, the sensor system(s) 506 can send sensor data, via the one or more networks 542, to the one or more computing device(s) 544 at a particular frequency, after a lapse of a predetermined period of time, in near real-time, etc.

[0115] The vehicle 502 can also include one or more emitters 508 for emitting light and / or sound, as described above. The emitters 508 in this example include interior audio and visual emitters to communicate with passengers of the vehicle 502. By way of example and not limitation, interior emitters can include speakers, lights, signs, display screens, touch screens, haptic emitters (e.g., vibration and / or force feedback), mechanical actuators (e.g., seatbelt tensioners, seat positioners, headrest positioners, etc.), and the like.

[0116] The emitters 508 in this example also include exterior emitters. By way of example and not limitation, the exterior emitters in this example include lights to signal a direction of travel or other indicator of vehicle action (e.g., indicator lights, signs, light arrays, etc.), and one or more audio emitters (e.g., speakers, speaker arrays, horns, etc.) to audibly communicate with pedestrians or other nearby vehicles, one or more of which comprising acoustic beam steering technology7.

[0117] The vehicle 502 can also include one or more communication connection(s) 510 that enable communication between the vehicle 502 and one or more other local or remote computing device(s). For instance, the communication connection(s) 510 can facilitate communication with other local computing device(s) on the vehicle 502 and / or the drive system(s) 514. Also, the communication connect! on(s) 510 can allow the vehicle to communicate with other nearby computing device(s) (e.g., other nearby vehicles, traffic signals, etc.). The communications connection(s) 510 also enable the vehicle 502 to communicate with a remote teleoperation computing device or other remote services.Lee&Hayes27Attorney DocketNo. Z019-6340PCT

[0118] The communications connection(s) 510 can include physical and / or logical interfaces for connecting the vehicle computing devices 504A-D to another computing device or a network, such as network(s) 542. For example, the communications connection(s) 510 can enable Wi-Fi-based communication such as via frequencies defined by the IEEE 802.11 standards, short range wireless frequencies such as Bluetooth®, cellular communication (e.g., 2G, 3G, 4G. 4G LTE, 5G, etc.) or any suitable wired or wireless communications protocol that enables the respective computing device to interface with the other computing device(s).

[0119] In at least one example, the vehicle 502 can include one or more drive systems 514. The vehicle 502 can have a single drive system 514, or multiple drive systems 514. In at least one example, if the vehicle 502 has multiple drive systems 514, individual drive systems 514 can be positioned on opposite ends of the vehicle 502 (e.g., the front and the rear, etc.).

[0120] In at least one example, the drive system(s) 514 can include one or more sensor systems to detect conditions of the drive system(s) 514 and / or the surroundings of the vehicle 502. By way of example and not limitation, the sensor system(s) can include one or more wheel encoders (e.g., rotary encoders) to sense rotation of the wheels of the drive modules, inertial sensors (e.g., inertial measurement units, accelerometers, gyroscopes, magnetometers, etc.) to measure orientation and acceleration of the drive module, cameras or other image sensors, ultrasonic sensors to acoustically detect objects in the surroundings of the drive system, lidar sensors, radar sensors, etc. Some sensors, such as the wheel encoders can be unique to the drive system(s) 514. In some cases, the sensor system(s) on the drive system(s) 514 can overlap or supplement corresponding systems of the vehicle 502 (e.g., sensor system(s) 506).

[0121] The drive system(s) 514 can include many of the vehicle systems, including a high voltage battery', a motor to propel the vehicle, an inverter to convert direct current from the battery into alternating current for use by other vehicle systems, a steering system including a steering motor and steering rack (which can be electric), a braking system including hydraulic or electric actuators, a suspension system including hydraulic and / or pneumatic components, a stability7control system for distributing brake forces to mitigate loss of traction and maintain control, an HVAC system, lighting (e.g., lighting such as head / tail lights to illuminate an exterior surrounding of the yLLee&Hayes28Attorney DocketNo. Z019-6340PCTvehicle), and one or more other systems (e.g., cooling system, safety systems, onboard charging system, other electrical components such as a DC / DC converter, a high voltage junction, a high voltage cable, charging system, charge port, etc.).

[0122] Additionally, the drive system(s) 514 can include a drive system controller which can receive and preprocess data from the sensor system(s) and to control operation of the various vehicle systems. In some examples, the drive system controller can include one or more processors and memory communicatively coupled with the one or more processors. The memory can store one or more components to perform various functionalities of the drive system(s) 514. Furthermore, the drive system(s) 514 also include one or more communication connection(s) that enable communication by the respective drive system with one or more other local or remote computing device(s).

[0123] In at least one example, the direct connection 512 can provide a physical interface to couple the one or more drive system(s) 514 with the body of the vehicle 502. For example, the direct connection 512 can allow the transfer of energy, fluids, air, data, etc. between the drive system(s) 514 and the vehicle 502. In some instances, the direct connection 512 can further releasably secure the drive system(s) 514 to the body of the vehicle 502.

[0124] In at least one example, the localization component 521, the perception component 524, the prediction component 522, the planning component 525, the system controllers 523, and the maps 526, can process sensor data, as described above, and can send their respective outputs, over the one or more network(s) 542, to one or more computing device(s) 544. In at least one example, the respective outputs of the components can be transmitted to the one or more computing device(s) 544 at a particular frequency, after a lapse of a predetermined period of time, in near realtime, etc.

[0125] Additionally, or alternatively, the vehicle 502 can send sensor data to one or more computing device(s) 544 via the network(s) 542, including raw7sensor data, processed sensor data and / or representations of sensor data. Such sensor data can be sent as one or more log files to the computing device(s) 544 at a particular frequency, after a lapse of a predetermined period of time, in near real-time, etc.

[0126] The computing device(s) 544 can include processor(s) 546 and a memory 548 storing a state machine repository7550. In some examples, a state machine repository 550 may store one or more state transition models that can be generated and yLee&Hayes29Attorney DocketNo. Z019-6340PCTmodified offline and provided to various vehicles 502 in a fleet. Different state transition models may be provided to different models of vehicles 502, and / or based on the location or operating conditions of the vehicles 502.

[0127] In various examples, the computing devices 544 may implement one or more machine learning systems or heuristics-based systems to train, test, and optimize different state transition models for different vehicles 502 operating within different environments. Additionally, any of the features or functionalities described in connection with the vehicle fail operational features 530 may be performed by computing devices 544.

[0128] The processor(s) 516 of the vehicle 502 and the processor(s) 546 of the computing device(s) 544 can be any suitable processor capable of executing instructions to process data and perform operations as described herein. By way of example and not limitation, the processor(s) 516 and 546 can comprise one or more Central Processing Units (CPUs), Graphics Processing Units (GPUs), or any other device or portion of a device that processes electronic data to transform that electronic data into other electronic data that can be stored in registers and / or memory. In some examples, integrated circuits (e.g., ASICs, etc ), gate arrays (e.g., FPGAs, etc ), and other hardware devices can also be considered processors in so far as they are configured to implement encoded instructions.

[0129] Memory 520 and 548 are examples of non-transitory computer-readable media. The memory 520 and 548 can store an operating system and one or more software applications, instructions, programs, and / or data to implement the methods described herein and the functions attributed to the various systems. In various examples, the memory can be implemented using any suitable memory’ technology, such as static random-access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile / Flash-type memory, or any other type of memory capable of storing information. The architectures, systems, and individual elements described herein can include many other logical, programmatic, and physical components, of which those shown in the accompanying figures are merely examples that are related to the discussion herein.

[0130] It should be noted that while FIG. 5 is illustrated as a distributed system, in alternative examples, components of the vehicle 502 can be associated with the computing device(s) 544 and / or components of the computing device(s) 544 can beLee&Hayes^ 30 Attorney DocketNo. Z019-6340PCTassociated with the vehicle 502. That is, the vehicle 502 can perform one or more of the functions associated with the computing device(s) 544, and vice versa.

[0131] FIG. 6 is a flow diagram illustrating an example an active MCN takeback procedure, in accordance with one or more examples of the disclosure. As described below, the process 600 may be performed by one or more computer-based components configured to implement various functionalities described herein.

[0132] The process 600 is illustrated as collections of blocks in a logical flow diagram, representing sequences of operations, some or all of which can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, encryption, deciphering, compressing, recording, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and / or in parallel to implement the processes, or alternative processes, and not all of the blocks need to be executed in all examples. For discussion purposes, the processes herein are described in reference to the frameworks, architectures and environments described in the examples herein, although the processes may be implemented in a wide variety of other frameworks, architectures, or environments.

[0133] At operation 602, a backup MCN, e.g., the backup MCN 440 illustrated in FIG. 4, can determine that it is ready for active MCN takeback. Operation 602 can comprise checking, by the backup MCN 440, a first set of conditions to determine that the backup MCN 440 is ready for the active MCN takeback. The first set of conditions can comprise, e.g., one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition. If the first set of conditions are met, the backup MCN 440 can publish its ready for active MCN takeback status to the network 470.

[0134] At operation 604, an active MCN, e.g., the active MCN 430 illustrated in FIG. 4, can determine that it is ready for active MCN takeback. Operation 604 can comprise checking, by the active MCN 430, a second set of conditions to determine that the active MCN is ready for the active MCN takeback. The second set of conditionsLee&Hayes^ 31 Attorney DocketNo. Z019-6340PCTcan comprise, e.g., one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition. If the second set of conditions are met, the active MCN 430 can publish its ready for active MCN takeback status to the network 470.

[0135] At operation 606. in response to the second set of conditions being satisfied at operation 604 the active MCN 430 can take a first action to resume active MCN communication / control of ECUs. For example, the active MCN can take a first action to enable communications between the active MCN and one or more ECUs onboard the vehicle. The first action can comprise, e.g., an unmuting action whereby communications from the active MCN are unmuted. The active MCN 430 can optionally publish its resumed communication status to the network 470.

[0136] At operation 608, the backup MCN 440 can perform a control handover safety check. Operation 608 can comprise checking, by the backup MCN 440. a third set of conditions. The third set of conditions can comprise, e.g., one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition. If the third set of conditions are met, the backup MCN 440 can publish a comprehensive ready for active MCN takeback status to the network 470.

[0137] At operation 610, in response to the third set of conditions being satisfied at operation 608, the backup MCN 440 can take a second action to resume active MCN communication / control of ECUs. The second action can comprise, e.g., a release or muting of backup MCN 440 communication / control of ECUs. For example, the backup MCN 440 can perform a second action to enable the communications between the active MCN 430 and the one or more ECUs. The second action can comprise, e.g., a muting action whereby communications from the backup MCN 440 are muted.

[0138] At operation 612, any vehicle computing system, e.g., the PCN 420, can reset a steering system to enable active MCN 430 communication / control thereof. For example, the PCN 420 can automatically reset a vehicle steering system to enable the active MCN takeback. Alternatively, the PCN 420 can receive and carry out a remote operator instruction to reset a vehicle steering system to enable the active MCNLee&Hayes32Attorney DocketNo. Z019-6340PCTtakeback. The reset may comprise a power cycling or a reset of a steering system component or communication interface.

[0139] At operation 614, subsequent to the active MCN takeback of control over all vehicle controls 460, any vehicle computing system, e.g., the PCN 420, can reengage an autonomy system 426 to autonomously control the vehicle to carry' out a mission. In some embodiments, the PCN 420 can receive and carry out a remote operator instruction to reengage the autonomy system.EXAMPLE CLAUSES

[0140] A. A vehicle comprising: a first computer subsystem comprising an active motion compute node configured to control the vehicle; and a second computer subsystem comprising a backup motion compute node configured to control the vehicle; wherein the first and second computer subsystems comprise one or more processors and one or more computer-readable media storing computer-executable instructions; and wherein the instructions, when executed, cause the first and second computer subsystems to perform active motion compute node takeback operations subsequent to a backup motion compute node takeover in which the backup motion compute node takes control of the vehicle from the active motion compute node, the active motion compute node takeback operations comprising: checking, by the backup motion compute node, a first set of conditions, and in response to the first set of conditions being satisfied, reporting, by the backup motion compute node, that the backup motion compute node is ready for the active motion compute node takeback; checking, by the active motion compute node, a second set of conditions, and in response to the second set of conditions being satisfied, performing, by the active motion compute node, a first action to enable communications between the active motion compute node and one or more electronic control units onboard the vehicle, wherein the communications enable the active motion compute node takeback; and checking, by the backup motion compute node, a third set of conditions, and in response to the third set of conditions being satisfied, performing, by the backup motion compute node, a second action to enable the communications between the active motion compute node and the one or more electronic control units. yLLee&Hayes^ 33 Attorney DocketNo. Z019-6340PCT

[0141] B. The vehicle of paragraph A, wherein the first action to enable the communications between the active motion compute node and the one or more electronic control units comprises an unmuting action whereby communications from the active motion compute node are unmuted, and wherein the second action to enable the communications between the active motion compute node and the one or more electronic control units comprises a muting action whereby communications from the backup motion compute node are muted.

[0142] C. The vehicle of paragraph A, further comprising a vehicle steering system, wherein the vehicle steering system is resettable to enable the active motion compute node takeback, and wherein the vehicle steering system is resettable by one or more of a remote operator reset operation, or an automated operation included in the active motion compute node takeback operations.

[0143] D. The vehicle of paragraph A, further comprising an autonomy system comprising one or more computer subsystems configured to autonomously control the vehicle to carry out a mission, and wherein, in response to completion of the active motion compute node takeback operations, the autonomy system is configured to be reengaged to enable the vehicle to continue the mission.

[0144] E. A method comprising for performing an active motion compute node takeback of a vehicle, subsequent to a backup motion compute node takeover of the vehicle in which a backup motion compute node takes control of the vehicle from an active motion compute node, the method comprising: checking, by the backup motion compute node, a first set of conditions to determine that the backup motion compute node is ready for the active motion compute node takeback; checking, by the active motion compute node, a second set of conditions to determine that the active motion compute node is ready for the active motion compute node takeback; in response to the second set of conditions being satisfied, performing, by the active motion compute node, a first action to enable communications betw een the active motion compute node and one or more electronic control units onboard the vehicle: and checking, by the backup motion compute node, a third set of conditions, and in response to the third set of conditions being satisfied, performing, by the backup motion compute node, a second action to enable the communications between the active motion compute node and the one or more electronic control units.Lee&Hayes34Attorney DocketNo. Z019-6340PCT

[0145] F. The method of paragraph E, wherein the first set of conditions comprises one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition.

[0146] G. The method of paragraph E, wherein the second set of conditions comprises one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

[0147] H. The method of paragraph E, wherein the third set of conditions comprises one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.

[0148] I. The method of paragraph E, wherein the first action comprises an unmuting action whereby communications from the active motion compute node are unmuted.

[0149] J. The method of paragraph E, wherein the second action comprises a muting action whereby communications from the backup motion compute node are muted.

[0150] K. The method of paragraph E, further comprising resetting a vehicle steering system to enable the active motion compute node takeback.

[0151] L. The method of paragraph E, further comprising, subsequent to the active motion compute node takeback, reengaging an autonomy system to autonomously control the vehicle to carry out a mission.

[0152] M. One or more non-transitory computer-readable media storing instructions executable by a processor, wherein the instructions, when executed, cause the processor to perform operations for an active motion compute node takeback of a vehicle, subsequent to a backup motion compute node takeover of the vehicle in which a backup motion compute node takes control of the vehicle from an active motion compute node, the operations comprising: checking a first set of conditions to determine that the backup motion compute node is ready for the active motion compute node takeback; checking a second set of conditions to determine that the active motion compute node is ready for the active motion compute node takeback; in response to theLee&Hayes^ 35 Attorney DocketNo. Z019-6340PCTsecond set of conditions being satisfied, performing a first action to enable communications between the active motion compute node and one or more electronic control units onboard the vehicle; and checking a third set of conditions, and in response to the third set of conditions being satisfied, performing a second action to enable the communications between the active motion compute node and the one or more electronic control units.

[0153] N. The one or more non-transitory computer-readable media of paragraph M, wherein the first set of conditions comprises one or more of a stationary vehicle condition, a brake engaged condition, or ano crash detection condition.

[0154] O. The one or more non-transitory computer-readable media of paragraph M, wherein the second set of conditions comprises one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

[0155] P. The one or more non-transitory computer-readable media of paragraph M, wherein the third set of conditions comprises one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.

[0156] Q. The one or more non-transitory computer-readable media of paragraph M, wherein the first action comprises an unmuting action whereby communications from the active motion compute node are unmuted.

[0157] R. The one or more non-transitory computer-readable media of paragraph M, wherein the second action comprises a muting action whereby communications from the backup motion compute node are muted.

[0158] S. The one or more non-transitory computer-readable media of paragraph M, wherein the operations further comprise resetting a vehicle steering system to enable the active motion compute node takeback.

[0159] T. The one or more non-transitory computer-readable media of paragraph M, wherein the operations further comprise, subsequent to the active motion compute node takeback, reengaging an autonomy system to autonomously control the vehicle to carry out a mission.Lee&Hayes^ 36 Attorney DocketNo. Z019-6340PCT

[0160] While the example clauses described above are described with respect to particular examples, it should be understood that, in the context of this document, the content of the example clauses can be implemented via a method, device, system, a computer-readable medium, and / or another example. Additionally, any of examples A-T may be implemented alone or in combination with any other one or more of the examples A-T.CONCLUSION

[0161] While one or more examples of the techniques described herein have been described, various alterations, additions, permutations, and equivalents thereof are included within the scope of the techniques described herein.

[0162] In the description of examples, reference is made to the accompanying drawings that form a part hereof, which show by way of illustration specific examples of the claimed subject matter. It is to be understood that other examples may be used and that changes or alterations, such as structural changes, may be made. Such examples, changes or alterations are not necessarily departures from the scope with respect to the intended claimed subject matter. While the steps herein may be presented in a certain order, in some cases the ordering may be changed so that certain inputs are provided at different times or in a different order without changing the function of the systems and methods described. The disclosed procedures could also be executed in different orders. Additionally, various computations that are herein need not be performed in the order disclosed, and other examples using alternative orderings of the computations could be readily implemented. In addition to being reordered, the computations could also be decomposed into sub-computations with the same results.

[0163] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

[0164] The components described herein represent instructions that may be stored in any type of computer-readable medium and may be implemented in software and / or hardware. All of the methods and processes described above may be embodied in, and fully automated via, software code modules and / or computer-executable instructions yLee&Hayes37Attorney DocketNo. Z019-6340PCTexecuted by one or more computers or processors, hardware, or some combination thereof. Some or all of the methods may alternatively be embodied in specialized computer hardware.

[0165] Conditional language such as, among others, ‘'may,” “could,” “may” or “might,” unless specifically stated otherwise, are understood within the context to present that certain examples include, while other examples do not include, certain features, elements and / or steps. Thus, such conditional language is not generally intended to imply that certain features, elements and / or steps are in any way required for one or more examples or that one or more examples necessarily include logic for deciding, with or without user input or prompting, whether certain features, elements and / or steps are included or are to be performed in any particular example.

[0166] Conjunctive language such as the phrase “at least one of X, Y or Z,” unless specifically stated otherwise, is to be understood to present that an item, term, etc. may be either X, Y, or Z, or any combination thereof, including multiples of each element. Unless explicitly described as singular, “a” means singular and plural.

[0167] Any routine descriptions, elements or blocks in the flow diagrams described herein and / or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code that include one or more computerexecutable instructions for implementing specific logical functions or elements in the routine. Alternate examples are included within the scope of the examples described herein in which elements or functions may be deleted, or executed out of order from that shown or discussed, including substantially synchronously, in reverse order, with additional operations, or omitting operations, depending on the functionality involved as would be understood by those skilled in the art.

[0168] Many variations and modifications may be made to the above-described examples, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.Lee&Hayes^ 38 Attorney DocketNo. Z019-6340PCT

Claims

CLAIMSWHAT IS CLAIMED IS:

1. A vehicle comprising: a first computer subsystem comprising an active motion compute node configured to control the vehicle; and a second computer subsystem comprising a backup motion compute node configured to control the vehicle; wherein the first and second computer subsystems comprise one or more processors and one or more computer-readable media storing computer-executable instructions; and wherein the instructions, when executed, cause the first and second computer subsystems to perform active motion compute node takeback operations subsequent to a backup motion compute node takeover in which the backup motion compute node takes control of the vehicle from the active motion compute node, the active motion compute node takeback operations comprising: checking a first set of conditions to determine that the backup motion compute node is ready for the active motion compute node takeback; checking a second set of conditions to determine that the active motion compute node is ready for the active motion compute node takeback; performing a first action at the active motion compute node to enable communications between the active motion compute node and one or more electronic control units onboard the vehicle; and performing a second action the backup motion compute node to enable the communications between the active motion compute node and the one or more electronic control units.

2. The vehicle of claim 1 , wherein the first set of conditions comprises one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition.Attorney DocketNo. Z019-6340PCT3. The vehicle of any one of claims 1-2, wherein the second set of conditions comprises one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

4. The vehicle of any one of claims 1 -3, wherein the operations further comprise checking a third set of conditions, and wherein the third set of conditions comprises one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.

5. The vehicle of any one of claims 1-4, wherein the first action comprises an unmuting action whereby communications from the active motion compute node are unmuted.

6. The vehicle of any one of claims 1 -5, wherein the second action comprises a muting action whereby communications from the backup motion compute node are muted.

7. The vehicle of any one of claims 1-6, wherein the operations further comprise resetting a vehicle steering system to enable the active motion compute node takeback.

8. The vehicle of any one of claims 1-7, wherein the operations further comprise, subsequent to the active motion compute node takeback, reengaging an autonomy system to autonomously control the vehicle to carry out a mission.

9. A method for performing an active motion compute node takeback of a vehicle, subsequent to a backup motion compute node takeover of the vehicle in which a backup motion compute node takes control of the vehicle from an active motion compute node, the method comprising: yLee&Hayes40Attorney DocketNo. Z019-6340PCTchecking, by the backup motion compute node, a first set of conditions to determine that the backup motion compute node is ready for the active motion compute node takeback; checking, by the active motion compute node, a second set of conditions to determine that the active motion compute node is ready for the active motion compute node takeback; in response to the second set of conditions being satisfied, performing, by the active motion compute node, a first action to enable communications between the active motion compute node and one or more electronic control units onboard the vehicle; and checking, by the backup motion compute node, a third set of conditions, and in response to the third set of conditions being satisfied, performing, by the backup motion compute node, a second action to enable the communications between the active motion compute node and the one or more electronic control units.

10. The method of claim 9, wherein the first set of conditions comprises one or more of a stationary vehicle condition, a brake engaged condition, or a no crash detection condition.

11. The method of any one of claims 9-10. wherein the second set of conditions comprises one or more of a no fault condition, a stationary vehicle condition, an active motion compute node control of electronic drive unit condition, an active motion compute node control of brake condition, an active motion compute node in parked state condition, or a backup motion compute node ready for active motion compute node takeback condition.

12. The method of any one of claims 9-11, wherein the third set of conditions comprises one or more of a backup motion compute node ready for active motion compute node takeback condition, an active communication condition, or an active motion compute node control condition.Lee&Hayes^ 41 Attorney DocketNo. Z019-6340PCT13. The method of any one of claims 9-12, wherein the first action comprises an unmuting action whereby communications from the active motion compute node are unmuted.

14. The method of any one of claims 9-13, wherein the second action comprises a muting action whereby communications from the backup motion compute node are muted.

15. One or more non-transitory computer-readable media storing instructions executable by one or more processors, wherein the instructions, when executed, cause the one or more processors to perform operations of the methods recited in any one of claims 9-14.Lee&Hayes^ 42 Attorney DocketNo. Z019-6340PCT

Images