Patent Application
20250229782
The present disclosure generally relates to autonomous racing vehicles and related systems.
Autonomous racing is an aspect of self-driving car technology. In racing environments, autonomous cars typically maneuver at relatively high speeds compared to autonomous passenger cars used on public roads. Further, the overtaking of one vehicle by another presents inherent risks. Racing with human drivers employs safety rules for overtaking, such as the “one move” rule in Formula One, which limits the number of defensive maneuvers a leading car can take to block an overtaking car. Even with such rules, experienced human drivers still make unsafe maneuvers during overtaking resulting in collisions or assessment of penalties. The problems of safe overtaking are also present for autonomous vehicles. In high-speed environments with autonomous vehicles, current artificial intelligence (AI) hardware and software struggle to comply in a timely manner with imposed constraints, such as safety margin, non-collision, speed, stability, and controllability. Improved ways to manage overtaking safely are needed.
Safety and performance is enhanced by an orchestration platform that controls overtaking by autonomous vehicles under conditions where optimal speed is important, such as racing conditions, qualifications, or performance testing.
The orchestration platform can be implemented as a system for managing overtaking by autonomous vehicles that includes a control unit comprising a computing device with a processor and a wireless transmitter and receiver for communication with autonomous vehicles. A course is identified for the autonomous vehicles with predetermined zones along its path. The zones include an execution zone and a decision-making zone, typically designed before a change in course geometry, such as a curve or turn. In another embodiment, a change in course geometry reflecting a decision-making zone can be a curve such as a steady turn followed by a straight section. In still other embodiments, an execution zone and a decision-making zone can be implemented in the same or similar course geometry (e.g. a long straightaway). The decision-making zone precedes the execution zone on the course. The control unit's computing device receives and analyzes proposed overtaking trajectories and counter-trajectories from the autonomous vehicles while they are in the decision-making zone. When the control unit receives a proposed overtaking trajectory from a trailing autonomous vehicle, the control unit requests a proposed defensive counter-trajectory from the first autonomous vehicle.
In some embodiments, the proposed defensive counter-trajectory includes a path through the execution zone and a curve or turn that accounts for the proposed overtaking trajectory by the attacking autonomous vehicle. In alternative embodiments, the defensive counter trajectory is proposed as a normal, optimal line without knowing the proposed overtaking trajectory.
The control-unit computing device compares a proposed overtaking trajectory with a proposed defensive counter-trajectory. A proposed overtaking trajectory is rejected if the proposed counter-trajectory allows the leading autonomous vehicle to remain ahead of the trailing autonomous vehicle throughout the execution zone. An overtaking trajectory is approved if the proposed overtaking trajectory allows the trailing autonomous vehicle to pass safely in the execution zone.
In some embodiments, the control unit is located on or near the course and separate from the first and second autonomous vehicles. The control unit may also be distributed between the first and second autonomous vehicles and the course.
In some embodiments, the number of n autonomous vehicles is 3 or more.
In some embodiments, a decision zone is identified for the n autonomous vehicles dynamically after they enter the decision zone. In some embodiments, a decision zone is predefined, static, and shared with n autonomous vehicles before they enter the decision zone, or before a race begins. A combination of dynamic and static decision zones are used in some embodiments.
The orchestration platform can also be implemented as a method for controlling overtaking by a leading first autonomous vehicle and trailing second autonomous vehicles on a course comprising a curve using a control unit including a processor, a nonvolatile storage medium, and a wireless transmitter and receiver for communication with the first and second autonomous vehicles.
A predetermined execution zone and a predetermined decision zone on the course located before the curve are identified for the autonomous vehicles. The decision-making zone is proximate and before the execution zone. The curve is proximate and after the execution zone. A first sensor detects entry of the autonomous vehicles into a decision zone. The control unit sends a wireless request for a proposed overtaking trajectory to the trailing second autonomous vehicle. The control unit also sends a wireless request for a proposed defensive trajectory to the leading first autonomous vehicle.
If the second autonomous vehicle intends to overtake the first autonomous vehicle, the control unit will receive a proposed overtaking trajectory from the second autonomous vehicle. In an embodiment, the control unit also receives a proposed defensive trajectory from the first autonomous vehicle. The control unit compares the proposed overtaking trajectory with predetermined minimum requirements for the autonomous vehicles during an overtaking and wirelessly sends an approval of the proposed overtaking trajectory to the second autonomous vehicle if the predetermined minimum requirements are satisfied.
The control unit also compares the proposed defensive trajectory with predetermined minimum requirements and wirelessly sends an approval of the proposed defensive trajectory to the first autonomous vehicle if the predetermined minimum requirements are satisfied. A rejection of the proposed defensive trajectory will be sent if the proposed defensive trajectory does not meet predetermined minimum requirements. In cases where both proposed trajectories are approved, the control unit confirms trajectories for the first and second autonomous vehicles.
In an embodiment, the predetermined requirements for overtaking include a minimum velocity advantage for the second autonomous vehicle with respect to the first autonomous vehicle. The predetermined requirements for overtaking can include a minimum safe distance between the first and second autonomous vehicles.
In an embodiment, a second request for a proposed defensive trajectory is sent to the first autonomous vehicle while the first autonomous vehicle remains in the decision zone if a proposed defensive trajectory is not received at the control unit from the first autonomous vehicle.
In an embodiment, the control unit requests and receives an alternative safety trajectory from the first autonomous vehicle after the first autonomous vehicle enters the decision zone. The control unit can approve the alternative safety trajectory by sending confirmation to the first autonomous vehicle.
In an embodiment, a second sensor is used to detect the actual path of the first autonomous vehicle and compare the actual path with the proposed defensive trajectory. The control unit can also record the variance between the proposed defensive trajectory and the actual path of the first autonomous vehicle.
The orchestration platform can also be implemented by a method for controlling overtaking by first and second autonomous vehicles on a course, where the first and second autonomous vehicles have a control unit including a processor, a nonvolatile storage medium, and a wireless transmitter and receiver for communications between the control units of the first and second autonomous vehicles.
The second autonomous vehicle detects its own entry into the predetermined decision zone and determines that it is trailing the first autonomous vehicle. The second autonomous vehicle calculates an overtaking trajectory with respect to the first autonomous vehicle and sends, by the second autonomous vehicle's wireless transmitter, a proposed overtaking trajectory to the first autonomous vehicle. The second autonomous receives a proposed defensive trajectory from the first autonomous vehicle in response to the proposed overtaking trajectory and compares, using its control unit, the proposed overtaking trajectory with the proposed defensive trajectory. The second autonomous vehicle's control unit decides whether the overtaking is permitted in accordance with predetermined requirements and sends its control unit's decision that the overtaking trajectory is permitted to the first autonomous vehicle with a request for confirmation of this decision by the first autonomous vehicle. The second autonomous vehicle receives a confirmation from the first autonomous vehicle that the proposed overtaking trajectory is permitted and executes the proposed overtaking trajectory.
In an embodiment, a control unit is installed onboard each of the first and second autonomous vehicles. In an alternative embodiment, the onboard control unit hardware is virtualized.
In an embodiment, the predetermined requirements for overtaking include a minimum velocity advantage for the second autonomous vehicle with respect to the first autonomous vehicle. In an embodiment, the predetermined requirements for overtaking include a minimum safe distance between the first and second autonomous vehicles.
In an embodiment, a second request for a proposed defensive trajectory is sent to the first autonomous vehicle while the first autonomous vehicle remains in the decision zone if a proposed defensive trajectory is not received at the second autonomous vehicle from the first autonomous vehicle. In some embodiments, an alternative safety trajectory is received from the first autonomous vehicle while the first autonomous is still in the decision zone.
An overtaking orchestration protocol reduces the uncertainty of autonomous racing agents' behavior. The orchestration systems and its methods for use reduce the probability of collisions, create natural-looking and entertaining overtakes. The system and method also determine responsibility in case of incidents related to overtaking.
Autonomous racing cars employ high-speed and low-latency vehicle-to-vehicle communication systems. Embodiments resolve ambiguity in car positions by negotiating future trajectories using a race-orchestration protocol. Further, embodiments help prevent collisions between autonomous cars during overtaking maneuvers. When implemented in an autonomous racing environment, the disclosed systems and methods create conditions for natural-looking, spectacular overtakes.
In an embodiment, a system assigns blame for incidents during overtaking maneuvers.
Key technical aspects of the systems and methods are implemented primarily at the level of the autonomous racing car or the level of track infrastructure or by a combination of the two. In embodiments, though certain infrastructures are provided by way of example herein, components can be distributed or cloud-based.
A racing course generally comprises a continuous, predetermined track. A decision-making zone operates as a continuous zone of the track, predetermined before a race begins. An execution zone comprises another predetermined continuous sub-zone on the track. Execution zones are defined in relation to decision-making zones. Each decision-making zone is followed by an execution zone.
In some embodiments, further zones are predetermined before a race. For example, a safety emergency zone can be designated. Another example is a predetermined run-off zone.
The use of predetermined zones allows for racing trajectories or approximations of racing trajectories to be computed offline, before the race to satisfy zone constraints and reduce computation time during a race. For example, for a given vehicle, one or more trajectories are calculated for the given track.
Autonomous racing cars and the teams controlling them can be viewed as agents in relation to the orchestration platform. Future trajectories committed by agents are evaluated by the platform computing metrics, such as distance or position. For example, an overtaking maneuver can be assessed as a reduction of distance below a margin or a change in position. The outcome of an attempted overtaking is processed by the platform as successful or not in view of the competing trajectories proposed by agents for their autonomous cars.
In embodiments of the orchestration platform, a set of commands are issued to racing agents. For example, a command is sent with a safety margin that should not be crossed, or a zone in which it is prohibited to enter. In an embodiment, the platform includes an enforcement mechanism system to enforce rules established for the racing agents. For example, in alternative embodiments, a time penalty is assessed, or a speed limit imposed, or a power reduction implemented.
Rule sets defined by the platform give agents advance notice of racing parameters. Examples of such rule sets include allowed racing parameters such as safety margins, allowed speeds and agent positioning relative to each other and the course geometry. Platform rules and prescriptions for agents are implemented by the system to ensure safe overtaking. For example, trajectories are committed and accepted only when an autonomous car is in a decision-making zone. Thus, the platform will not receive or approve changes to a committed trajectory in an execution zone. In this context, trajectory refers generally to data that identify possible future car positions on the track.
In operation, the orchestration platform manages a set of N agents operating on the track at the same time. In this context, agents generally comprise autonomous cars and the teams that manage the autonomous cars before and during a race. While racing, the N agents interact with each other and the orchestration platform. In an embodiment, any two agents can trigger the orchestration platform when certain conditions occur. Some of these conditions are predefined by the platform. Examples include proximity, low time to collision, and similar safety metrics.
When the orchestration platform is triggered by a zone-related event during a race, the agents are able to engage in certain interactions with the platform. In an embodiment, the orchestration platform designates predetermined zones on the track and queries the agents when an autonomous car enters one of these zones. The agents engage with the platform to safely navigate through a given zone. For example, the platform accepts requests from the agents to change their relative positions by performing overtaking in a predetermined execution zone. The platform generates and communicates rules and prescriptions to the agents. The agents receive platform feedback and communicate with the platform by committing proposed trajectories. This communication with the platform involving committed trajectories takes place while the agents are in a decision-making zone. Committed trajectories must meet predefined requirements established by the platform. For example, a proposed trajectory must keep an autonomous car inside the track boundaries, avoid prohibited zones, and maintain safe distances from other cars or track objects. The platform allows agents to execute maneuvers in an execution zone if those maneuvers meet specific conditions established by the platform in view of track geometry, safety requirements, and counter-maneuvers or trajectories proposed by other agents. In an embodiment, the platform enforces its rules and prescriptions by assessing penalties against the agents for noncompliance.
At the outset of this example, Car-2 104 executes racing line 120 while car-1 106 executes racing line 122. Both cars then enter Zone 1 130, which is a decision-making zone. Orchestrator 102 then sends a trigger 132 to car-2 104 and trigger 134 to car-1 106. Triggers 132 and 134 are linked to entry into a decision-making zone (e.g. Zone 1 130) and give the racing agents an opportunity to propose overtaking trajectories. In an embodiment, trailing car-2 104 perceives an opportunity for overtaking car-1 106 and sends attack proposal 136 for overtaking car-1 106 to orchestrator 102. Leading car-1 106 sends a defensive trajectory 140 to orchestrator 102. In an alternative embodiment, leading car-1 106 also sends emergency trajectory 138. Orchestrator 102 analyzes the proposed attack and defense trajectories. If the proposed attack trajectory meets predetermined parameters, orchestrator 102 accepts the attack trajectory with decision acceptance 142. Orchestrator 102 then sends a request 144 to car-1 106 to commit to a safe response to the attack. In response, car-1 106 sends a commit trajectory 146.
In this example, orchestrator 102 sends an attack trajectory acceptance 148 to car-2 104 and defense trajectory acceptance 150 to car-1 106. Car-2 104 and car-1 106 then enter zone 2 152, which is an execution zone. When the autonomous vehicles enter zone 2 152, no further trajectory changes are permitted. Once in the execution zone, the autonomous vehicles execute the trajectories approved by orchestrator 102. The attack trajectory 160 is executed by car-2 104 and defense trajectory 104 is executed by car-1 106. If the autonomous vehicles execute attack and defense trajectories in accordance with orchestrator 102 instructions, trailing car-2 104 will be able to safely overtake leading car-1 106.
In the scenario of
Other overtaking scenarios may be managed by the orchestration platform, such as when the leading car does not propose a normal line or when the leading car does not propose any defensive trajectory while in the decision-making zone. These alternative overtaking scenarios are addressed below in connection with
The chronology of the two trajectories 221, 223 is shown by the relative positions of cars 220, 222 at three different times: t1, t2, and t3. Both cars 220 and 222 are in decision-making zone 202 at time t1. At time t2, car 222 has taken an advantage over car 220 just before entering corner 206. Cars 220, 222 then collide at time t3.
Agent responses from car 220 and car 222 are received by the orchestration platform. In embodiment, these agent responses follow a chronological sequence linked to decision zone 202 and execution zone 204. For example, the platform communicates with car 220 in the decision zone and requests a proposed trajectory to meet the overtaking trajectory proposed by car 222. In an embodiment, if car 220 does not provide a defensive trajectory while in the decision-making zone, then car 220 will be penalized by the system.
The chronology of the two trajectories 321, 323 is shown by the relative positions of cars 220, 222 at three different times: t1, t2, and t3. Both cars 220 and 222 are in decision-making zone 202 at time t1. At time t2, car 222 has taken an advantage over car 220 just before entering corner 206. Car 222 has successfully overtaken car 220 at time t3.
Overtaking is permitted when proposed trajectories meet certain conditions. In many embodiments, these conditions include the relative velocity and relative position of car 220 and car 222. For example, the proposed trajectory of car 222 will satisfy conditions for overtaking when it includes a relative velocity margin between the two cars that is more than a predetermined threshold of x kilometers per hour (kmph). In an embodiment, the x kmph value is determined by the platform before the race. The x value may be established based on track geometry, racing conditions, historical results, or the technical specifications of the autonomous cars. A combination of factors may also be used to determine the kmph threshold. In an embodiment, the x kmph value is determined by the platform dynamically during the race.
Relative velocity may be a sufficient condition for overtaking, but it is not always necessary. Overtaking conditions can also be met even when the velocity margin between two cars is less than x kmph. For example, car 222 may propose a trajectory that does not meet the relative velocity threshold but the proposed trajectory positions cars relative to each other such that the racing line of car 220 is compromised and it cannot defend against overtaking by car 222.
The orchestration platform may also reject proposed trajectories based on relative position even though relative velocity thresholds are met. For example, a trajectory with sufficient velocity to overtake but does not preserve safety margins for distance between cars will be rejected. Alternatively, a proposed trajectory will be rejected if that trajectory does not place car 222 on the inside of curve 206 before car 220 reaches curve 206. An overtaking trajectory may also be rejected because it does not provide enough space for car 220 at the exit of the curve 206. In an embodiment, the platform accepts all proposed trajectories that meet the relative velocity threshold and comply with relative positional requirements and safety margins.
As shown in
The chronology of the two trajectories 621, 623 is shown by the relative positions of cars 220, 222 at three different times: t1, t2, and t3. Both cars 220 and 222 are in decision-making zone 202 at time t1. At time t2, car 220 has taken an inside line just before entering corner 206 while car 222 executes a trajectory 621 that does not challenge car 220 while in corner 206. At time t3, car 222 has entered safety zone 208 while car 220 has successfully navigated corner 206 and remains ahead of car 222.
In alternative scenario 701 shown in
At the outset of this example, Car-2 804 executes racing line 820 while car-1 806 executes racing line 822. In an embodiment, trailing car-2 104 perceives an opportunity for overtaking car-1 106 and sends a request 830 to trigger orchestration platform overtaking control. In response, orchestrator 802 defines a decision making zone 1 and an execution zone 2 and sends a trigger 832 to both cars. Trigger 832 comprises a zones-definition message 833 with details of the decision-making zone 1 and execution-zone 2. The zones-definition message 833 identifies portions of track 808 for decision making and executing maneuvers. In
In response to trigger 832 and message 833, car-2 804 proposes attack trajectory 836 and car-1 806 proposes defense trajectory 840. Orchestrator 802 analyzes the proposed attack and defense trajectories. If the proposed attack trajectory meets predetermined parameters, orchestrator 802 accepts the attack trajectory with decision acceptance 842. Orchestrator 802 then sends request 844 to car-1 806 to commit to a safe response to the attack. In response, car-1 806 sends commit trajectory 846.
In this example, orchestrator 802 sends an attack trajectory acceptance 848 to car-2 804 and defense trajectory acceptance 850 to car-1 806. Car-2 804 and car-1 806 then enter zone 2 852, which is an execution zone. When the autonomous vehicles enter zone 2 852, no further trajectory changes are permitted. Once in the execution zone 852, the autonomous vehicles execute the trajectories approved by orchestrator 802. The attack trajectory 860 is executed by car-2 804 and defense trajectory 804 is executed by car-1 806. If the autonomous vehicles execute attack and defense trajectories in accordance with orchestrator 802 instructions, trailing car-2 804 will be able to safely overtake leading car-1 806.
Car 223 proposes trajectory 1325 through zones 204 and 206. Car 220 proposes trajectory 1323 and car 222 proposes trajectory 1321. Car 222's trajectory is an overtaking trajectory with respect to car 220 and an overtaking trajectory with respect to car 223. Car 220's trajectory is a defensive trajectory with respect to cars 222 and 223. Car 223's trajectory is an overtaking trajectory with respect to car 220 and a defensive trajectory with respect to car 222. These proposed trajectories are sent to the platform at time t1 while all three cars are in decision-making zone 202. The orchestration platform selects valid trajectories for each case of attack and defense and communicates the results to cars 220, 222, and 223. The cars then execute the validated trajectories. In the embodiment of
In alternative embodiments, the number of autonomous vehicles may be represented as some number n. In these embodiments, cars are treated as pairs for purposes of overtaking. Thus, if n=4 cars enter a decision-making zone, each car may propose an overtaking or defending trajectory with respect to each of the other 3 cars. The orchestration platform will resolve each two-way battle between cars and validate safe trajectories according to racing and safety parameters.
In some embodiments of the orchestration platform, decision-making zones are predetermined based on specific course geometry. In one example, a decision-making zone for a particular track is established 200 m before a curve. The optimal area where overtaking can take place safely is factored into setting off decision-making zones on a course. For example, in some parts of the track the roadway may be too narrow or the optimal line difficult to calculate within tolerances.
In some embodiments, the orchestration platform's approval of proposed trajectories is linked to the designation of decision-making zones and execution zones on the track. For example, attacking trajectories are more likely to be approved at points where the track is wider. Acceptance of attacking trajectories is based in part on predetermined vehicle-spacing parameters. Where the overtaking car has a high speed differential, spacing is less likely to result in rejection of a proposed attack trajectory. But when the speed differential is close to the lower limit, more space will be required to maintain safe distances and thus fewer parts of the track will allow for generous approval of attack trajectories.
Once chosen by the orchestration platform, decision-making zones are identified for all racing agents in advance of the race. Racing agents are also instructed to compute attacking trajectories only in the decision-making zones. For example, over a five km track, there are a number of turns and before each turn, a decision-making zone will be identified. The predetermination of decision-making zones imposes time-constraints on racing agents. The predetermined decision making zones also allow for calculation of trajectories or approximation of trajectories before the race because all racing agents know where the decision-making and execution zones start. In autonomous racing, all racing agents typically use the same or similar hardware and software. In many embodiments, racing agents can also make pre-race calculations based on expected trajectories of the other racing agents.
In some embodiments, orchestration-platform control will not allow a trailing autonomous vehicle to execute a proposed attack trajectory. For example, the leading car may propose a defense trajectory that comprises an optimal racing line that effectively blocks the attacking car. The defense trajectory may succeed because the attacking trajectory is suboptimal. Alternatively, the defense trajectory may succeed because the attacking trajectory has insufficient speed differential for the amount of space available for overtaking in a given curve.
In alternative embodiments, the orchestration platform asks the leading car for a defense trajectory more than once while in the decision-making zone. For example, another defense trajectory may be requested if the first defense trajectory does not comply with safety requirements. In an embodiment, a second request for a defense trajectory may be requested if no defense trajectory is received within a predetermined time after the first request. The x time unit for the predetermined threshold will depend on the size of the decision-making zone and no further trajectory will be requested after a car leaves a decision-making zone. Second and subsequent requests may also be made of the trailing car if, for example, the first proposed attack trajectory does not meet minimum safety thresholds. The time between requests may also account for the compute required to generate an attack trajectory. For example, if racing agents are unable to respond to requests for attack and defense trajectories in less than a predetermined time, the timing of follow-up requests will not be shorter than the time needed to calculate an attack or defense trajectory.
In some embodiments, racing agents that provide trajectories resulting in collision will receive penalties. The penalties may be issued by the orchestration platform directly or after review by race officials. Penalties may take the form of time penalties, such as 5 seconds, 10 seconds, or drive-through (typically having to leave the track and drive through the pit lane at the reduced pit-lane speed before rejoining the track). A more severe penalty, such as a stop-go penalty (typically having to leave the track and make a pit stop without servicing the car) may also be imposed. The orchestration platform approves proposed attack and defense trajectories on the assumption that the proposing racing agents can successfully execute the proposed trajectories. If a racing agent cannot execute a proposed trajectory after approval, a penalty may be assessed to discourage overly optimistic proposals.
The orchestration platform generally assumes that a racing agent's proposed trajectory can be executed. In some embodiments, the orchestration platform has access to autonomous vehicle performance statistics and makes limited threshold determinations about whether a proposed trajectory is possible in view of car performance parameters and track conditions. In ordinary cases, however, the platform will accept proposed trajectories and issue penalties to racing agents that cannot execute their proposals.
The orchestration platform can be implemented at the track level through the use of stationary hardware installed locally. Alternatively, the orchestration platform can be implemented as a cloud-based system or by the autonomous vehicles themselves. In a car-based system, the orchestration platform operates as a message protocol exchange where each car supports the protocol. In these embodiments, race-control elements, including hardware and software configured for message exchange are associated with each car or with each racing agent. Protocol algorithms of negotiation may be employed that ensure secure exchanges by using encrypted trajectories. In certain embodiments, an exchange of cryptographic keys between the cars is used. For example, proposed trajectories are exchanged in encrypted form by two racing agents while in decision-making zones. Encryption keys are used to decrypt the proposed trajectories and each racing team processes the attack and defense trajectories using the same algorithm. Proposed trajectories are permitted or denied after each racing team independently applies the same orchestration-platform algorithm. When agreed upon attack and defense trajectories are confirmed, the racing teams execute these trajectories in the execution zone. When the racing teams are unable to confirm an attack and defense trajectory, each car will maintain its current trajectory and optionally propose an emergency trajectory to avoid collision.
The hardware for implementing the orchestration platform includes vehicle-to vehicle-communications equipment. In an embodiment, Vehicle-to-Anything (V2X) infrastructure may be used to send information and requests to racing agents. In one embodiment, computing devices with processors and memory may be installed on the autonomous vehicles, on the track, or on both. The autonomous vehicles and track can be equipped with sensors to track relative positions, geolocation, and racing parameters such as velocity, acceleration, and vehicle performance. Racing agents may maintain control of the autonomous vehicles remotely and perform calculations on-vehicle or remotely, or in combination.
In alternative embodiments, the autonomous racing cars themselves calculate their paths under an orchestration protocol in connection with predetermined track zones. In some of these embodiments, calculations are performed at the car level by onboard control-unit hardware and software. In an embodiment, control unit hardware and software are modular and isolated from other car hardware or software. Alternatively, some or all of the control unit hardware may be virtualized by, for example, running as a guest in a container using computing resources of the host autonomous car. In an embodiment, the car-level control units are secured so that racing agents may not tamper with control-unit hardware or software. For example, a self-contained control unit can be installed on each car under orchestration platform control. The onboard control units can be configured with their own wireless receivers and transmitters. In an embodiment, each autonomous vehicle or racing agent communicates directly with the onboard control unit and the onboard control unit communicates with the onboard control units associated with other autonomous vehicles. Thus, vehicle-to-vehicle communication can take place by way of onboard control units only. Alternatively, the autonomous vehicles or racing agents can use their own wireless communication devices to communicate with other autonomous vehicles or racing agents. Communications received can be passed to the onboard control unit for analysis and response. In some embodiments, the vehicles send each other only encrypted messages and data. The onboard control units then use public key cryptography or other encryption tools to decrypt the messages and data. In an embodiment, only the onboard control units can decrypt and understand the proposed trajectories received from other autonomous vehicles or racing agents. The autonomous cars and racing agents learn only the control unit's decisions and are unable to tamper with the inputs the onboard control units receive.
In other embodiments, the orchestration platform acts as a master path coordinator for the autonomous vehicles and no control units are installed at the vehicle level. In these embodiments, all calculations are performed by the platform at a location apart from the autonomous vehicles and the racing agents. Alternatively, control-unit functionality can be distributed. For example, processing of trajectories can be performed at a central location apart from the autonomous vehicles while detecting entry into a decision-making zone or evaluation of successful performance of a proposed trajectory is performed by an onboard control unit.
Reviewing control units can also be employed to validate decisions made by onboard control units, track-based control units, or remote control units. For example, a racing agent may dispute a determination made by a control unit during a race because of a hardware malfunction, software error, or communication error. In such cases, appeal can be made to one or more reviewing control units applying the same algorithms and predetermined parameters in effect during the race.
