MCC Ref. No.:  103361‐329WO1  SYSTEMS AND METHODS FOR COOPERATIVE NAVIGATION WITH A UTONOMOUS VEHICLES    CROSS‐REFERENCE TO RELATED APPLICATIONS  [0001]     This application claims the benefit of U.S. provision al patent application No.  63/456,930, filed on April 4, 2023, and titled “SY STEMS AND METHODS FOR ANALYZING SMART  INTERSECTIONS WITH HIGHLY AUTOMATED VEHICLES,” and U .S. provisional patent application  No. 63/373,618, filed on August 26, 2022, and titled  “SYSTEMS AND METHODS FOR OPERATING  SMART INTERSECTIONS WITH AUTONOMOUS VEHICLES,” the d isclosures of which are expressly  incorporated herein by reference in its entirety.    STATEMENT REGARDING FEDERALLY FUNDED RESEARCH  [0002]     This invention was made with government support under  grant/contract  number 69A3552047138 awarded by the U.S. Department o f Transportation. The government  has certain rights in the invention.    BACKGROUND  [0003]     Autonomous vehicles can navigate between two points w ithout a human  driver, or with limited human input. Autonomous vehic les can include sensors, computer  systems, and communication systems, which can be used  to identify obstacles, perform and  collision avoidance while the autonomous vehicle is n avigating along a route. Autonomous  vehicles can also include route planning systems.  � � MCC Ref. No.:  103361‐329WO1  [0004]     Highly automated vehicles can identify obstacles, and� �perform collision  avoidance while the autonomous vehicle is navigating  along a route. Highly automated vehicles  can also perform route planning and navigation betwee n waypoints.   [0005]     Both autonomous vehicles and highly automated vehicles  can operate in  conjunction with smart infrastructure systems. Smart i nfrastructure systems can be used to  monitor and/or control roadways, for example by contr olling traffic signals.   [0006]     Therefore, what is needed are systems and methods fo r using autonomous  vehicles and/or highly automated vehicles with smart  infrastructure. For example, systems and  methods for avoiding collisions between vehicles. For� �example, systems and methods for  avoiding collisions between vehicles.      SUMMARY   [0007]     Systems for performing cooperative navigation with aut onomous vehicles  and/or highly automated vehicles, are described herein .  [0008]     In some aspects, the techniques described herein rela te to a system for  performing cooperative navigation with autonomous vehic les, the system including: an  autonomous vehicle; a communication system; and a veh icle control system, the vehicle control  system including a processor and a memory, the memor y having computer‐executable  instructions stored thereon that, when executed by th e processor, cause the processor to:  receive traffic information from the communication sys tem, wherein the traffic information  includes first information from a plurality of roadsi de communication devices and second  information from a second vehicle; receive a pluralit y of vehicle parameters associated with the  MCC Ref. No.:  103361‐329WO1  autonomous vehicle; determine, based on the traffic i nformation and the vehicle parameters, a  cooperative navigation solution.  [0009]     In some aspects, the techniques described herein rela te to a system, further  including controlling the autonomous vehicle using the  cooperative navigation solution.  [0010]     In some aspects, the techniques described herein rela te to a system or claim  2, wherein the vehicle control system is attached to  the autonomous vehicle.  [0011]     In some aspects, the techniques described herein rela te to a system, wherein  the cooperative navigation solution includes a vehicle  velocity instruction, wherein the vehicle  velocity instruction includes a velocity that avoids  a potential collision.  [0012]     In some aspects, the techniques described herein rela te to a system, wherein  the cooperative navigation solution includes a coopera tive cruise control instruction.  [0013]     In some aspects, the techniques described herein rela te to a system, wherein  the cooperative navigation solution includes cooperativ e adaptive lane keeping information.  [0014]     In some aspects, the techniques described herein rela te to a system, wherein  the cooperative navigation solution includes cooperativ e collision avoidance information.  [0015]     In some aspects, the techniques described herein rela te to a system, wherein  the roadside communication devices include a road sid e unit (RSU).  [0016]     In some aspects, the techniques described herein rela te to a system, wherein  the roadside communication devices include a smart tr affic light (STL).  [0017]     In some aspects, the techniques described herein rela te to a system, wherein  the roadside communication devices include a smart tr affic sign (STS).  MCC Ref. No.:  103361‐329WO1  [0018]     In some aspects, the techniques described herein rela te to a system, wherein  the roadside communication devices include an automate d traffic management (ATM) system.  [0019]     In some aspects, the techniques described herein rela te to a system, wherein  the vehicle parameters include a vehicle length.  [0020]     In some aspects, the techniques described herein rela te to a system, wherein  the vehicle parameters include a vehicle position.  [0021]     In some aspects, the techniques described herein rela te to a system, wherein  the vehicle parameters include a heading angle.  [0022]     In some aspects, the techniques described herein rela te to a system, wherein  the vehicle parameters include a lane identity of th e vehicle.  [0023]     In some aspects, the techniques described herein rela te to a system, wherein  the vehicle parameters include a turn identification  of the vehicle.  [0024]     In some aspects, the techniques described herein rela te to a system, wherein  the communication system includes an autonomous inters ection management system.  [0025]     In some aspects, the techniques described herein rela te to a system, further  including a light detection and ranging (LIDAR) senso r, and wherein the plurality of vehicle  parameters include LIDAR data.  [0026]     In some aspects, the techniques described herein rela te to a system, further  including a radar sensor, and wherein the plurality  of vehicle parameters include radar data.  [0027]     In some aspects, the techniques described herein rela te to a system, further  including a camera, and wherein the plurality of veh icle parameters include image data.  MCC Ref. No.:  103361‐329WO1  [0028]     In some aspects, the techniques described herein rela te to a computer‐ implemented method of performing cooperative collision� �avoidance for an autonomous  vehicle, the method including: receiving traffic infor mation from a communication system,  wherein the traffic information includes information f rom a plurality of roadside  communication devices and information from a second v ehicle; receiving a plurality of vehicle  parameters associated with the autonomous vehicle; det ermining, based on the traffic  information and the vehicle parameters, a cooperative� �navigation solution.  [0029]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the cooperative navigation� �solution includes a vehicle velocity,  wherein the vehicle velocity is a velocity that avoi ds a potential collision.  [0030]     In some aspects, the techniques described herein rela te to a computer‐ implemented method or claim 22, wherein the cooperati ve navigation solution includes  cooperative cruise control information.  [0031]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the cooperative navigation� �solution includes cooperative  adaptive lane keeping information.  [0032]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the cooperative navigation� �solution includes cooperative  collision avoidance information.  [0033]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the roadside communication� �devices include a road side unit  (RSU).  MCC Ref. No.:  103361‐329WO1  [0034]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the roadside communication� �devices include a smart traffic light  (STL).  [0035]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the roadside communication� �devices include a smart traffic sign  (STS).  [0036]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the roadside communication� �devices include an automated  traffic management (ATM) system.  [0037]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the vehicle parameters inc lude a vehicle length.  [0038]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the vehicle parameters inc lude a vehicle position.  [0039]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the vehicle parameters inc lude a heading angle.  [0040]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the vehicle parameters inc lude a lane identity of the vehicle.  [0041]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the vehicle parameters inc lude a turn identification of the  vehicle.  MCC Ref. No.:  103361‐329WO1  [0042]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the communication system i ncludes an autonomous  intersection management system.  [0043]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the plurality of vehicle  parameters include LIDAR data.  [0044]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the plurality of vehicle  parameters include RADAR data.  [0045]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, wherein the plurality of vehicle  parameters include camera data.  [0046]     In some aspects, the techniques described herein rela te to a computer‐ implemented method, further including controlling the  autonomous vehicle using the  cooperative navigation solution.  [0047]     It should be understood that the above‐described su bject matter may also be  implemented as a computer‐controlled apparatus, a co mputer process, a computing system, or  an article of manufacture, such as a computer‐reada ble storage medium.  [0048]     Other systems, methods, features and/or advantages wil l be or may become  apparent to one with skill in the art upon examinat ion of the following drawings and detailed  description. It is intended that all such additional� �systems, methods, features and/or  advantages be included within this description and be  protected by the accompanying claims.    BRIEF DESCRIPTION OF THE DRAWINGS  MCC Ref. No.:  103361‐329WO1  [0049]     The components in the drawings are not necessarily t o scale relative to each  other. Like reference numerals designate corresponding� �parts throughout the several views.  [0050]     FIG. 1A illustrates a system block diagram of a sys tem for performing collision  avoidance, according to implementations of the present  disclosure.  [0051]     FIG. 1B illustrates a system block diagram of a sys tem for performing collision  avoidance, according to implementations of the present  disclosure.  [0052]     FIG. 2A illustrates a flow chart of a method for p erforming collision avoidance,  according to implementations of the present disclosure .   [0053]     FIG. 2B illustrates a flow chart of a method for p erforming collision avoidance,  according to implementations of the present disclosure .  [0054]     FIG. 3A illustrates a system including cooperative hi ghly automated vehicles  with cooperative collision avoidance, cooperative cruis e control, and cooperative lane‐keeping,  according to implementations of the present disclosure .   [0055]     FIG. 3B illustrates a system including cooperative hi ghly automated vehicles  with cooperative collision avoidance, cooperative cruis e control, cooperative lane‐keeping, GPS,  and RADAR, according to implementations of the presen t disclosure.   [0056]     FIG. 4 illustrates a system including cooperative hig hly automated vehicles  with cooperative collision avoidance, cooperative cruis e control, cooperative lane‐keeping, GPS,  LIDAR, RADAR, and a camera, according to implementati ons of the present disclosure.   [0057]     FIG. 4 illustrates a method of cooperative navigation , according to  implementations of the present disclosure.   [0058]     FIG. 5 is an example computing device.  MCC Ref. No.:  103361‐329WO1  [0059]     FIG. 6 illustrates an overview of simulation scenario  of a smart intersection  including a roadside unit (RSU), a smart traffic lig ht (STL), and autonomous intersection  management (AIM).   [0060]     FIG. 7 illustrates results of a simulation of an ex ample implementation of the  present disclosure, showing that an example actor and  ego vehicle do not collide based on  different velocity profiles.   [0061]     FIG. 8 illustrates results of a simulation of an ex ample implementation of the  present disclosure including AIM devices, showing that  an example actor and ego vehicle do not  collide based on different velocity profiles.   [0062]     FIG. 9 illustrates results of a results of a simula tion of an example  implementation of the present disclosure including AIM , STL, and cooperation.   [0063]     FIG. 10 illustrates an example analysis of a first  actor in a simulation,  according to an implementation of the present disclos ure.   [0064]     FIG. 11 illustrates an example analysis of a second� �actor in a simulation,  according to an implementation of the present disclos ure.   [0065]     FIG. 12 illustrates an example analysis of a third  actor in a simulation,  according to an implementation of the present disclos ure.  [0066]     FIG. 13 illustrates velocity tracking results for sim ulations of different  cooperation scenarios, including V2V, cooperation, V2V� �and AIM cooperation, and V2V, AIM,  and STL cooperation.  MCC Ref. No.:  103361‐329WO1  [0067]     FIG. 14 illustrates attributes of example sensors and  data sources that can be  used in cooperative navigation systems, according to  implementations of the present  disclosure.    [0068]     FIG. 15A illustrates examples of near space and far� �space navigation,  according to implementations of the present disclosure .  [0069]     FIG. 15B illustrates examples of near space and far� �space navigation,  according to implementations of the present disclosure .  [0070]     FIG. 16 illustrates threats and vulnerabilities of di fferent sensors and sources  of information that can be used in implementations o f the present disclosure.  [0071]     FIG. 17 illustrates an example of radar interference� �at a smart intersection,  according to implementations of the present disclosure .  [0072]     FIG. 18 illustrates an example simulation of a smart  intersection, according to  implementations of the present disclosure.  [0073]     FIG. 19 illustrates a schematic of conflict points i n an intersection, according  to implementations of the present disclosure.  [0074]     FIG. 20 illustrates a table of static and dynamic v ariables that can be  simulated, according to implementations of the present  disclosure.   [0075]     FIG. 21 illustrates a simulation of velocity as a f unction of time for jamming  scenarios, according to an implementation of the pres ent disclosure.  [0076]     FIG. 22 illustrates a simulation of steering angle a s a function of time for  jamming scenarios, according to an implementation of  the present disclosure.   MCC Ref. No.:  103361‐329WO1  [0077]     FIG. 23 illustrates a simulation of acceleration as  a function of time for  jamming scenarios, according to an implementation of  the present disclosure.  [0078]     FIG. 24 illustrates a simulation of highly automated� �vehicles including  positions as a function of time, according to an im plementation of the present disclosure.  [0079]     FIG. 25 illustrates a simulation of highly automated� �vehicles including  positions as a function of time including jamming an d interference scenarios, according to an  implementation of the present disclosure.  [0080]     FIG. 26 illustrates a simulation result showing safet y where patchy  information was provided for actor 2, according to a n implementation of the present  disclosure.  [0081]     FIG. 27 illustrates a simulation result showing veloc ity, where patchy  information was provided for actor 2, according to a n implementation of the present  disclosure.   [0082]     FIG. 28 illustrates attributes of an ego vehicle und er different simulation  scenarios, according to implementations of the present  disclosure.   [0083]     FIG. 29 illustrates simulation results showing velocit y as a function of time for  different scenarios, according to implementations of t he present disclosure.  [0084]     FIG. 30 illustrates simulation results showing steerin g angle as a function of  time for different scenarios, according to implementat ions of the present disclosure.  [0085]     FIG. 31 illustrates simulation results showing acceler ation as a function of  time for different scenarios, according to implementat ions of the present disclosure.  MCC Ref. No.:  103361‐329WO1  [0086]     FIG. 32 illustrates simulation results showing acceler ation as a function of  time for different scenarios, according to implementat ions of the present disclosure.  [0087]     FIG. 33 illustrates simulations of cooperative collisi on avoidance in threat  scenarios where AIM and STL are jammed by an attack er, according to implementations of the  present disclosure.  [0088]     FIG. 34 illustrates simulations of cooperative collisi on avoidance in threat  scenarios where STL is jammed by an attacker, accord ing to implementations of the present  disclosure.  [0089]     FIG. 35A illustrates simulations of cooperative collis ion avoidance in threat  scenarios where all communication channels are active,  according to implementations of the  present disclosure.  [0090]     FIG. 35B illustrates cooperative cruise control veloci ties in threat scenarios,  according to implementations of the present disclosure .   [0091]     FIG. 36 illustrates a comparison of analyses of ego� �vehicles in different threat  scenarios with different driving strategies for HAVs  at a signal‐free smart intersection, according  to implementations of the present disclosure.   [0092]     FIG. 37A illustrates lead vehicle velocity in an exa mple simulated scenario,  according to implementations of the present disclosure .  [0093]     FIG. 37B illustrates simulated cooperative lane keepin g results in different  threat scenarios, according to implementations of the� �present disclosure.  [0094]     FIG. 38 illustrates example conflict points at a sim ulated intersection,  according to implementations of the present disclosure .  MCC Ref. No.:  103361‐329WO1  [0095]     FIG. 39 illustrates example static and dynamic variab les, according to  implementations of the present disclosure.   [0096]     FIG. 40A illustrates a schematic of a conflict point  between an ego and actor  vehicle, according to an example implementation of th e present disclosure.   [0097]     FIG. 40B illustrates a schematic of a conflict betwe en an ego vehicle and actor  vehicle, according to an example implementation of th e present disclosure.   [0098]     FIG. 41 illustrates spacing control between vehicles,� �according to an example  implementation of the present disclosure.  [0099]     FIG. 42 illustrates the relationship between an ego  vehicle and actor vehicles,  according to implementations of the present disclosure .  [00100]     FIG. 43 illustrates a schematic of two vehicles in  a simulated intersection,  according to implementations of the present disclosure .  [00101]     FIG. 44 illustrates a schematic of two vehicles in  a simulated lane of traffic,  according to implementations of the present disclosure .  [00102]     FIG. 45A illustrates simulation results showing accele ration as a function of  time for different scenarios, according to implementat ions of the present disclosure.  [00103]     FIG. 45B illustrates simulation results showing steeri ng angles as a function of  time for different scenarios, according to implementat ions of the present disclosure.  [00104]     FIG. 46 illustrates simulation results for different  jamming scenarios,  according to implementations of the present disclosure .  [00105]     Fig. 47 illustrates simulation results showing velocit y as a function of time for  different jamming scenarios, according to implementatio ns of the present disclosure.  MCC Ref. No.:  103361‐329WO1  [00106]     FIG. 48 illustrates simulation results showing steerin g angle as a function of  time for different jamming scenarios, according to im plementations of the present disclosure.  [00107]     FIG. 49 illustrates simulation results showing acceler ation as a function of  time for different jamming scenarios, according to im plementations of the present disclosure.  [00108]     FIG. 50 illustrates simulation results showing acceler ation as a function of  time for different jamming scenarios, according to im plementations of the present disclosure.  [00109]     FIG. 51 illustrates simulation results for an ego ve hicle under different  jamming scenarios, according to implementations of the  present disclosure.  [00110]     FIG. 52 illustrates an example algorithm for performi ng cooperative collision  avoidance.    DETAILED DESCRIPTION  [00111]     Unless defined otherwise, all technical and scientific  terms used herein have  the same meaning as commonly understood by one of o rdinary skill in the art. Methods and  materials similar or equivalent to those described he rein can be used in the practice or testing  of the present disclosure. As used in the specificat ion, and in the appended claims, the singular  forms “a,” “an,” “the” include plural refe rents unless the context clearly dictates otherwise.  The  term “comprising” and variations thereof as used  herein is used synonymously with the term  “including” and variations thereof and are open,  non‐limiting terms. The terms “optional” or  “optionally” used herein mean that the subsequentl y described feature, event or circumstance  may or may not occur, and that the description incl udes instances where said feature, event or  circumstance occurs and instances where it does not.� �Ranges may be expressed herein as from  MCC Ref. No.:  103361‐329WO1  "about" one particular value, and/or to "about" anoth er particular value. When such a range is  expressed, an aspect includes from the one particular  value and/or to the other particular  value. Similarly, when values are expressed as approx imations, by use of the antecedent  "about," it will be understood that the particular v alue forms another aspect. It will be further  understood that the endpoints of each of the ranges� �are significant both in relation to the other  endpoint, and independently of the other endpoint. Wh ile implementations will be described  for performing navigation and collision avoidance betw een autonomous vehicles in  intersections, it will become evident to those skille d in the art that the implementations are not  limited thereto, but are applicable for preventing co llisions between other vehicle types, as well  as preventing collisions between vehicles in locations  other than intersections.   [00112]     Described herein are systems and methods for performi ng navigation and  control of autonomous vehicles at an intersection.   [00113]     The systems and methods described herein can be used  to implement  cooperative navigation strategies with partially or co mpletely autonomous vehicles.  In existing  systems, partially or completely autonomous vehicles t ypically perform self‐driving without  using cooperative navigation. These autonomous vehicles  can be considered “self‐contained” –  the vehicle acquires the information it needs to nav igate from a variety of sensors, and makes  decisions without receiving information from other sou rces or vehicles. These “self‐contained”  autonomous vehicles are unable to take advantage of  the additional information and navigation  strategies that could be acquired by receiving inform ation from other sources and/or  cooperating with other vehicles.   MCC Ref. No.:  103361‐329WO1  [00114]     In contrast, other existing systems for autonomous ve hicles include vehicles  that are centrally controlled by a system that monit ors the position and status of multiple  vehicles in that system, and issues commands to the� �vehicles to steer navigate. These centrally  controlled systems are vulnerable to disruption becaus e the vehicles are dependent on the  central controller to determine how to navigate. In  other words, these autonomous vehicles are  not “self‐contained.”  [00115]     The systems and methods described herein include coop erative systems and  methods that allow autonomous vehicles to navigate au tonomously and to interact with other  autonomous vehicles and various sensors that can be  part of road infrastructure. The systems  and methods described herein can generate a cooperati ve navigation solution for an  autonomous vehicle using a communication system, traff ic information, and/or vehicle  parameters that can optionally be sensed using one o r more sensors. . The autonomous vehicle  is optionally controlled based, at least in part, on  the cooperative navigation solution. This  allows for the benefits of cooperative navigation str ategies to be incorporated into systems  with autonomous vehicles.   [00116]     In particular, implementations of the present disclosu re include cooperative  navigation methods that can be used in conjunction w ith AIM (Autonomous Intersection  Management), RSU’s (RoadSide Units), STL’s (Smart  Traffic Lights), and OBU’s (vehicle onboard  units) and CAV’s (connected autonomous vehicles) tha t can be connected by infrastructure. The  example implementation described herein can be used b y autonomous vehicles to navigate and  communicate with smart infrastructure.   MCC Ref. No.:  103361‐329WO1  [00117]     Cooperative navigation strategies that include autonomo us vehicles and  smart infrastructure can increase the safety and capa city of intersections, including smart  intersections. Additionally, implementations of the pre sent disclosure can be used for both  autonomous and non‐autonomous vehicles, as well as  in situations where only some vehicles  are configured to cooperate (i.e., are non‐cooperati ve). Implementations of the present  disclosure using smart infrastructure can increase the  safety and efficiency of autonomous  vehicles in situations where obstacles or other vehic les are beyond visual range of each other,  or beyond visual range of the intersection.  [00118]     Implementations of the present disclosure can be used  for collision avoidance  in traffic situations with and without traffic signal s.  In situations with and without traffic  signals, different components of the system can be u sed. For example, in an unsignalized  intersection, the autonomous vehicle can use an OBU,� �while in a signalized intersection the  autonomous vehicle can use an RSU, OBU, AIM system,� �and/or STL’s.     [00119]     Implementations of the present disclosure include a c ooperative navigation  strategy focusing on Cooperative Collision Avoidance ( CCA) for CAV’s. Smart infrastructure  information can be used with CAV’s in a smart cit y environment or other environments  including smart infrastructure. The present disclosure� �contemplates that smart infrastructure  can include RSUs, an AIM systems, STL, and Smart tr affic Signs (STS). The present disclosure  contemplates that smart infrastructure can include any  or all of these components, and that the  components can be placed at any location along a ro adway (e.g., at an intersection, between  intersections, along a highway, etc.).   MCC Ref. No.:  103361‐329WO1  [00120]     Implementations of the present disclosure are configur ed to avoid collisions  between CAVs at smart intersections. The cooperative  navigation methods and systems  disclosed herein can include a navigation system that  can exchange data, on its current state  and environmental parameters to evaluate its decision� �and position for safe operation. The  navigation system can be used to provide position na vigation, and timing (PNT) guidance to  autonomous vehicles.   [00121]     Implementations of the present disclosure can use inf ormation from RSU, STL,  AIM, and OBU to generate an optimized velocity profi le to cross the smart intersection.  [00122]     For example, the vehicle control system can be confi gured to receive traffic  information from the communication system. The traffic  information from the communication  system can include information from roadside communica tion and computing devices and/or  information from other vehicles.   [00123]     The information received from the roadside communicati on and computing  devices can include information from smart infrastruct ure devices, including road side units,  smart traffic lights, smart traffic signs, and automa ted traffic management systems. The road  side units, smart traffic lights, smart traffic signs , and automated traffic management systems  can be part of the communication system. For example , any or all of the roadside  communication and computing devices can be connected  by a wired or wireless network.  Another non‐limiting example of a roadside communica tion and computing device that can be  part of the communication system is an AIM system.    [00124]     With reference to FIG. 1A, implementations of the pr esent disclosure include  systems for performing cooperative navigation with aut onomous vehicles.  MCC Ref. No.:  103361‐329WO1  [00125]     The system 100 shown in FIG. 1A includes an autonom ous vehicle 102, a route  planning system 104, a communication system 106, and� �a vehicle control system 136.  The  vehicle control system 136 can be operably coupled t o the autonomous vehicle 102, and, for  example, can be configured to control the autonomous� �vehicle 102. Optionally, any or all of the  autonomous vehicle 102, route planning system 104, co mmunication system 106, and vehicle  control system 136 can include a computing device, f or example the computing device 500  illustrated in FIG. 5. The vehicle control system 13 6 can be configured to perform methods of  cooperative navigation, including the methods described  with reference to FIG. 2A and FIG. 2B.   [00126]     In some implementations, the system 100 can be confi gured so that any or all  of the route planning system 104, communication syste m 106, and/or vehicle control system  136 are positioned in/on the autonomous vehicle 102,� �or attached to the autonomous vehicle  102. The systems and methods described herein can be  configured to allow for cooperative  navigation where one or more autonomous vehicles 102� �are in traffic, and the autonomous  vehicles perform cooperative navigation to avoid colli sions between themselves and/or any  non‐autonomous vehicles. As used herein, cooperative� �navigation includes navigation systems  and methods that may not rely on centralized traffic  control, and can be performed onboard  the autonomous vehicles 102.   [00127]     Still with reference to FIG. 1A, the communication s ystem 106 can optionally  include roadside units and/or onboard units.  As use d herein, an “onboard unit” or OBU refers  to a communication or control device that is located  “onboard” a vehicle. The communication  system 106 can further include Autonomous Intersection s Management (AIM) system 124, and  MCC Ref. No.:  103361‐329WO1  smart traffic lights (STL) 128. The communication sys tem 106 can be configured to interface  with the “ego” OBU 126, which can be located on  the autonomous vehicle 102.   [00128]     Still with reference to FIG. 1A, the navigation guid ance and control loop 138  can include a collision avoidance system 132, a path  following system 134, and a control system  136. The control system 136 can be configured to re ceive collision avoidance and path following  information (e.g., speed and attitude) from the colli sion avoidance and path following systems,  and convert the speed and attitude into acceleration,  braking, and steering controls for the  autonomous vehicle 102. The control system 136 can a lso be configured to determine, based  on the traffic information and the vehicle parameters , a vehicle velocity, where the vehicle  velocity represents a speed that will avoid a collis ion between the autonomous vehicle and  another vehicle or other obstacle.  Alternatively or� �additionally, the vehicle parameters can  include information about the location or movement of  the vehicle. As a non‐limiting example,  the vehicle parameters can include a heading angle,  lane identity of the vehicle, and/or turn  identification of the vehicle.   [00129]     Again with reference to FIG. 1A, the collision avoid ance system 132 and path  following system 134 can receive inputs from a waypo ints system 140. The waypoints system  can determine a desired path for the autonomous vehi cle 102 that can be an input to the  collision avoidance system 132 and path following sys tem 134. As shown in FIG. 1A, the  collision avoidance system 132 and path following sys tem 134 can also exchange information  (for example, speed information for the autonomous ve hicle 102). The information received  from other vehicles can include information about the  characteristics (i.e., “vehicle  parameters”) of those autonomous vehicles. The vehic le parameters can include information  MCC Ref. No.:  103361‐329WO1  about any attribute of the vehicle. In some implemen tations of the present disclosure, vehicle  parameters include information about the size of the� �vehicle, including the length, width, and  height of the vehicle.   [00130]     It should be understood that the use of other traff ic management systems or  smart infrastructure devices is contemplated by the p resent disclosure.   [00131]     With reference to FIG. 1B, it should be understood  that the communication  system 106 can be configured so that information is� �exchanged along different paths or in  different ways among the AIM system 124, STL 128, R SU/OBU 122 and ego OBU 126. In the  example system 150 illustrated in FIG. 1B, the ego  OBU 126 communicates with the RSU/OBU  122, which in turn communicates with the AIM system� �124 and STL 128. But it should be  understood that any part of the communication system� �106 can be in communication with any  other part of the communication system 106.   [00132]     With reference to FIG. 3A, another example system 30 0 is illustrated  according to another implementation of the present di sclosure. The system 300 includes the  communication system 106 and route planning system 10 4 described with reference to FIG. 1A.   The system 300 further includes a cooperative automat ed driving system 302 that can include a  cooperative collision avoidance system 310, a cooperat ive adaptive cruise control system 314,  and a cooperative lane keeping system 318. The coope rative adaptive cruise control system 314  and cooperative lane keeping system 318 can optionall y be part of a path following system 134.  The system 300 can further include route planning sy stem 104.  In the system 300, the  navigation guidance and control loop 138 can include� �a model predictive control system 320, a  vehicle dynamics system 330 and a Global navigation  satellite system (“GNSS system”) 340. A  MCC Ref. No.:  103361‐329WO1  non‐limiting example of a GNSS system 340 is a GP S system, but it should be understood that  any system or sensor that can be used to locate a� �vehicle can be used in place of the GNSS  system 340 or in addition to the GNSS system 340.  .   [00133]     With reference to FIG. 3B, another system 350 is il lustrated according to  another implementation of the present disclosure. The� �system 350 includes the elements  shown and described with reference to the system 300  in FIG. 3A.  In FIG. 3B, the system 350  further includes a RADAR system or sensor 342 as pa rt of the system 350.   [00134]     With reference to FIG. 4, another system 400 is ill ustrated according to  another implementation of the present disclosure. The� �system 400 includes the elements  shown and escribed with reference to the system 350� �in FIG. 3B. The system 400 further  includes a LIDAR sensor 402 and a camera sensor 404 .   [00135]     In some implementations, the RSU can be used for co mmunication between  vehicles and smart infrastructure. The RSU can use a  dedicated short‐range communication  (DSRC) channel and can share environmental parameters,  AIM, and STL information with  vehicles present at that intersection.  [00136]     In some implementations, the OBU can be a communicat ion device used to  exchange information with a vehicle to vehicle (V2V)� �and vehicle to infrastructure (V2I) using  the DSRC channel. All vehicle parameters and informat ion is shared via V2V communication.  [00137]     In some implementations, the AIM can be an intersect ion management  system that assigns time slots to the vehicles and  manages intersection traffic light controller  phase and time information.  MCC Ref. No.:  103361‐329WO1  [00138]     In some implementations, the STL is the smart traffi c light that can change  phase and time information according to the traffic  condition and density on the specific lane.  [00139]     With reference to FIGS. 2A and 2B, the present disc losure includes methods of  performing cooperative navigation. FIG. 2A illustrates� �a flow chart of a method 200 for  performing collision avoidance, according to implementa tions of the present disclosure. The  method can include receiving vehicle parameters at st ep 202.    [00140]     At step 204, the method can include receiving inform ation from smart  infrastructure systems (including SPAT and MAP message s).    [00141]     At step 206, the method can include receiving time  allocation information.  Optionally, the time allocation information can be ob tained from smart infrastructure systems.  [00142]     At step 208, the method can also include identifying  vehicles.  [00143]     At step 210, the method can include detecting confli ct points, for example  conflict points between any number of the vehicles i dentified in step 208. Optionally, the  distance between the conflict points can be based on  vehicle parameters and/or environmental  parameters.  [00144]     At step 212, the distance between the vehicle and t he conflict points can also  be determined.  Optionally, the distance between the� �conflict points can be based on vehicle  parameters and/or environmental parameters.  [00145]     At step 214, the ego vehicle velocity can be optimi zed.  Optionally, the  optimization is performed based on the distance betwe en the vehicle and the conflict points,  and the vehicle parameters of the vehicle. As an ex ample, the optimization can be an  MCC Ref. No.:  103361‐329WO1  optimization that determines a speed of the vehicle  that will avoid a collision at the conflict  point.   [00146]     At step 216, the method can further include adjustin g the path of the vehicle  based on the conflict points to avoid the conflict  points.    [00147]     At step 218, the method can further include providin g the optimized velocity  determined at step 216 to a control system. Optional ly, the optimized velocity can be provided  to a path following system/algorithm to steer the eg o vehicle.   [00148]     At step 218, the method can include repeating steps� �202 through 216 any  number of times. Optionally, the method can be repea ted when there is a change in a vehicle  parameter, in order to determine whether the new pat h and/or velocity of the vehicle will  collide with any other vehicle.   [00149]     With reference to FIG. 2B, another example method 25 0 for performing  cooperative navigation is illustrated.  The example m ethod can be a computer‐implemented  method in some implementations of the present disclos ure. The method 250 can be used for  cooperative navigation of autonomous vehicles. A non� �limiting example of an autonomous  vehicle is a car, but it should be understood that� �the present disclosure can be used for other  autonomous vehicles, for example trucks, trains, and/o r aerial vehicles.   [00150]     At step 252, the method includes receiving traffic i nformation from a  communication system. Optionally, the communication sys tem can include any/all of the  components of the computing device 500 shown in FIG.  5.   [00151]     The traffic information can include information from  a plurality of roadside  communication devices and information from a second v ehicle.  As used herein, “roadside  MCC Ref. No.:  103361‐329WO1  communication devices” can include any device that  can be used to monitor traffic and/or  communicate with vehicles in traffic. In some impleme ntations, the roadside communication  device(s) can include a road side unit (RSU). Altern atively or additionally, the roadside  communication device(s) can include a STL and/or smar t traffic sign (STS)  Yet another non‐limiting example of a roadside comm unication device is an automated traffic  management (ATM) system. Still another non‐limiting  example of a roadside communication  device is an autonomous intersection management system .  [00152]     At step 254, the method can include receiving vehicl e parameters associated  with the autonomous vehicle.  The vehicle parameters� �can include any information that relates  to the position or orientation of the autonomous veh icle, as well as the physical properties of  the autonomous vehicle. Non‐limiting examples of veh icle parameters that can be used in  implementations of the present disclosure include vehi cle length, vehicle position, heading  angle, a lane identity of the vehicle, and a turn  identification of the vehicle.  [00153]     Alternatively or additionally, the method can include� �measuring vehicle  parameters using sensors. Example sensors include LIDA R, RADAR, and/or cameras. In some  implementations, the vehicle parameters can include an y or all of LIDAR data, RADAR data  and/or camera data.   [00154]     At step 256, the method can include determining, bas ed on the traffic  information and the vehicle parameters, a cooperative� �navigation solution. Optionally, the  cooperative navigation solution can include a vehicle� �velocity.  In some implementations, the  vehicle velocity is a velocity that avoids a potenti al collision.   MCC Ref. No.:  103361‐329WO1  [00155]     Alternatively or additionally, the cooperative navigati on solution can include  cooperative cruise control information. Alternatively o r additionally, the cooperative navigation  solution can include cooperative adaptive lane keeping  information. Alternatively or  additionally, the cooperative navigation solution compr ises cooperative collision avoidance  information. It should be understood that in differen t implementations of the present  disclosure the cooperative navigation solution can inc lude any combination of vehicle velocity,  adaptive lane keeping information, cooperative cruise  control information and/or collision  avoidance information.   [00156]     It should be appreciated that the logical operations� �described herein with  respect to the various figures may be implemented (1 ) as a sequence of computer implemented  acts or program modules (i.e., software) running on  a computing device (e.g., the computing  device described in FIG. 5), (2) as interconnected m achine logic circuits or circuit modules (i.e.,  hardware) within the computing device and/or (3) a c ombination of software and hardware of  the computing device. Thus, the logical operations di scussed herein are not limited to any  specific combination of hardware and software. The im plementation is a matter of choice  dependent on the performance and other requirements o f the computing device. Accordingly,  the logical operations described herein are referred  to variously as operations, structural  devices, acts, or modules. These operations, structura l devices, acts and modules may be  implemented in software, in firmware, in special purp ose digital logic, and any combination  thereof. It should also be appreciated that more or� �fewer operations may be performed than  shown in the figures and described herein. These ope rations may also be performed in a  different order than those described herein.  MCC Ref. No.:  103361‐329WO1  [00157]     Referring to FIG. 5, an example computing device 500  upon which the  methods described herein may be implemented is illust rated. It should be understood that the  example computing device 500 is only one example of� �a suitable computing environment upon  which the methods described herein may be implemented . Optionally, the computing device  500 can be a well‐known computing system including,  but not limited to, personal computers,  servers, handheld or laptop devices, multiprocessor sy stems, microprocessor‐based systems,  network personal computers (PCs), minicomputers, mainfr ame computers, embedded systems,  and/or distributed computing environments including a  plurality of any of the above systems or  devices. Distributed computing environments enable remo te computing devices, which are  connected to a communication network or other data t ransmission medium, to perform various  tasks. In the distributed computing environment, the  program modules, applications, and other  data may be stored on local and/or remote computer  storage media.   [00158]     In its most basic configuration, computing device 500  typically includes at  least one processing unit 506 and system memory 504.  Depending on the exact configuration  and type of computing device, system memory 504 may� �be volatile (such as random access  memory (RAM)), non‐volatile (such as read‐only mem ory (ROM), flash memory, etc.), or some  combination of the two. This most basic configuration  is illustrated in FIG. 5 by dashed line 502.  The processing unit 506 may be a standard programmab le processor that performs arithmetic  and logic operations necessary for operation of the  computing device 500. The computing  device 500 may also include a bus or other communic ation mechanism for communicating  information among various components of the computing� �device 500.   MCC Ref. No.:  103361‐329WO1  [00159]     Computing device 500 may have additional features/func tionality. For  example, computing device 500 may include additional  storage such as removable storage 508  and non‐removable storage 510 including, but not li mited to, magnetic or optical disks or tapes.  Computing device 500 may also contain network connect ion(s) 516 that allow the device to  communicate with other devices. Computing device 500  may also have input device(s) 514 such  as a keyboard, mouse, touch screen, etc. Output devi ce(s) 512 such as a display, speakers,  printer, etc. may also be included. The additional d evices may be connected to the bus in order  to facilitate communication of data among the compone nts of the computing device 500. All  these devices are well known in the art and need n ot be discussed at length here.   [00160]     The processing unit 506 may be configured to execute  program code encoded  in tangible, computer‐readable media. Tangible, compu ter‐readable media refers to any media  that is capable of providing data that causes the c omputing device 500 (i.e., a machine) to  operate in a particular fashion. Various computer‐re adable media may be utilized to provide  instructions to the processing unit 506 for execution . Example tangible, computer‐readable  media may include, but is not limited to, volatile  media, non‐volatile media, removable media  and non‐removable media implemented in any method o r technology for storage of  information such as computer readable instructions, da ta structures, program modules or other  data. System memory 504, removable storage 508, and  non‐removable storage 510 are all  examples of tangible, computer storage media. Example� �tangible, computer‐readable recording  media include, but are not limited to, an integrated  circuit (e.g., field‐programmable gate array  or application‐specific IC), a hard disk, an optica l disk, a magneto‐optical disk, a floppy disk, a  magnetic tape, a holographic storage medium, a solid� ��state device, RAM, ROM, electrically  MCC Ref. No.:  103361‐329WO1  erasable program read‐only memory (EEPROM), flash me mory or other memory technology,  CD‐ROM, digital versatile disks (DVD) or other opti cal storage, magnetic cassettes, magnetic  tape, magnetic disk storage or other magnetic storage  devices.  [00161]     In an example implementation, the processing unit 506  may execute program  code stored in the system memory 504. For example,  the bus may carry data to the system  memory 504, from which the processing unit 506 recei ves and executes instructions. The data  received by the system memory 504 may optionally be� �stored on the removable storage 508 or  the non‐removable storage 510 before or after execu tion by the processing unit 506.   [00162]     It should be understood that the various techniques  described herein may be  implemented in connection with hardware or software o r, where appropriate, with a  combination thereof. Thus, the methods and apparatuses  of the presently disclosed subject  matter, or certain aspects or portions thereof, may  take the form of program code (i.e.,  instructions) embodied in tangible media, such as flo ppy diskettes, CD‐ROMs, hard drives, or  any other machine‐readable storage medium wherein, w hen the program code is loaded into  and executed by a machine, such as a computing devi ce, the machine becomes an apparatus  for practicing the presently disclosed subject matter.  In the case of program code execution on  programmable computers, the computing device generally� �includes a processor, a storage  medium readable by the processor (including volatile  and non‐volatile memory and/or storage  elements), at least one input device, and at least  one output device. One or more programs  may implement or utilize the processes described in  connection with the presently disclosed  subject matter, e.g., through the use of an applicat ion programming interface (API), reusable  controls, or the like. Such programs may be implemen ted in a high level procedural or object‐ MCC Ref. No.:  103361‐329WO1  oriented programming language to communicate with a c omputer system. However, the  program(s) can be implemented in assembly or machine� �language, if desired. In any case, the  language may be a compiled or interpreted language a nd it may be combined with hardware  implementations.  [00163]     Examples  [00164]     The following examples are put forth so as to provi de those of ordinary skill in  the art with a complete disclosure and description o f how the compounds, compositions,  articles, devices and/or methods claimed herein are m ade and evaluated, and are intended to  be purely exemplary and are not intended to limit t he disclosure. Efforts have been made to  ensure accuracy with respect to numbers (e.g., amount s, temperature, etc.), but some errors  and deviations should be accounted for. Unless indica ted otherwise, parts are parts by weight,  temperature is in  ^C or is at ambient temperature, and pressure is at  or near atmospheric.  [00165]     Example 1:  [00166]     An example implementation of the present disclosure i ncludes a cooperative  navigation strategy for connected autonomous vehicles  operating at smart intersections. The  example implementation can achieve cooperative collisio n avoidance for enhancing the safety  and capacity of the intersection. The example impleme ntation was evaluated with cooperative  connected autonomous vehicles operating simultaneously  with non‐cooperative autonomous  vehicles. In the example implementation, beyond visual  range scenarios were evaluated to  reduce the vulnerable situations. Beyond visual range,  information is implemented by using the  data from the roadside units, autonomous intersection� �management system, smart traffic  lights, and onboard units. MATLAB/Simulink environments  were used to validate the  MCC Ref. No.:  103361‐329WO1  experimental implementation in a study of a simulatio n. The simulation results show the  separation time within the set upper and lower bound s. That can ensure that the ego vehicle  does not collide with others at the intersection. Th e cooperative collision avoidance algorithm  guides the ego vehicle as soon as the ego vehicle  comes in the range of the intersection service  area, which increases the safety and capacity of the  intersection. This strategy is comfortably  used for both an unsignalized and signalized intersec tion. In an unsignalized intersection  scenario, the ego vehicle uses an onboard unit. In  signalized intersection scenario, the ego  vehicle uses a roadside unit, onboard unit, autonomou s intersection management system, and  smart traffic lights. The example implementation can  be used to implemented connected  autonomous vehicles that can utilize the information  from smart infrastructure devices.  [00167]     Recent advancements in the automotive industry focus  on autonomous  vehicles. Technology innovations such as Vehicle to V ehicle (V2V) communication, Vehicle to  Infrastructure (V2I) communication, Vehicle to Cloud ( V2C), Vehicle to Pedestrian (V2P)  communication, and guidance, navigation, and control s ystem can provide a safe environment  for Connected Autonomous Vehicles (CAVs) and all road  users. Khayatian et al. (2020). As an  example, Smart Columbus is one of the major projects  supported by the U.S. Department of  Transportation (USDOT) to develop Columbus as a model  smart connected city for CAV’s to  improve people's quality of life, economic growth, su stainability, and safety Cocks and Johnson  (2021). Systems for traffic control including CAV’s� �can be categorized into two major domains:  (i) infrastructure development approach and (ii) vehic ular control approach for connected  autonomous vehicles. Technological development in infra structure related to the automobile  industry can include roadside computing and communicat ion devices including RSU’s, STL’s,  MCC Ref. No.:  103361‐329WO1  STS’s, AIM systems, Cloud Storage and Connectivity,� �and/or Automated Traffic Management  (ATM) System. An RSU is an edge computing device th at establishes the connection of  communication between vehicles and infrastructure. RSU� ��s can use the Dedicated Short Range  Communication (DSRC) channel to exchange information b etween infrastructure and vehicles.  Vehicular control approach‐based navigation can have� �many subsystems of the automatic  driving systems (way‐points positioning system, path� �planning system, lane‐keeping system,  etc.) that make vehicles smart enough to operate saf ely in a vulnerable environment. All  subsystems can be used to convert a vehicle into a� �Highly Automated Vehicle (HAVs) and/or a  Highly Smart Vehicle (HSVs) to operate in vulnerable� �environments or situations.  [00168]     From the above discussion, it is concluded that the� �efforts were made in the  direction of (i) infrastructure development approach,  which is developed only for the smart  intersection, and (ii) vehicular control approach, whi ch only works for the un‐signalized  intersection using V2" " V communication. Intersection  management strategies use a  reservation approach for CAVs, compromising the inters ection's capacity. On the other hand,  the vehicular navigation strategies mostly use the ga me theory approach for CAVs at the  intersection which compromises safety where beyond vis ual information is not available  Khayatian et al. (2020).  [00169]     The example systems and methods described herein can� �eliminate the  downsides of systems and methods that rely solely on  information from vehicles or information  from smart intersections. The example implementations  can use V2I and V2V information to  decide the efficient realization of systems in the s mart intersection and non‐smart  intersections. It can reduce the hazards due to hack ing and system failure in the vulnerable  MCC Ref. No.:  103361‐329WO1  environment and enhance the safety, and capacity of  CAVs operating at smart intersections.  The rapid development of smart cities required the p roposed cooperative navigation strategy  for CAV’s operating at the smart intersection.   [00170]     In the example implementation, safety can be achieved  using infrastructure  devices and vehicle sensors simultaneously by a coope rative navigation framework. Moreover,  in the example implementation, capacity and safety ca n be achieved by velocity optimization in  a cooperative collision avoidance algorithm.  [00171]     Operations over intersections can be particularly impo rtant because of the  large number of merge, diverge and cross conflict po ints. The present example includes a  cooperative position, navigation, and timing (PNT) sol ution for the ego vehicle based on other  vehicles operating at the same intersection. The exam ple navigation strategy includes  performing collision avoidance at the smart intersecti on. In the example implementation, the  smart intersection can be equipped with RSU, AIM, an d STL. Due to the presence of the  mentioned devices, the SPaT, intersection parameters,  MAP, time‐slots, and other lane vehicle  information are available for the ego vehicle. In th e example implementation, all actor vehicles  can be non‐cooperative vehicles. Actor vehicles only  share their velocity profiles and do not  respond to the other vehicle's actions. The ego vehi cle uses the information from all other  vehicles. The actor vehicle’s velocity profile and  distance can be used to generate the ego  vehicle velocity profile. This information can be use d to calculate the other vehicle's future path  with the time of arrival at the conflict point to  find potential conflicting situations. Problem  formulation has been done based on conflict points,  intersection parameters, and CAV's future  path.   MCC Ref. No.:  103361‐329WO1  [00172]     FIG. 6 shows an intersection scenario 600 that has  the three vehicles that are  at the intersection 610. in each lane and all have� �different directions to move that is straight,  right, and left turn. The leading vehicle in the  ^^ lane is the ego CAV 602a that has to follow th e  left turn path. A vehicle 602b in the  ^^ lane is another CAV that has to follow the stra ight path.  CAV in the  ^^ lane 602c has to follow the right turn, and CAV  in  ^^ lane 602d has to follow the left  turn. The intersection scenario 600 shown in FIG. 6� �generates two conflict points 620  concerning the latitude and longitude positions of th e ego CAV 602a, while in the time frame,  there are three conflicting situations. The actor veh icles are connected and automated, but  they may not have beyond visual range cooperativeness . The ego CAV 602a can share  information such as forward and rear lengths of the� �GPS receiver point, turn indication, the  width of the vehicle, the height of the vehicle, th e current position of the vehicle in terms of  latitude and longitude, the velocity at which its ap proaching intersection, and heading angle of  the vehicle. In the example studied, it is assumed  that all perception sensors were performing  well and generating relative positioning and speed in formation of other vehicles and their  surrounding obstacles. The scenario simulation only de als with the leading vehicles in lanes, but  the proposed solution can be implemented for other v ehicles in each lane.  [00173]     In the example study, a dynamic model of the vehicl e has been taken into  account in the simulation framework. The tire modelin g is used to depict the nonlinear  behavior of the vehicles Bian et al. (2014). The ef fects of tire slip with steering angle also  considered for the evaluation. (1) is the 3 ^^ ^^ ^^ mathematical modeling of CAVs operating at the  intersection. Dynamic modeling is referred and modeled  according to the SAE J670e standards  Code (1995).  MCC Ref. No.:  103361‐329WO1  ì ^{^^ ^¨^ ൌ ^^ ^^^ ^ ^ ^^ ^^ ^ ^^ ^^^^^ െ ^^ ^^^^^ ï} _{ï ^^൫ ^˙^^ ^௬ ^ ^^^ ^௫ ^˙^൯ ൌ ^^ ^^^ ^ ^ ^^ ^ ^^^^^ ^ ^^^^^}   ^^ is the yaw angle,  ^^ and  ^^ are the  forward and rear length of the vehicle from the cen ter of gravity,  ^^ _^  and  ^^ _^  are longitudinal  forces on the front and rear tires,  ^^ _^^  and  ^^ _^^  are lateral forces on the front and rear tir es,  ^^ is  the mass of the vehicle,  ^^ _௫  and  ^^ _௬  are longitudinal and lateral velocities,  ^^ and  ^^ are  longitudinal and lateral positions and  ^^ is the steering angle. '  ^^ ' represents the lane ID of the  intersection, and 'n' represents the vehicle ID. Simi lar indexes were used for other actors  vehicle dynamics, such as  ^^, ^^, and  ^^ for different lanes and  ^^ ൌ 1,2,3.. , ^^ for different vehicles.  The terms  ^^ ^^ _^ ^{^} ^  and  ^^ ^^ _^ ^{^} ^ _^  in (1) represent the effect of vehicle side‐slip.  It is necessary because  the vehicle operating at the intersection needs to t ake a 90‐degree turn. Since sideslip is the  product of lateral force with steering angle as show n in (1). Therefore, as the velocity of the  vehicle increases the side slip also increases Kim a nd Ryu (2011). Precise steering command  signals depend on the side‐slip of vehicle. It sho uld be understood that these example formulas  and models for the vehicles are intended only as no n‐limiting examples.   [00176]     In the example implementation, the intersection is mo deled in terms of  conflict points for each lane and path taken by the  vehicle. The selection of the way‐points is  crucial for the accurate calculation of conflicting s ituations. As shown in FIG. 6, if the selected  consecutive way‐points are far apart, the system ma y not calculate highlighted conflict points.  Since all vehicles can be connected, the ego CAV 60 2a can develop a set of way‐points for each  MCC Ref. No.:  103361‐329WO1  leading vehicle that can create a conflicting situati on. Hence, every next‐way point is spaced by  the length of the vehicle. Equation (2) shows the n umber of conflict points in a path for a  particular vehicle.  ^ ^{^ ோ} _^ ^ఏ [ _{00177]     ^} ^ൌ ^ ^{^} ^ _^ Γ _^ ^{^} ^ ^^ ^^ ^{^}  (2)  ^^ ^{^} ൌ _^ [00178]     Where  ^^ _^  is the left turn radius of the intersection.� �Γ _^ ^{^}  is a position where the  intersection starts.  ^^ ^{^} ^ is the length of the vehicle, and  ^^ _^ ^{^} follow the path.  one conflict point, it can enter the next conflict  point. This strategy provides all possible  conflicting points in a path. This can provide an a dvantage over techniques that produce only a  limited number of conflict points in an intersection� �[Milo (2020)], and [Cocks and Johnson  (2021)]. Equation (2) can generate conflict points fo r any configuration of intersection. The  value of the  ^^ range for the path is from 0 to 90 ^∘ . Therefore, the example modeled intersection  of Fig. 6 is in a perfect cross configuration, howe ver implementations of the present disclosure  can work for any type of intersection with the abil ity to avoid collision.  [00179]     Navigation based on smart infrastructure can rely on� �devices that share data  using the DSRC communication channel. This type of g uidance is prone to cyber security threat  issues. While navigation using onboard sensors does n ot provide beyond visual range  information. However, both pieces of information are  necessary for operations at the smart  intersection. The example cooperative navigation strate gy can use both (i) AIM, STL, and RSU  information and (ii) feedback from sensors simultaneou sly, to provide safe and effective  cooperative navigation at the intersection of smart c ities. A signalized intersection scenario is  MCC Ref. No.:  103361‐329WO1  described herein that has a single incoming lane on� �each side of the intersection as shown in  FIG 6. The number of vehicles in each lane is repr esented by a different group of vehicles as  shown in FIG. 6. The formulation maintains a safe d istance within the same group of vehicles  and simultaneously avoid conflicts between different g roups of vehicles. FIG. 6 shows the  potential conflict points over the signalized intersec tion of the simulation scenario highlighted  by a circle. FIG. 1B shows an overview of cooperati ve navigation, guidance, and control system  100 that depicts the flow and type of information t hat can be exchanged between RSU and  OBUs of the vehicle. The vehicle control system 136� �can use all actor vehicles, ego vehicle, and  environmental parameters to calculate optimized velocit y for the ego vehicle which avoids  conflict in the vulnerable scenario. Velocity is used  by the path following block to generate  actuation command to vehicle dynamics block. Current  state values are feedback to path  following and send to OBU for cooperation with other  vehicles. The cooperative collision  avoidance algorithm uses other vehicle information suc h as position, velocity, length, width,  heading angle, lane identity, and turn indication of� �vehicle. The cooperative collision avoidance  algorithm resolves the conflict point between all lea ding vehicles from each lane and within the  lane vehicle.  [00180]     Collision avoidance algorithms (e.g., Huang et al. (2 021), Bifulco et al. (2021),  and Wang et al. (2021)) can be implemented as part� �of an onboard computing system. The  onboard computing system can access information from  roadside communications devices such  as AIM, RSU, and STL available at a smart intersect ion. If two of the vehicles have a common 3 ^^  positioning such as [lat, long, time] at any timesta mp they will collide. The cooperative collision  avoidance system calculates the desired velocity to a void conflicts. Once the algorithm  MCC Ref. No.:  103361‐329WO1  optimizes the velocity, it can share the velocity to  the path following algorithm and repeat the  process throughout the simulation. This can generate  the velocity profile at which the vehicle  follows its path across the intersection. The surroga te optimization fulfills the two basic  requirements of real‐time optimization in automotive� �applications. Surrogate optimizations can  require less time to optimize a solution and can fi nd an optimal solution for the problem. In the  proposed framework, SPaT information from STL,  ^^ _^ , and turn indication  ^^ _^ ^{^}  from the vehicle is  the standard requirement to optimize the ego vehicle� �velocity. Surrogate optimizes the function  within a bounded range defined by the scenario. The� �algorithm constructs a surrogate as an  interpolation of the objective function by using a r adial basis function (RBF) interpolator Xu et  al. (2018). RBF interpolation has several convenient  properties that make it suitable for  constructing a surrogate. Evaluating an RBF interpolat or can be performed quickly, which can  be an essential requirement for an automotive system.   [00181]     The objective function defines in terms of the time� �of arrival, traveling time,  and phase time of the signal. In (3) "  ^^ _^ ^{^}  " is the time vehicle takes to travel from  its current  position to the next waypoint.  ^ ^{^^} _ି௫ ^{^} [00182]     ^ ^^ _^ ^{^} ൌ _^భ ^ ^^ _^ ^{^}  (3)       separation time of CAV respectively.  ^^ _^ ^{^}  is also the function of vehicle parameters as  a vehicle  having a larger size in length needs more separation  time than a shorter vehicle. So the conflict  situation can arise when  ^^ ^{^ ^} ^ ൌ ^^ _^  at any particular timestamp.  [00184]     Let  ^^ be the difference in time of arrival from ego v ehicle to another vehicle at  the intersection. Therefore, the objective function in  Eq. (4) is used to minimize the  ^^ for all the  MCC Ref. No.:  103361‐329WO1  vehicles at the intersection by using information fro m AIM, RSU, and OBUs. FIG. 52 illustrates  an example algorithm for performing cooperative collis ion avoidance.   ì ^{^^} _^ ^{^ ൌ ^ ^^หூ^ ^ ି^^ห} ^ ^^ _^ ^{^} ^ ^^ _^ ^{^} ^ െ ^^ ^{หூ^శభ ^ ି^^ห} ^ ^^ _^ ^{^ା^} ^ ^^ _^ ^{^ା^} ^^ ï ^{^} ^^ ^{หூ^ ^ ି^^ห}  is the conditional check on the vehicle to f ollow the intersection SPaT information. If  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ ^{^^ା^^} ^  the ego vehicle will collide with any of the  four vehicles. Ego CAV velocity is one control varia ble to avoid collision and following path. (4)  contains all the parameters that are received by ano ther vehicle in V2V communication.  However, this cost function has an upper and lower  bound to prevent unwanted delay and  excessive speed while CAVs operate at the intersectio n. (5) shows the formulation of upper and  lower bound constraints.  ^ ^{^^^^} ౮ ^ ^{^ ^^^౮} ^ _{^ ^} ^^ _^ ^ _^^^^ (5) ^^ _୫୧୬ ൌ 1 m and  ^^ _୫ୟ^ ൌ 7 m is the separation distance and  ^^ _min   and  ^^ _୫ୟ^  is the upper and lower limit of ego velocity .  [00187]     In the study, the cooperative navigation, guidance, a nd control strategy of an  example implementation of the present disclosure was  implemented on a simulated Ego  Vehicle using a MATLAB/Simulink environment. Five vehi cles simulated one actor vehicle in  each lane and one ego vehicle in lane '  ^^ ', as shown in FIG. 6.  ^^ is the separation time between  ego vehicle and actor vehicles.   MCC Ref. No.:  103361‐329WO1  [00188]     The separation time shown in FIGS. 7, 8, and 9 sho w different actor vehicles in  a scenario. The separation times shown in FIGS. 7,  8, and 9 are relative to the ego vehicle, so  the ego vehicle is not shown in FIGS. 7‐9.   FI G. 7 shows V2V cooperation, FIG. 8 shows V2V and  AIM cooperation, and FIG 9 shows V2V, AIM, and STL� �cooperation. Simulation results show the  effectiveness of the example implementation of an opt imization and control framework by  ensuring the values of the upper and lower bound co nstraints as defined in Eq. (5). FIG. 7 shows  the plot for the cooperative collision avoidance resu lt discussed in a scenario where only V2V  cooperation is available. The vertical axis shows the  separation time concerning the ego vehicle  at the conflict point identified by the cooperative  collision avoidance algorithm. The horizontal  axis is the sample for each second during the simul ation. Non‐zero value of actor vehicle shows  that at any instant, ego vehicle and actor vehicle  do not collide based on velocity profile  followed by actor vehicle and optimized velocity foll owed by ego vehicle. Negative value shows  that the actor vehicle passes before the ego vehicle  at a potential conflict point.   [00189]     In FIG. 7, the interval between 10 to 18 shows tha t the ego vehicle crosses the  conflict point much earlier than the actor vehicle.  The ego vehicle tries to maintain the least  possible separation distance that also ensures the in crease in intersection's capacity with  safety. FIG. 8 shows a cooperative collision avoidanc e result discussed in a scenario where V2V  and AIM cooperation is available. In the simulation  represented by FIG. 8, all actor vehicles pass  after the ego vehicle as the time stamp provided to  the ego vehicle is much earlier than the  actor vehicle. FIG. 9 shows the cooperative collision  avoidance result discussed in a scenario  where V2V, AIM, and STL cooperation is available. Mo re separation time between each actor  vehicle and ego vehicle shows that SPaT information  also provides collision avoidance to CAV.  MCC Ref. No.:  103361‐329WO1  [00190]     Since vehicles can enter and leave the intersection  at a much faster speed,  therefore, time spent by the vehicle at the intersec tion is less than the scenario where vehicles  use V2V communication only. This in turn increases t he throughput of the intersection. FIG. 10  shows the quantitative analysis for actor 1. FIG. 11  shows the quantitative analysis for actor 2,  and FIG. 12 shows the quantitative analysis for acto r 3. The time column in FIGS. 10, 11, and 12  show the reference time when actor vehicles collide  with ego vehicles in a scenario where no  cooperation is done between vehicles. The tables illu strated in FIGS. 10, 11, and 12 show the  level of cooperation of the ego vehicle. In the pos ition column, different position at the same  time stamp at different cooperation level shows that� �the ego vehicle mange to avoid collision  and move faster than when there is no cooperation.  Where actors 1, 2, and 3 had conflicting  situations at simulation times of 12, 18, and 16 se conds respectively. Actor 4 is in the same lane  as the ego vehicle, therefore, it maintains a safe  distance throughout the trajectory.  [00191]     The efficacy of the path following algorithm is show n in FIG. 13. As the path  following algorithm receives guidance from the coopera tive collision avoidance algorithm, it  starts tracking the desired velocity. FIG. 13 shows  that the ego vehicle is following the reference  velocity profile while crossing the intersection. Velo city tracking results show that cooperative  collision avoidance algorithms provide different veloci ty profiles in different scenarios.  Cooperative collision avoidance reference velocity prov ided by V2 V cooperation only is the  slowest velocity profile to operate safely at the in tersection and avoid the collision. The  reference velocity profile provided by V2 V and AIM� �Cooperation slightly increases the velocity  of the ego vehicle within the bounds of safety limi ts provided by AIM which gives an ego vehicle  an edge to move faster than it is moving in V2 V� �cooperation. The reference velocity is at its  MCC Ref. No.:  103361‐329WO1  maximum value when all V2 V, AIM, and STL cooperati on is available, hence giving maximum  throughput. Therefore, the example cooperative navigati on, guidance, and control strategy  increase the throughput with safety.   [00192]     The study shows that the example implementation allow s the CAV to behave  intelligently and cooperate with other vehicles while� �passing through a smart intersection. The  simulations of the example implementation of a cooper ative navigation algorithm used  infrastructure information with sensor feedback. The e xample implementation of a cooperative  navigation Algorithm improved safety and intersection  capacities while operating at the smart  intersection. The efficacy of the example implementati on was evaluated and validated by static  environmental parameters, which will be extended to t he dynamic environment in the future.  This work can also be extended to explore the actio n of CAVs in presence of threats. While the  example implementation was applied to an example inte rsection, it should be understood that  the systems and methods described herein can be appl ied to other scenarios including CAVs  having cooperative navigation technology.  [00193]     Example 2:   [00194]     A study was performed on communications and sensing  that can be  implemented by the present disclosure. An example lis t of sensors and sources that can be  used by different highly automated transportation syst ems (HATS) including positioning,  navigation, and timing (PNT) information is illustrate d in FIG. 14.  FIG. 15A illustrates an  example schematic of a communication system that can� �be used in implementations of the  present disclosure. FIG. 15B illustrates examples of  near space navigation and far space  navigation systems, according to an implementation of� �the present disclosure. FIG. 16  MCC Ref. No.:  103361‐329WO1  illustrates PNT sensors and sources along with possib le threats and vulnerabilities, according to  implementations of the present disclosure.  FIG. 17  illustrates an example of radar interference  that can occur in a smart intersection, according to  an implementation of the present  disclosure. FIG. 18 illustrates an example of a simu lated smart intersection, according to an  implementation of the present disclosure.   [00195]     Example 3:   [00196]     Another study was performed on an example implementat ion of the present  disclosure. The study evaluated PNT solutions in adve rse cyber‐security scenarios for HAVs  operating at smart intersection. The example implement ation can reduce conflicting situations  at the smart intersection where infrastructure can ex perience jamming and interferences from  cyber‐attacks, avoid collisions and enhance safety i n adverse Cyber‐Security situations, and/or  follow a path with optimal speed and enhance the ca pacity of a smart intersection  [00197]     The example implementation included a scenario with 3  communication  devices: Vehicle to Vehicle (V2V), Autonomous Intersec tion management (AIM) and Smart  traffic Light (STL). FIG. 1A illustrates an example  cooperative navigation system that was used  for the study, and FIG. 2A illustrates an example c ooperative collision avoidance algorithm that  was used in the study. The study included an Object ive Function for C‐CAS:  [00198]     ζ ^୬ ୧ ൌ หe ^{|୪^ି^^|} ^f _୧ ^୬ ^ T _୧ ^୬ ^ െ e ^{|୪^ି^^|} ^f _୧ ^{୬ା^} ^ T _୧ ^{୬ା^} ^ห       [00201]     ^^ _^ ^ା ^ ^^ _^ ^ା ^ ℵ ^ା ^ ≤  ^^ _^     MCC Ref. No.:  103361‐329WO1  ష      ^{^ శ ష శ} [00202] ^{^^^ ^^ି ^^^^^^ ା ା ା ^^^^^^ି ^^^^^^} ௩ _^ೌ^ ≤ ^^ _^ ^ ^^ _^ ^ ℵ _^ ≤  _{௩^^^    ^^^} ^{ା^} _^^ ^{^}  _is the  same conflict point vehicle leaves.   [00206]     The study included a dynamic model of CAVs: SAE‐J6 70e  [00207]     Longitudinal velocity: x^ _୧ ^୬ ^ ൌ x _୧ ^୬ ଶ cos൫x _୧ ^୬ ହ൯ െ x _୧ ^୬ ସ sin^x _୧ ^୬ ହ^  [00208]     ^{^^} ୧ ^{^ା ^ ^ ^ ^^౨ି^^ ↑^ ୬ ୬} ଶ ൌ _୫ െ x _୧ସ x _୧^   [00209]     Lateral velocity: x^ _୧ ^{୬ ୬} ଷ ൌ x _{୧ସ ଶ} [00210]     Lateral acceleration: x^ _୧ ^{୬ ^^ ^ ^ ^ ^^ஔ^ା^^↑^ା^^↑౨ ୬ ୬} ସ ൌ _୫ െ x _{୧ ଶ} x _{୧ ^}   [00211]     Heading rate: x^ _୧ ^{୬ ୬} ହ ൌ x _{୧ ^}   ୟ ^{^^ ஔ^ାୠ^^ ିୠ^^} [00212]     Heading angular acceleration : x^ _୧ ^{୬ ^^ ^ ^ ↑^ ^↑౨} ^ ൌ _୍   [00213]     The states used in the example objective function we re:  longitudinal velocity,  lateral velocity, and heading rate. The example colli sion avoidance algorithm found solutions of  defined conflict points for the ego vehicle. The exa mple objective function ensured the time  separation between ego vehicle and other vehicle by  adjusting the ego vehicle speed.  [00214]     The capacity of the intersection is ensured by the  increased in velocity while  crossing intersection as the level of cooperation inc reases. FIGS. 21‐24 illustrate experimental  results.   MCC Ref. No.:  103361‐329WO1  [00215]     FIG. 21 illustrates the velocity of different simulat ed vehicles as a function of  time, according to an example implementation of the  present disclosure.   [00216]     FIG. 22 illustrates steering angles of simulated vehi cles when V2V, Aim, and/or  STL are used in the example implementation of the p resent disclosure.  [00217]     FIG. 23 illustrates acceleration when V2V, Aim, and/o r STL are used in the  example implementation of the present disclosure.  [00218]     FIG. 24 illustrates 3D positioning of HAVS in jammin g scenarios, according to  an example implementation of the present disclosure.  Implementations of the present  disclosure can be configured to analyze cyber‐securi ty threat scenarios including information  denial or jamming, patching information, false informa tion or spoofing, and/or asynchronous  timing. FIG. 25 illustrates another example of 3D‐p ositioning of HAVs in jamming and  interference scenarios.  [00219]     FIG. 26 illustrates additional results from the study . FIG. 26 illustrates a safety  result showing that patchy information related to act or 2’s velocity changes the separation  time. The separation time can decrease, but the syst em still avoids a collision.   [00220]     FIG. 27 illustrates capacity result showing that patc hy information related to  actor’s 2 velocity also changes the CA velocity ou tput, but the velocity profile remains the same  with some chattering.  [00221]      FIG. 28 illustrates a qualitative analysis of jammi ng and interferences,  according to an example implementation of the present  disclosure.   [00222]     FIG. 29 illustrates a capacity result for different  communication systems,  where velocity is plotted as a function of time.  MCC Ref. No.:  103361‐329WO1  [00223]     FIG. 30 illustrates a capacity result for different  communication systems,  where the steering of a vehicle is plotted as a fu nction of time.  [00224]     FIG. 31 illustrates a capacity result for different  communications systems,  where the acceleration of a vehicle is plotted as a  function of time.  [00225]     FIG. 32 illustrates a capacity result for different  communications systems,  where the acceleration of a vehicle is plotted as a  function of time.  [00226]     Example 4:  [00227]     Another study was performed of an example implementat ion including a  methods and systems for safety testing and validation  of Highly Automated Vehicles (HAVs) by  using cooperative navigation at the smart intersection s. The example implementation can  enhance the safety of the intersection. The purposed� �methodology can allow HAVs to safely  navigate through intersections while operating with no n‐cooperative vehicles. A significant  challenge of this context is that city intersections� �are often complex environments where  onboard sensors may not be able to detect all relev ant information, such as vehicles or  pedestrians behind obstructions. To address this issue , the proposed approach uses beyond‐ visual range information from vehicles that are trans mitted via an everything communication  network. This allows HAVs to perceive their surroundi ngs and make safer navigation decisions.  The cooperative navigation of HAVs is achieved throug h the use of data from various sources,  including RSU’s, OBU’s, AIM systems, and STL’s.� �The example implementation includes several  features, including cooperative collision avoidance (CC A), cooperative cruise control ^CCC^, and  cooperative adaptive lane keeping (CALK). In addition,  HAVs are able to follow predefined paths  using model predictive control. In the example implem entation each vehicle is an independent  MCC Ref. No.:  103361‐329WO1  agent, makes its own decision based on the informati on available from the vehicle to the  everything communication network, and uses a mathemati cal model to predict future behavior  for optimized navigation solutions. The study tested  the performance of the cooperative  navigation framework, including with an example scenar io in which HAVs operate at a smart  intersection. The results shown herein show that safe ty can be ensured in a dynamic scenario.   [00228]     Autonomous vehicles can rely on a range of technolog ies, including vehicle‐to‐ vehicle ^V2V^ communication, vehicle‐toinfrastructure  (V2I) communication, vehicle‐to‐cloud  (V2C) communication, and vehicle‐to‐pedestrian (V2P)  communication, to operate safely in an  environment. In addition, guidance, navigation, and co ntrol systems are essential for ensuring  the safety of HAVs and all road users [1c]. To adv ance the growth of autonomous systems,  investment opportunities have been established by gove rnment agencies for automotive  manufacturers, technology companies, and research insti tutes. An example is the Smart  Columbus project, which seeks to turn Columbus into  a shining example of a smart connected  city for HAVs. This project aims to enhance the qua lity of life, economic prosperity,  sustainability, and safety in Columbus through the in tegration of HAVs [2c]. Researchers and  scientists are making substantial contributions to the  creation of a secure and highly  dependable autonomous system for smart cities. There  are several navigation methodologies  used in different applications. Since HAVs are able  to communicate with each other and their  surrounding infrastructure in order to improve their  navigation and decision‐making abilities.  [00229]     There are several methodological frameworks for the c ooperative navigation  of HAVs, including:  MCC Ref. No.:  103361‐329WO1  [00230]     Hierarchical Control: In this approach, a central con troller coordinates the  movements of multiple HAVs, taking into account the  overall traffic flow and the individual  objectives of each vehicle [3c]. HAVs longitudinal ve locity are depends on central control  system its mean that malicious actor can disturbed c omplete traffic flow by just interfering  centralized control system.  [00231]     Game‐theoretic approaches: These frameworks use princ iples from game  theory to model the interactions between HAVs and to  design strategies for cooperation [4c]. It  increases the computational complexity and based on a ssumption of others behavior which  may not be reliable in vulnerable situations.  [00232]     Multi‐agent systems: In this approach, each HAV is� �modeled as an  independent agent that is able to make its own deci sions based on local information and  communication with other HAVs [5c]. Multi‐agent syst ems are flexible, scalable, robust,  decentralized, adaptable, and facilitate collaboration  among agents. These properties make  them well‐suited for complex tasks and allow for m ore efficient use of resources, adaptability  to changing circumstances, and improved performance, b ut there is no literature that discusses  its application in intersection scenarios. Distributed� �optimization: This approach involves  designing algorithms that allow HAVs to communicate a nd coordinate their movements in  order to optimize some global objective, such as min imizing fuel consumption or travel time  [6c]. The implementation of a distributed optimization  navigation system at a signalized smart  intersection requires a different framework and V2X c ommunication, as the current approach  focuses on unsignalized intersections. To effectively  navigate a signalized intersection, a system  that incorporates V2X communication and a tailored fr amework can be developed.  MCC Ref. No.:  103361‐329WO1  [00233]     Machine learning: Machine learning algorithms can be  used to predict the  behavior of other HAVs and to optimize the navigatio n of a HAV based on this prediction [7c].  Machine learning in HAV navigation may suffer from o ver‐fitting and poor generalization, as  well as a lack of transparency and explain‐ability� �in decision making. Additionally, collecting and  labeling the necessary data for training can be a t ime consuming and costly process.  [00234]     Decentralized control: In this approach, each HAV mak es its own navigation  decisions based on local information and communication  with its immediate neighbors, without  the need for a central controller [6c]. Decentralized  navigation in HAVs has several advantages,  including increased scalability, flexibility, and robus tness, as well as reduced risk of a single  point of failure and improved resource utilization. A dditionally, decentralized navigation  enables collaboration between vehicles and allows for� �continuous improvement through  learning and adaptation.   [00235]     Model‐based predictive control: This approach involve s using a mathematical  model of the HAV's dynamics to predict its future b ehavior and optimize its navigation [8c].  Model predictive control (MPC) is a control strategy� �for HAVs navigation that can handle  constraints and optimally balance multiple objectives.� �MPC uses a model of the system to  predict its behavior over a future horizon and gener ates control inputs that optimize a  performance criterion based on the predicted behavior.    [00236]     Consensus‐based approaches: These approaches involve  designing algorithms  that allow HAVs to reach a consensus on their navig ation decisions through iterative  communication and negotiation [9c]. One of the main  drawbacks of a consensus‐based  approach in HAV navigation is that it may not be e fficient in handling large amounts of data in  MCC Ref. No.:  103361‐329WO1  real‐time. This is because each vehicle needs to e xchange information with every other vehicle  in the system, which can lead to increased communica tion overhead and decreased  performance. Additionally, the consensus process can b e vulnerable to errors or attacks, which  can compromise the reliability of the navigation syst em.  [00237]     Graph‐based methods: These methods involve representi ng the HAVs and  their environment as a graph, and using graph theore tic techniques to optimize the navigation  of the HAVs [10c]. The graph‐based navigation syste m has some limitations, such as the  difficulty of handling real‐world scenarios with unp redictable elements, and the computational  complexity of constructing and solving the graph. Thi s can limit the efficiency and accuracy of  the navigation system.  [00238]     Reinforcement learning: Reinforcement learning algorithm s can be used to  learn optimal navigation strategies for HAVs through  trial‐and‐error [11c]. Reinforcement  learning has some limitations including difficulty in� �modeling complex environments, lack of  interpret‐ability, and the need for a large amount� �of data and computational resources.  Additionally, it can be difficult to ensure safe and  reliable behavior in real‐world applications  due to the trial‐and‐error nature of reinforcement  learning.  [00239]     The example implementations of the present disclosure� �includes  methodological frameworks that combine multi‐agent sy stems, decentralized control, and  model‐based predictive control framework used for HA Vs navigation. In the example  implementation each HAV can be an independent agent,� �make its own decision based on the  information available from the vehicle to everything  (V2X) communication network, and/or use  a mathematical model of HAV to predict future behavi or and optimize navigation solutions.  MCC Ref. No.:  103361‐329WO1  [00240]     Implementations of the present disclosure can be immu ne to interference in  single agent systems and requires less computational  power compared to machine learning  navigation frameworks. In a signalized smart intersect ion scenario, where only leading vehicles  collaborate to cross the intersection, the consensus  based approach may not be appropriate.  The graphical approach and reinforcement learning requ ire a large amount of data exchange  through V2X communication channels, which is not nece ssary in the proposed methodology,  but can pose challenges in real‐time scenarios.  [00241]     The study simulated results using an example intersec tion scenario 600,  illustrated and described with reference to FIG. 6.   In this study, the intersection scenario 600  was studied with HAVS. This intersection features adv anced technology such as RSUs, AIM  systems, and STL with short‐range communication tech nologies (DSRC). RSUs serve as edge  communication devices that transmit information about  the infrastructure and receive basic  safety messages (BSM) from vehicles. AIM is an inter section management system that  synchronizes multiple connected intersections in an ar ea to enhance the capacity, and safety at  intersections and provide time slots for HAVs approac hing an intersection to optimize fuel  consumption at the smart intersection. STL is a smar t traffic light system that can be controlled  signal, phase, and time (SPaT) information according  to the situation by the autonomous  management system. The vehicles in this scenario shar e information about their state, such as  their current position in terms of latitude and long itude, velocity, heading angle, and  dimensions. The vehicles also share information about� �the GPS receiver location point and the  status of the turn indicator. It is assumed that th e vehicles' perception sensors are functioning  correctly and providing accurate relative positioning  and speed information about other  MCC Ref. No.:  103361‐329WO1  vehicles and any surrounding obstacles. The present e xample considers the leading vehicles in  each lane. However, it should be understood that the  example implementation can be  extended to other vehicles in the same lane. This a llows the vehicle to have a better  understanding of the situation in the smart intersect ion and make critical decisions accordingly.  [00242]     FIG. 6 illustrates a smart intersection scenario equi pped with RSU, AIM, and  STL. HAVs operating at the smart intersection have O BU to communicate through V2 V and V2I  communication networks. FIG. 6 shows an intersection  scenario with three vehicles in each  lane, all moving in different directions (left turns,  right turns, and straight). The lead vehicle in  lane "i" is a HAV that must take the left‐turn p ath, with the ego vehicle following behind.  Meanwhile, the HAV in lane "j" must continue straigh t, the HAV in lane " k " must make a right  turn, and the HAV in lane "l" must also make a le ft turn. This scenario generates two conflict  points in terms of the ego vehicle's latitude and l ongitude positions, and three conflicting  situations in the given time frame. The other vehicl es are automated but do not have  cooperative capabilities for beyond visual range infor mation. The purpose of this scenario is to  test the proposed cooperative navigation framework in� �a complex situation and evaluate its  impact on the safety and efficiency of the intersect ion for all vehicles.  [00243]     Cooperative navigation is a method that can be used� �by multiple autonomous  agents, such as robots or drones, to navigate and a ccomplish tasks together. In a cooperative  navigation system, the agents work together to achiev e a common goal while taking into  account the actions and positions of the other agent s. This allows them to coordinate their  actions and make efficient use of their resources, s uch as sensors (Radar, Camera, GPS, INS, and  Lidar) or communication channels (V2V, V2I, V2P, V2C,  and V2X). Cooperative navigation can be  MCC Ref. No.:  103361‐329WO1  used in a variety of applications, such as search a nd rescue, surveillance, and exploration. In the  automotive industry, it is used to enhance the safet y, capacity, and fuel efficiency of HAVs  especially when they are operating at the smart inte rsection. The proposed Methodological  framework is inspired by a multi‐agent system, Dece ntralized control, and Model predictive  control. As a multi‐agent system, and decentralized� �control provides robustness, flexibility,  scalability, efficiency while MPC can handle constrain ts, multiple objectives, multivariable  nonlinear system, and also handle the uncertainty of� �the system. Therefore the present  disclosure includes mixed approaches including any/all� �of these capabilities.  [00244]     The illustration in FIG. 3A presents a visual repres entation of an example  cooperative navigation methodology applied in a system  300, including the flow and type of  information exchanged between smart infrastructure and� �HAVs. The CCC component makes  use of all relevant information from the other vehic les on the road, the ego vehicle, and  environmental factors to determine an optimized veloci ty for the ego vehicle, enabling it to  safely navigate through potentially hazardous scenarios . Optimized velocity can be shared with  the path‐following system 134 along with its sub‐ systems CCC and CALK. Cooperative cruise  control can provide the adaptive velocity according t o the scenario and lead vehicle, while  cooperative lane‐keeping provides the steering comman d according to the predefined path and  current scenario of the ego vehicle. These signals a re passed to the model predictive control  system 320 and the model predictive control system 3 20 can predict the future of the ego HAV  for the defined scenario based on HAV dynamic model� �and generate the optimized adaptive  control signals to perform the safe operation at the  smart intersection. In this framework, only  the GNSS and INS are used for the positioning of t he ego vehicle. All other information was  MCC Ref. No.:  103361‐329WO1  shared through the V2X communication network. The ini tial version of this framework was  published before that has the capability of a cooper ative collision avoidance system and path‐ following system based on information coming from the  V2X communication network [12].  [00245]     Eq.1 describes the mathematics used in the example s ystem and method.  ì ^{^^} _^ ^{^ ൌ ^ ^^หூ^ ^ ି^^ห^} _^^^ ^{^} _{^ ^^^} ^{^^} _{െ ^^} ^{หூ^శభ ^ ି^^ห^} _^^^ ^{^ା^} _{^ ^^^} ^{^ା^^} _^   ^^ ^{หூ^ ^ ି^^ห}  is the conditional check on the vehicle to f ollow the intersection SPaT information.  ^^ _^  is  ^^ _^ ^{^}  is the HAVs indication variable  to follow the desired path (left, right, and straigh t). In the proposed framework, the velocity of  the ego HAV is an essential control variable to avo id collisions and stay on a predetermined  path. Equation (1) shows how the cost function for  each vehicle is calculated, incorporating all  parameters received through V2V communication. However,  to avoid unnecessary delays and  excessive speeds while the HAVs navigate the smart i ntersection, the cost function has been  restricted by upper and lower bounds, as indicated b y the second expression in (1). Where  ^^ _୫୧୬ , ^^ _୫ୟ^  Cooperative adaptive cruise control received th at optimized velocity profile as the  output from the first and second expression based on  lead vehicle velocity and another smart  intersection parameter. Since there is no sensor info rmation involved in this framework,  therefore, lead vehicle velocity is received from the  V2V communication network. Third  expression in 1 is the Adaptive cruise control expre ssion where  ^^ _ego  , ^^ _rel  , and  ^^ _lead   is ego  MCC Ref. No.:  103361‐329WO1  vehicle velocity, relative velocity, and lead vehicle� �velocity respectively. fourth expression is  used to maintain a safe minimum distance where  ^^ _^  is the safe minimum spacing between lead  vehicles and  ^^ _௧  is the minimum time gap between ego and the� �lead vehicle. The fifth expression  in equation 1 is for adaptive lane‐keeping where  ^^ _^ , ^^ _^ , and  ^^ _^  is ego vehicle relative yaw angle,  ego vehicle heading angle, and lane centerline angle� �respectively. the sequence of flow of  information in a purposed methodology is as follows:� � [00248]     Step 1: Collect information from infrastructure device s. Non‐limiting example  infrastructure devices include AIM, RSU, and STL.   [00249]     Step 2: Scan the number of lanes and the number of  vehicles in each lane.   [00250]     Step 3: Extract time slot " ^^ _^ ^{^} ", " ^^ _^ ^{^} ", ^^ _^ ^{^} ", ^^ _^ ^{^} " information for each vehicle from  AIM data  [00251]     Step 4: Extract SPAT information  ^^ _^ , ^^ _^ , ^^ _^ , ^^ _^  from STL  [00252]     Step 5: Extract vehicle states  ^^ _௫^ ^{^} , ^^ _௬^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} ,  ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , from  OBU through V2 V communication channel  [00253]     Step 6: Cooperative collision avoidance algorithm uses  the information to  generate a collision‐free optimized velocity profile.   [00254]     Step 7: CCA calculates the conflict point for other� �actor vehicles operating at  the intersection.  [00255]     Step 8: if collision exist based on followed velocit y profile CCA optimizes the  velocity profile using the Surrogate optimization tool .  [ ^{00256]     Step 9: CCA ensures the safe separation  ^^} _^ ^{^, ^^} _^ ^{^, ^^} _^ ^{^,  ^^} _^ ^{^ should be greater than}  _0.7 s.  MCC Ref. No.:  103361‐329WO1  [00257]     Step 10: based on safe distance Optimized velocity p rofile is fed into the  cooperative cruise control system.  [00258]     Step 11: Cooperative cruise control generates the fol lowing velocity based on  feedback from inertial sensors, lead vehicle velocity,  and optimized velocity from the  cooperative collision avoidance algorithm.  [00259]     Step 12: The reference and lead velocity are input  into an MPC system (e.g.,  the model predictive control system 320 shown in FIG . 3A) and, based on predictions of the  near future, the MPC control can adjust the ego veh icle velocity.  [00260]     Step 13: Simultaneously, the cooperative lane‐keeping  algorithm received  information from infrastructure devices and generated  a heading angle '  ^^ _^ ^ᇱ  and lane curvature  angle  ^ᇱ ^^ _^ ^ᇱ  to follow and maintain the lane center.  [00261]     Step 14: Cooperative lane‐keeping algorithm gets the  feedback from the  inertial sensor and feeds the steering angle to the� �MPC system.  [00262]     Where  ^^ _^ ^{^} ^^ _^ ^{^} ^^ _^ ^{^} ^^ _^ ^{^}  is the time slot of  ^^ ^{௧^}  vehicle in lane  ^^, ^^, ^^, and  ^^  respectively provided by AIM to manage the capacity  and safety of the intersection.  ^^ _^ , ^^ _^ , ^^ _^ , ^^ _^   is the smart traffic signal phase information for ea ch lane  ^^, ^^, ^^, and  ^^ respectively according to  the simulation reference time frame.  ^^ _௫^ ^{^} , ^^ _௬^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^}  is the  longitudinal velocity, lateral velocity, steering angle , heading angle, front tire distance from the  center of gravity ^CG^, rear tire distance from CG,� �longitudinal position coordinate and lateral  position coordinate and turn indicator respectively fo r  ^^ ^{௧^}  vehicle in lane  ^^. ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^} , ^^ _^ ^{^}  is the  separation between ego and  ^^ ^{௧^}  actor vehicles in lane  ^^, ^^, ^^, and  MCC Ref. No.:  103361‐329WO1  [00263]     The example implementation includes a mathematical fra mework for  performing cooperative navigation. In Eq. 1A, the obj ective function defines in terms of the  time of arrival, traveling time, and phase time of  the signal. In (1A) "  ^^ _^ ^{^}  " is the time vehicle  takes to travel from its current position to the ne xt waypoint.  ^ ^{^^} _ି௫ ^{^} ì ^{^^} _^ ^{^ ൌ} _{^భ ^^} ^{^} ^ ^^ _^ ^{^}   separation time, and conflict point of CAV respective ly.  ^^ _^ ^{^}  is also the function of vehicle  parameters as a vehicle having a larger size in len gth needs more separation time than a  shorter vehicle. So the conflict situation arises whe n  ^^ _^ ^{^} ൌ ^^ ^{^} ^ at any particular timestamp. Let  ^^  be the difference in time of arrival from the ego  vehicle to another vehicle at the intersection.  Therefore, the objective function in Eq. (2) is used  to minimize the  ^^ for all the vehicles at the  intersection by using information from AIM, RSU, and� �OBUs.  ì ^{^^} _^ ^{^ ൌ ^ ^^หூ^ ^ ି^^ห^} _^^^ ^{^} _{^ ^^^} ^{^^} _{െ ^^} ^{หூ^శభ ^ ି^^ห^} _^^^ ^{^ା^} _{^ ^^^} ^{^ା^^} _^        , , system.  ^^ ^{หூ^ ^ ି^^ห}  is the conditional check on the vehicle to f ollow the intersection SPaT  information. If  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ _^ ^{^}  or  ^^ _^ ^{^} ൌ ^^ ^{^^ା^^} ^  the ego vehicle will collide  MCC Ref. No.:  103361‐329WO1  with any of the four vehicles. Ego CAV velocity is� �one control variable to avoid collision and  following path. (2) contains all the parameters that� �are received by another vehicle in V2 V  communication. However, this cost function has an upp er and lower bound to prevent  unwanted delay and excessive speed while CAVs operate  at the intersection. (3) shows the  formulation of upper and lower bound constraints.  [00268]     ^ ^{^^^^} ^ _{^ ^౮} ^ ^^ _^ ^{^} ^ ^{^^^౮} ^ _^^^     (3)  ^^ _୫ୟ^ ൌ 7 m is the separation distance and  ^^ _୫୧୬  and  ^^ _୫ୟ^  is the upper and lower limit of ego velocity .  ^^ _ego  ൌ ^^ _rel  ^ ^^ _lead       ^ ൌ ^^ _^ ^ ∗ ^^ _^^^   output from CCA using 1A and 2 and based on the c onstraint in 3. Since there is no sensor  information involved in this example framework, theref ore, lead vehicle velocity is received  from the V2 V communication network. The first expre ssion in 4 is for CCC where  ^^ _ego  , ^^ _rel  , and  ^^ _lead   is ego vehicle velocity, relative velocity, an d lead vehicle velocity respectively. the second  expression is the constraint on CCC to maintain a s afe minimum distance where  ^^ _^  is the safe  minimum spacing between lead vehicles and  ^^ _௧  is the minimum time gap between ego and the� � lead vehicle. The output of these expressions provide s CCC velocity to operate safely at the  intersection. The third expression in 4 is for adapt ive lane‐keeping where  ^^ _^ , ^^ _^ , and  ^^ _^  is ego  vehicle relative yaw angle, ego vehicle heading angle , and lane centerline angle respectively.  [00272]     Collision avoidance includes solutions for unsignalized  intersections [15C],  [16C], and [17C].  However, implementations for signa lized intersections can benefit from  MCC Ref. No.:  103361‐329WO1  cooperative scenarios and systems and methods enabling  cooperative control of vehicles at  signalized intersections. The example implementation in cludes a collision avoidance algorithm  that is integrated into the onboard computing system� �of the HAVs. The example  implementation can take advantage of modern technologi es such as AIM, RSU, and STL, which  are available at smart intersections, to access infor mation and make decisions. If two vehicles in  a simulation have the same 3 ^^ position of [latitude, longitude, time], a collisi on can occur. The  CCA system can calculate the desired velocity to avo id conflicts and shares the optimized  velocity with the path following algorithm. The proce ss can be repeated throughout the  simulation, generating a velocity profile for the veh icle to follow as it traverses the intersection.  The use of surrogate optimization meets the two key� �requirements for real‐time optimization in  automotive applications: it is computationally efficien t and able to find optimal solutions  quickly. In the proposed framework, optimizing the ve locity of the ego vehicle requires  standard information such as SPaT information from th e STL, the position  ^^ _^ , and turn  indication  ^^ _^ ^{^}  of the vehicle. The surrogate optimization pro cess involves finding the best  solution within a defined range based on the scenari o. This can be achieved by using a radial  basis function (RBF) interpolator to interpolate the  objective function [18C]. RBF interpolation is  a suitable choice for constructing the surrogate beca use it is computationally efficient, which is  an important consideration for an automotive system.  [14C] The results of the cooperative  navigation in scenarios with jammed AIM and STL are� �shown in FIG. 33. The figure represents  the separation time on the vertical axis and simulat ion time on the horizontal axis. In the  scenario, Actor 4 is the lead vehicle, and the coop erative navigation framework uses  information from the V2V communication channel to opt imize the ego vehicle velocity. FIG. 34  MCC Ref. No.:  103361‐329WO1  shows the results of a scenario where STL is jammed , and FIG. 35A shows the results of a  scenario where all communication is active.  [00273]     CCC is a system that allows vehicles to communicate� �with each other and with  the infrastructure to improve traffic flow and reduce  fuel consumption. It can use combinations  of radar, cameras, and V2V communication to sense th e distance and speed of other vehicles,  and to adjust the speed of the vehicle in real‐ti me to maintain a safe following distance. The  system can also be integrated with traffic lights, r oad signs, and other infrastructure to optimize  traffic flow and reduce congestion. Additionally, CCC� �can also be used to improve safety by  providing advanced warning of potential collisions and  supporting automated emergency  braking. In the example implementation, there is only  V2X communication to share velocities  and the relative distance of other HAVs operating at  the smart intersection.   [00274]     The present study included evaluations of three diffe rent threat scenarios.  FIG. 35B shows that there are some frequent variatio ns in the ego vehicle velocity and the  optimized velocity from cooperative collision avoidance . FIG. 37A shows the lead vehicle  velocity. Since the lead vehicle is connected with t he ego vehicle but does not have the  capability of cooperative navigation. Therefore, its v elocity profile remains the same in the  different threat scenarios. In the study’s analysis,  it was determined that the ego vehicle must  adhere to the optimized velocity determined by the c ooperative collision avoidance algorithm.  This means that the cooperative adaptive cruise contr ol must be adjusted accordingly to  comply with the reference velocity established by the  cooperative collision avoidance system.  Under all of the specified threat scenarios, the ego  vehicle is able to maintain a safe distance  from the lead vehicle and avoid collisions with othe r vehicles at the intersection. As shown in  MCC Ref. No.:  103361‐329WO1  FIG. 37B, there is a significant difference in the  reference velocity from the cooperative collision  avoidance algorithm and the velocity of the lead veh icle, which is traveling faster than the ego  vehicle. This results in a large separation distance� �between the two vehicles. The example  implementation permits the ego vehicle to follow the� �reference set by the cooperative collision  avoidance algorithm, as shown in FIG. 35B. FIG. 36  illustrates the minimum delay between  successive vehicles in different implementations of th e present disclosure.   [00275]     Implementations of the present disclosure include a C ooperative adaptive  lane‐keeping system (“CALK”). The CALK system is  a subsystem of Cooperative Autonomous  Driving System (CADS) that uses a combination of sen sors, cameras, and V2V communication to  improve the lane keeping and lane change capabilities  of a vehicle. It provides the driver with  an additional level of support by detecting the posi tion of the vehicle relative to the road  markings, and by providing steering or braking assist ance to help keep the vehicle in the correct  lane. The system is also able to communicate with o ther vehicles on the road in order to  coordinate lane changes and provide advanced warnings� �of potential collisions. The main  objective of the CALK system is to increase the saf ety of the vehicle and its driver by reducing  the risk of lane departure accidents and collisions  caused by human error.  [00276]     The results of three different threat scenarios using  the proposed framework  are shown in FIG. 37B. FIG. 37B illustrates the pre defined curvature of the lane received by the  ego vehicle from the RSU. The RSU has detailed info rmation about each lane at the  intersection, including the turn curvatures, which hel ps enhance the safety of the intersection.  In the threat scenario where both AIM and STL commu nications are jammed, and the vehicles  are limited to V2V communication, the ego vehicle cr osses the intersection at a faster speed as  MCC Ref. No.:  103361‐329WO1  depicted in FIG. 37B. The ego vehicle crosses the i ntersection from 9sec to 12sec in this  scenario. In the scenario where only STL communicatio n is jammed, the ego vehicle crosses the  intersection from 13 sec to 17 sec, as depicted by FIG. 38. FIG. 38 illustrates th e angle of the  ego vehicle and lane curvature when different communi cation channels are active. As shown in  FIG. 37B, in the example implementation the ego vehi cle takes longer to cross the intersection  when all communication channels are active.  [00277]     The example implementation addresses the cooperative n avigation of HAVs in  smart intersections. It features four example componen ts: cooperative collision avoidance,  cooperative cruise control, cooperative lane‐keeping,� �and path following. In the example  implementation, each vehicle can act as an independen t agent, making decisions based on V2X  communication and utilizing an adaptive model predicti ve control to predict the near future.  Results from the example threat scenarios show that  the ego vehicle is able to maintain a safe  distance in all cases, demonstrating the efficacy of� �the proposed methodology for cooperative  navigation at smart intersections. The example impleme ntation can enhance the safety and  capacity of smart intersections.  [00278]     Example 5:   [00279]     Yet another study was performed on an example implem entation of the  present disclosure. The example implementation included  a simulation with the following  parameters: 32 conflict points; 4 vehicles operating  at the intersection; each vehicle in a  different lane; all vehicles are lead vehicles; Roads ide units (RSU); Autonomous intersection  management (AIM) system; Smart traffic lights (STL);  GNSS (Position, velocity, and timing  MCC Ref. No.:  103361‐329WO1  solution); Based on scenarios there are 2 potential  conflict points; Only Ego vehicles use a  cooperative navigation algorithm.  [00280]     An example graph showing the four vehicle paths is  illustrated in FIG. 39.  Another example intersection showing conflicts is illu strated in FIG. 19. FIG. 20 illustrates a  table of static and dynamic variables that can be s imulated, according to implementations of  the present disclosure.   [00281]     The example implementation can include the system 300  shown and  described with reference to FIG. 3A. The system 300� �can include cooperative collision  avoidance, cooperative path following, cooperative adap tive cruise control, and cooperative  lane keeping.   [00282]     FIG. 40A and FIG. 40B illustrate schematics of vehic les at different  separations. As described herein, ℵ is the time se paration depends on the vehicles width and its  velocity  ^^  is the time separation depends on the vehicle leng th and its velocity AND ^^ is the  separation time that depends on the time ego and ac tor vehicles take to arrive at the particular  conflict point.   [00283]     The objective function for C‐CAS used in the examp le implementation is:   ^ _^^ ^{^} _{ൌ ห ^^} ^{|^^ି^^|^} _^^^ ^{^} _{^ ^^^} ^{^^} _{െ ^^} ^{|^^ି^^|^} _^^^ ^{^ା^} _{^ ^^^} ^{^ା^^} _ห [00284]   [00285]      function constraints:  MCC Ref. No.:  103361‐329WO1  ^^ _^ ^ା ^ ^^ _^ ^ା ^ ^^ _^ ^ା ^ ^^ _{^ ^^^} ^{ష^^^} _ି^^ ^శ _^^^^ ^{ష శ} ^ ^^ ^ା ^ ^^ ^ା ^ ^ ^{൫^^} _{^^^ି^^^^^൯}   ^^ _^ ^ା ^ ^^^ is the  same conflict point vehicle leaves.  [00288]     FIG. 41 illustrates example following distances includ ing spacing and speed  control. As an example, a safe separation distance a t 25 mph may be 2 seconds, a safe  separation distance at 45mph may be 3 seconds, and  a safe separation distance at 65 mph may  be 4 seconds. Stopping distance can be considered th e sum of perception time distance,  reaction time distance, and breaking time distance. � � [00289]     FIG. 42 illustrates an example relationship between a n ego vehicle and any  number of actor vehicles operating in an example sys tem.   [00290]     FIG. 43 illustrates an example intersection with an  RSU, AIM, and STL.   [00291]     FIG. 44 illustrates a schematic of a lane‐keeping  plant model that can be used  by an MPC, according to an example implementation of  the present disclosure.   [00292]     Lane keeping plant model used by MPC:  [00293]       [00294]       MCC Ref. No.:  103361‐329WO1  [00295]   [00296]   [00297] velocity  [00298]     ^^ _ி , ^^ _ோ is cornering stiffness of front and rear tiers   [00299]     L _^, L _ୖ is position of center of gravity from front and rear tires  [00300]     I _^ is yaw moment of inertia  [00301]     m is total mass of vehicle  [00302]     The study included a model of predictive control. Th e example model of  predictive control included a MIMO System; Input outp ut interactions; Constraints; Preview  capabilities (look ahead);  solving online optimizatio n at defined time steps; and MPC using a  Quadratic programming solver for an optimal solution.� � [00303]     The example MPC cost function for Cooperative Adaptiv e cruise control and  cooperative lane keeping control includes:   [00304]     ^^ _^௭ೖ^ ൌ ^^ _௬^௭ೖ^ ^ ^^ _௨^௭ೖ^ ^ ^^ _{∆௨^௭ೖ^} ^ ^^ _ఌ^௭ೖ^        [00306]     ^^ _௨^௭ೖ^  is manipulated variable tracking  [00307]     ^^ _{∆௨^௭ೖ^}  is Manipulated Variable Move Suppression  [00308]     ^^ _ఌ^௭ೖ^  is constraints violation  [00309]     ^^ _^  is quadratic programing decision  MCC Ref. No.:  103361‐329WO1  [00310]     The example implementation can include a quadratic pr oblem solver. The  quadratic problem solver can include an Interior poin t convex quadratic programming  algorithm that can optionally include the following s teps:  [00311]     Pre‐solve/Post‐solve: The algorithm can simplify th e problem by removing  redundancies and simplifying constraints.  [00312]     Generate Initial Point: Initializing x ₀ .  [00313]     Predictor‐Corrector: The algorithms begin by turning� �the linear inequalities Ax  <= b into inequalities of the form Ax >= b b y multiplying A and b by ‐1.  [00314]     Stopping Conditions: The predictor‐corrector algorithm  iterates until it  reaches a point that is feasible.   [00315]     Infeasibility Detection: The merit function is a meas ure of feasibility. quadprog  stops if the merit function grows too large.   [00316]     In some implementations of the present disclosure, MP C can be tuned. Tuning  MPC can include tuning any/all of the following para meters:  [00317]     Sampling Time (Smaller the value will increase the c omputational burden).  [00318]     Prediction Horizon (Number of future intervals related  to sampling time).  [00319]     Control Horizon (Number of control moves to the time  steps).  [00320]     Weight on velocity tracking (Higher weight will reduc e the tracking error).  [00321]     Weight on lateral error (Higher weight will reduce t he lateral error).  [00322]     Weight on change of longitudinal accel (Higher weight  will produce less‐ aggressive vehicle acceleration).  MCC Ref. No.:  103361‐329WO1  [00323]     Weight on change of steering angle (Higher weight wi ll produce less‐ aggressive steering angle change).  [00324]     Three intersection threat scenarios are simulated incl uding jamming of AIM  and STL; Jamming of STL and Cooperation of all infr astructure devices. The capacity results of  the scenarios are illustrated in FIG. 45A and FIG.  45B, where FIG. 45A illustrates acceleration as  a function of time for each scenario and FIG. 45B  illustrates steering angles as a function of time  for each scenario.  [00325]     A table shown in FIG. 46 illustrates the risks of  collision evaluated by the study  for different scenarios.   [00326]     The present disclosure can overcome limitations of us ing GNSS (e.g., GPS),  Radar, Lidar, and camera sensors by using cooperative  methods to incorporate data from  multiple vehicles and control multiple vehicles. GPS  can include absolute velocity, position, and  time. But radar systems, LIDAR systems, and cameras  can be limited to providing only relative  positions of objects at relative times.    [00327]     As used herein, the term “smart intersection” can  refer to systems including  any or all of the following features: an Autonomous� �Intersection Management system, a smart  traffic light, and/or a RoadSide Unit. An Autonomous� �Intersection Management system can  optionally include a system to reserve times of arri val at the intersection. The smart traffic light  can optionally implement SPAT (Signal phase and timin g) and MAP (an intersection map).   [00328]     The RoadSide Unit can optionally include both infrast ructure parameters  and/or V2v and/or V2X communication.   MCC Ref. No.:  103361‐329WO1  [00329]     As used herein, the term “connected autonomous vehi cles” can refer to  vehicles including a cooperative navigation system. Th e cooperative navigation system can  include a cooperative collision avoidance system to m aintain separation between vehicles  and/or vehicles and pedestrians. The cooperative navig ation system can further include a  cooperative MPC‐based lane‐keeping assist system to  perform lane centering. The Cooperative  Navigation system can further include a cooperative M PC Adaptive Cruise Control System  configured to maintain a safe distance from a lead  vehicle. It should be understood that  connected autonomous vehicles can include any or all� �of these features, and can include  features in addition to these features.   [00330]     Referring to FIGS. 47‐50, additional experiments and  analyses were performed  on example implementations of the present disclosure  including static and dynamic scenarios.  As used herein, a static scenario is a scenario whe re the conflict point is static, and a dynamic  scenario is a scenario where the conflict point is  not static. In the static scenario, increases in  cooperation increase velocity. Ego vehicles approach t he intersection earlier as cooperation  increases in the static scenario.   [00331]     In the dynamic scenario, velocity decreases when coop eration increases. The  ego vehicle approaches the intersection later as coop eration increases. It should be understood  that the results illustrated in FIGS. 47‐50 are no n‐limiting examples that correspond to a single  experimental implementation.   [00332]     FIG. 47 illustrates velocity as a function of time  for different scenarios,  according to an implementation of the preset disclosu re. FIG. 48 illustrates steering angle as a  function of time for different scenarios, according t o an implementation of the present  MCC Ref. No.:  103361‐329WO1  disclosure. FIG. 49 illustrates acceleration as a fun ction of time according to an example  implementation of the present disclosure. FIG. 50 ill ustrates acceleration as a function of time  according to an example implementation of the present  disclosure.   [00333]     FIG. 51 illustrates a table showing simulation result s for different jamming  scenarios. As shown in FIG. 51, different jamming sc enarios can result in different vehicle  separations. Closer separations can result in higher  risks of collision.   [00334]     The example implementation includes a cooperative navi gation algorithm  including lane keeping assist systema and adaptive cr uise control systems. The models of  predictive control described herein can enhance safety  in real‐time dynamic scenarios.  As  described herein, the cooperative navigation methods c an include methods of simulating  communication jamming.  Finally, implementations of th e present disclosure can include  machine learning frameworks to simulate and/or impleme nt cooperative navigation systems  and methods.   [00335]     References  [00336]     Although the subject matter has been described in la nguage 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 li mited to the specific features or acts  described above. Rather, the specific features and ac ts described above are disclosed as  example forms of implementing the claims.  [00337]     Arizala, A., Lattarulo, R., Zubizarreta, A., and Pér ez, J. (2021). A control testing  framework for automated driving functionalities using  modular architecture with ros/carla  MCC Ref. No.:  103361‐329WO1  environment. In 2021 25th International Conference on� �System Theory, Control and Computing  (ICSTCC), 314‐320. doi: 10.1109/ICSTCC52150.2021.960722 1.  [00338]     Barzilai, O., Voloch, N., Hasgall, A., Steiner, O.L.,  and Ahituv, N. (2018). Traffic  control in a smart intersection by an algorithm with  social priorities. Contemporary Engineering  Sciences, 11(31), 1499‐1511.  [00339]     Bian, M., Chen, L., Luo, Y., and Li, K. (2014). A� �dynamic model for tire/road  friction estimation under combined longitudinal/lateral� �slip situation. Technical report, SAE  Technical Paper.  [00340]     Bifulco, G.N., Coppola, A., Loizou, S.G., Petrillo, A ., and Santini, S. (2021).  Combined energy‐oriented path following and collision  avoidance approach for autonomous  electric vehicles via nonlinear model predictive contr ol. In 2021 IEEE International Conference  on Environment and Electrical Engineering and 2021 IE EE Industrial and Commercial Power  Systems Europe (EEEIC / I CPS Europe), 1‐6. doi:  10.1109/EEEIC/ICPSEurope51590.2021.9584501.  [00341]     Cocks, M. and Johnson, N. (2021). Smart city technol ogies in the usa: Smart  grid and transportation initiatives in columbus, ohio.  In Smart Cities for Technological and Social  Innovation, 217‐245. Elsevier.  [00342]     Code, T.G.S.T. (1995). Sae international surface vehic le recommended  practice.  [00343]     Huang, Z., Liu, L., Wang, D., Wang, H., and Peng,  Z. (2021). Collision‐free  cooperative kinematic guidance laws for multiple unman ned surface vehicles subject to static  MCC Ref. No.:  103361‐329WO1  and dynamic obstacles. In 2021 11th International Con ference on Information Science and  Technology (ICIST), 565‐570. doi: 10.1109/ICIST52614.2 021.9440643.  [00344]     Khayatian, M., Mehrabian, M., Andert, E., Dedinsky, R ., Choudhary, S., Lou, Y.,  and Shirvastava, A. (2020). A survey on intersection� �management of connected autonomous  vehicles. ACM Transactions on CyberPhysical Systems, 4 (4), 1‐27.  [00345]     Kim, H. and Ryu, J. (2011). Sideslip angle estimatio n considering short‐ ^{duration longitudinal velocity variation. Internati onal Journal of Automotive Technology, 12(4),}  _{545 െ 553.}  [00346]     Martinsen, A.B. (2021). Optimization‐based planning a nd control for  autonomous surface vehicles.  [00347]     Milo, C. (2020). Intersection Simulation and Path Est imation. Ph.D. thesis.  [00348]     Pourmehrab, M., Elefteriadou, L., and Ranka, S. (2017 ). Smart intersection  control algorithms for automated vehicles. In 2017 Te nth International Conference on  Contemporary Computing (IC3), 1‐6. doi: 10.1109/IC3.2 017.8284361.  [00349]     Wang, H., Meng, Q., Chen, S., and Zhang, X. (2021).  Competitive and  cooperative behaviour analysis of connected and autono mous vehicles across unsignalised  intersections: A game‐theoretic approach. Transportati on research part B: methodological, 149,  322‐346.  [00350]     Xu, C.Z., Han, Z.H., Zhang, K.S., and Song, W. (201 8). Surrogate‐based  optimization method applied to multidisciplinary design  optimization architectures. In 31st  congress of the International Council Of The Aeronaut ical Sciences (ICAS 2018).  MCC Ref. No.:  103361‐329WO1  [00351]     Al‐Stouhi, S. K. (2019). System and method for pro viding vehicle collision  avoidance at an intersection. US Patent 10,220,845. � � [00352]     Villari, A. B. (2020). A multi‐agent autonomous int ersection management  (MA‐AIM) system for smart cities leveraging edge‐o f‐things and Blockchain},. Information  Sciences, 148‐163.  [00353]     Rakha, Y. B. (2019). Real‐time optimal intersection� �control system for  automated/cooperative vehicles. International Journal of  Transportation Science and  Technology, 1‐12.  [00354]     Chen, Y. a. (2019). An Autonomous T‐Intersection Dr iving Strategy Considering  Oncoming Vehicles Based on Connected Vehicle Technolog y. IEEE/ASME Transactions on  Mechatronics, 2779‐2790.   [00355]     Milo, C. (2020). Intersection Simulation and Path Est imation.  [00356]     Niels, T. a. (2019). Smart Intersection Management fo r Connected and  Automated Vehicles and Pedestrians. 2019 6th Internati onal Conference on Models and  Technologies for Intelligent Transportation Systems (MT ‐ITS), 1‐10.  [00357]     Shen, Z. a. (2019). Coordination of connected autonom ous and human‐ operated vehicles at the intersection. 2019 IEEE/ASME� �International Conference on Advanced  Intelligent Mechatronics (AIM), 1391‐1396.  [00358]     Vaio, M. D. (2019). Design and Experimental Validatio n of a Distributed  Interaction Protocol for Connected Autonomous Vehicles� �at a Road Intersection. IEEE  Transactions on Vehicular Technology, 9451‐9465.  MCC Ref. No.:  103361‐329WO1  [00359]     Xihui, W. a. (2020). Predictive Motion Planning of V ehicles at Intersection  Using a New GPR and RRT. 2020 IEEE 23rd Internation al Conference on Intelligent  Transportation Systems (ITSC), 1‐6.  [00360]     Arizala, A. a. (2021). A Control Testing Framework f or automated driving  functionalities using modular architecture with ROS/CAR LA environment. 2021 25th  International Conference on System Theory, Control and  Computing (ICSTCC, 314‐320.   [00361]     Park, C.‐H. a.‐C. (2019). Implementation of Autono mous Driving Vehicle at an  Intersection with Traffic Light Recognition and Vehicl e Controls. VEHITS, 542‐‐549.  [00362]     Bifulco, G. N. (2021). Combined Energy‐oriented Path  Following and Collision  Avoidance approach for Autonomous Electric Vehicles vi a Nonlinear Model Predictive Control.  2021 IEEE International Conference on Environment and� �Electrical Engineering and 2021 IEEE  Industrial and Commercial Power Systems Europe (EEEIC� �/ I CPS Europe), 1‐6.  [00363]     Huang, Z. a. (2021). Collision‐free Cooperative Kine matic Guidance Laws for  Multiple Unmanned Surface Vehicles Subject to Static  and Dynamic Obstacles. 2021 11th  International Conference on Information Science and Te chnology (ICIST, 565‐570.  [00364]     Kim, M. a. (2021). Model Predictive Control Method f or Autonomous Vehicles  Using Time‐Varying and Non‐Uniformly Spaced Horizon . IEEE Access, 86475‐86487.  [00365]     Lin, Q. a. (2021). Safe and Resilient Practical Wayp oint‐Following for  Autonomous Vehicles. IEEE Control Systems Letters, 157 4‐1579.  [00366]     Martinsen, A. B. (2021). Optimization‐based Planning� �and Control for  Autonomous Surface Vehicles. NTNU.  MCC Ref. No.:  103361‐329WO1  [00367]     Ramanata, P. P. (1998). Optimal vehicle path generato r using optimization  methods. Virginia Tech.  [00368]     Song, W. a. (2016). Intention‐aware autonomous drivi ng decision‐making in  an uncontrolled intersection. Mathematical Problems in� �Engineering.  [00369]     Tian, R. a. (2020). Game‐Theoretic Modeling of Traf fic in Unsignalized  Intersection Network for Autonomous Vehicle Control Ve rification and Validation. IEEE  Transactions on Intelligent Transportation Systems, 1� �16.  [00370]     Wang, M. a. (2021). Game‐Theoretic Planning for Sel f‐Driving Cars in  Multivehicle Competitive Scenarios. IEEE Transactions o n Robotics, 1313‐1325.  [00371]     Wang, Y. a. (2021). Path Following by Formations of� �Agents with Collision  Avoidance Guarantees using Distributed Model Predictive  Control. 2021 American Control  Conference (ACC, 3352‐3357.  [00372]     Yu, T. a. (2021). Design and Implementation of a Sm all‐scale Autonomous  Vehicle for Autonomous Parking. 2021 6th International  Conference on Automation, Control  and Robotics Engineering (CACRE), 398‐402.  [00373]     Zhu, D.‐D. a.‐Q. (2021). A New Algorithm Based o n Dijkstra for Vehicle Path  Planning Considering Intersection Attribute. IEEE Acces s, 19761‐19775.  [00374]     [1B] M. Khayatian, M. Mehrabian, E. Andert, R. Dedin sky, S. Choudhary, Y.  Lou, and A. Shirvastava, "A survey on intersection m anagement of connected autonomous  vehicles," ACM Transactions on Cyber‐Physical Systems , vol. 4, no. 4, pp. 1‐27, 2020.  MCC Ref. No.:  103361‐329WO1  [00375]     [2B] M. Cocks and N. Johnson, "Smart city technologi es in the usa: Smart grid  and transportation initiatives in columbus, ohio," in� �Smart Cities for Technological and Social  Innovation, pp. 217‐245, Elsevier, 2021.  [00376]     [3B] S. Jing, F. Hui, X. Zhao, J. Rios‐Torres, an d A. J. Khattak, "Integrated  longitudinal and lateral hierarchical control of coope rative merging of connected and  automated vehicles at on‐ramps," IEEE Transactions o n Intelligent Transportation Systems, vol.  23, no. 12, pp. 24248‐24262 2022.  [00377]     [4B] H. Wang, Q. Meng, S. Chen, and X. Zhang, "Com petitive and cooperative  behaviour analysis of connected and autonomous vehicle s across unsignalised intersections: A  game‐theoretic approach," Transportation research part  B: methodological, vol. 149, pp. 322‐ 346, 2021.  [00378]     [5B] S. K. S. Nakka, B. Chalaki, and A. A. Malikop oulos, "A multi‐agent deep  reinforcement learning coordination framework for conne cted and automated vehicles at  merging roadways," in 2022 American Control Conference  (ACC), pp. 3297‐3302, IEEE, 2022.  [00379]     [6B] Z. Zhu, L. Adouane, and A. Quilliot, "Intellige nt traffic based on hybrid  control policy of connected autonomous vehicles in mu ltiple unsignalized intersections," in  2021 IEEE SmartWorld, Ubiquitous Intelligence & Co mputing, Advanced & Trusted Computing,  Scalable Computing & Communications, Internet of P eople and Smart City Innovation  (SmartWorld/SCALCOM/UIC/ATC/IOP/SCI), pp. 416‐424, IEEE , 2021.  [00380]     [7B] N. Kamath B, R. Fernandes, A. P. Rodrigues, M.  Mahmud, P. Vijaya, T. R.  Gadekallu, and M. S. Kaiser, "Taken: A traffic knowl edge‐based navigation system for connected  and autonomous vehicles," Sensors, vol. 23 , no. 2  , p. 653, 2023.  MCC Ref. No.:  103361‐329WO1  [00381]     [8B] L. Chen and C. Englund, "Cooperative intersectio n management: A  survey," IEEE transactions on intelligent transportatio n systems, vol. 17, no. 2, pp. 570‐ 586,2015.  [00382]     [9B] A. Gholamhosseinian and J. Seitz, "A comprehensi ve survey on  cooperative intersection management for heterogeneous c onnected vehicles," IEEE Access, vol.  10, pp. 7937‐7972, 2022.  [00383]     [10B] A. M. M. Sizkouhi, M. Rahimifard, and R. R.  Selmic, "Covert attack and  detection through deep neural network on vision‐base d navigation systems of multi‐agent  autonomous vehicles," in 2022 IEEE International Confe rence on Systems, Man, and  Cybernetics (SMC), pp. 2583‐2590, IEEE, 2022  [00384]     [11B] A. Mirheli, M. Tajalli, L. Hajibabai, and A.  Hajbabaie, "A consensusbased  distributed trajectory control in a signal‐free inte rsection," Transportation research part C :  emerging technologies, vol. 100, pp. 161‐176, 2019.� � [00385]     [12B] X. Sun, F. R. Yu, and P. Zhang, "A survey o n cyber‐security of connected  and autonomous vehicles (cavs)," IEEE Transactions on� �Intelligent Transportation Systems, vol.  23, no. 7, pp. 6240‐6259, 2021.  [00386]     [13B] R. Valiente, M. Razzaghpour, B. Toghi, G. Shah , and Y. P. Fallah,  "Prediction‐aware and reinforcement learning based al truistic cooperative driving," arXiv  preprint arXiv:2211.10585, 2022  [00387]     [14B] R. Khan, A. Hanif, and Q. Ahmed, "Cooperative� �navigation strategy for  connected autonomous vehicle operating at smart inters ection," in 2022 10th IFAC Conference  on AAC, no. 0051, 2022.  MCC Ref. No.:  103361‐329WO1  [00388]     [15B] Z. Huang, L. Liu, D. Wang, H. Wang, and Z.  Peng, "Collision‐free  cooperative kinematic guidance laws for multiple unman ned surface vehicles subject to static  and dynamic obstacles,' in 2021 11th International Co nference on Information Science and  Technology (ICIST), pp. 565570,2021.  [00389]     [16B] G. N. Bifulco, A. Coppola, S. G. Loizou, A.  Petrillo, and S. Santini,  "Combined energy‐oriented path following and collisio n avoidance approach for autonomous  electric vehicles via nonlinear model predictive contr ol.," in 2021 IEEE International Conference  on Environment and Electrical Engineering and 2021 IE EE Industrial and Commercial Power  Systems Europe (EEEIC / I CPS Europe), pp. 1‐6, 2 021.  [00390]     [17B] H. Wang, Q. Meng, S. Chen, and X. Zhang, "Co mpetitive and cooperative  behavior analysis of connected and autonomous vehicles  across unsignalized intersections: A  game‐theoretic approach," Transportation research part  B: methodological, vol. 149, pp. 322‐ 346, 2021.  [00391]     [18B] C.‐Z. Xu, Z.‐H. Han, K.‐S. Zhang, and W.  Song, "Surrogate‐based  optimization method applied to multidisciplinary design  optimization architectures," in 31st  congress of the International Council Of The Aeronaut ical Sciences (ICAS 2018), 2018.