EP3353615A1 - Vehicle identification and location using senor fusion and inter-vehicle communication - Google Patents
Vehicle identification and location using senor fusion and inter-vehicle communicationInfo
- Publication number
- EP3353615A1 EP3353615A1 EP16858471.2A EP16858471A EP3353615A1 EP 3353615 A1 EP3353615 A1 EP 3353615A1 EP 16858471 A EP16858471 A EP 16858471A EP 3353615 A1 EP3353615 A1 EP 3353615A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- vehicle
- vehicles
- noc
- data
- platooning
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000004891 communication Methods 0.000 title description 55
- 230000004927 fusion Effects 0.000 title description 5
- 238000000034 method Methods 0.000 abstract description 107
- 239000000446 fuel Substances 0.000 abstract description 12
- 230000001133 acceleration Effects 0.000 abstract description 10
- 230000008569 process Effects 0.000 description 91
- 230000006870 function Effects 0.000 description 48
- 101001093748 Homo sapiens Phosphatidylinositol N-acetylglucosaminyltransferase subunit P Proteins 0.000 description 19
- 238000013475 authorization Methods 0.000 description 19
- 238000012544 monitoring process Methods 0.000 description 17
- 230000009471 action Effects 0.000 description 13
- 238000013459 approach Methods 0.000 description 13
- 238000010586 diagram Methods 0.000 description 12
- 238000007726 management method Methods 0.000 description 12
- 230000008901 benefit Effects 0.000 description 10
- 235000012813 breadcrumbs Nutrition 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 230000001413 cellular effect Effects 0.000 description 8
- 230000033001 locomotion Effects 0.000 description 8
- 230000015572 biosynthetic process Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 6
- 238000010276 construction Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 5
- 239000003550 marker Substances 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 230000007613 environmental effect Effects 0.000 description 3
- 230000000007 visual effect Effects 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000010267 cellular communication Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 206010000210 abortion Diseases 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000004397 blinking Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001066 destructive effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 235000012054 meals Nutrition 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 230000002040 relaxant effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
- G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
- G05D1/02—Control of position or course in two dimensions
- G05D1/021—Control of position or course in two dimensions specially adapted to land vehicles
- G05D1/0287—Control of position or course in two dimensions specially adapted to land vehicles involving a plurality of land vehicles, e.g. fleet or convoy travelling
- G05D1/0291—Fleet control
- G05D1/0293—Convoy travelling
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S19/00—Satellite radio beacon positioning systems; Determining position, velocity or attitude using signals transmitted by such systems
- G01S19/01—Satellite radio beacon positioning systems transmitting time-stamped messages, e.g. GPS [Global Positioning System], GLONASS [Global Orbiting Navigation Satellite System] or GALILEO
- G01S19/13—Receivers
- G01S19/24—Acquisition or tracking or demodulation of signals transmitted by the system
- G01S19/28—Satellite selection
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S19/00—Satellite radio beacon positioning systems; Determining position, velocity or attitude using signals transmitted by such systems
- G01S19/38—Determining a navigation solution using signals transmitted by a satellite radio beacon positioning system
- G01S19/39—Determining a navigation solution using signals transmitted by a satellite radio beacon positioning system the satellite radio beacon positioning system transmitting time-stamped messages, e.g. GPS [Global Positioning System], GLONASS [Global Orbiting Navigation Satellite System] or GALILEO
- G01S19/42—Determining position
- G01S19/51—Relative positioning
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/16—Anti-collision systems
- G08G1/161—Decentralised systems, e.g. inter-vehicle communication
- G08G1/163—Decentralised systems, e.g. inter-vehicle communication involving continuous checking
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/16—Anti-collision systems
- G08G1/164—Centralised systems, e.g. external to vehicles
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/22—Platooning, i.e. convoy of communicating vehicles
Definitions
- This application relates generally to methods, systems and devices that improve safety, diagnostics, analytics and fuel savings systems for vehicles, including but not limited to enabling at least a second vehicle to follow, safely, a first vehicle at a close distance in an automated or semi- automated manner. More particularly, the present invention relates to methods, systems and devices which permit vehicles to identify one another on the open road using the sensors local to one or more sensing vehicles together with inter-vehicle, wireless, and satellite signals
- the present invention relates to systems and methods for enabling vehicles to closely follow one another safely through partial automation. Following closely behind another vehicle has significant fuel savings benefits, but is generally unsafe when done manually by the driver.
- Convenience systems such as adaptive cruise control, control the speed of the vehicle to make it more pleasurable or relaxing for the driver, by partially automating the driving task.
- These systems use range sensors and vehicle sensors to then control the speed to maintain a constant headway to the leading vehicle. In general these systems provide zero added safety, and do not have full control authority over the vehicle (in terms of being able to fully brake or accelerate) but they do make the driving task easier, which is welcomed by the driver.
- the manual driver is not as reliable at maintaining a constant headway as an automated system. Additionally, a manual driver, when trying to maintain a constant headway, generally causes rapid and large changes in command (accelerator pedal position for example) which result in a loss of efficiency.
- aspects of the invention described herein combine attributes of state of the art convenience, safety systems and manual control to provide, for example, a safe, efficient convoying, or platooning, solution or other partly or fully automated vehicle solution.
- aspects of the present invention enable a first potential platooning partner to identify a sensed vehicle based on data received from the sensors local to the first vehicle, sometimes in combination with communications received from the sensed vehicle, or from a NOC or other network source, or via satellite link.
- the present invention achieves this objective by combining elements of active vehicle monitoring and control with communication techniques that permit drivers of both lead and trailing vehicles to have a clear understanding of their motoring environment, including a variety of visual displays, while offering increased convenience to the drivers together with the features and functionality of a manually controlled vehicle.
- systems and methods for semi-automated vehicular convoying are provided.
- the systems and methods of the present invention provide for, among other things: 1 ) a close following distance to save significant fuel; 2) safety in the event of emergency maneuvers by the leading vehicle; 3) safety in the event of component failures in the system or either vehicle; 4) an efficient mechanism for identifying partner vehicles with which to platoon, as well as identifying sections of road suitable for safe platooning; 5) an intelligent ordering of the vehicles based on several criteria; 6) other fuel economy optimizations made possible by the close following; 7) control algorithms to ensure smooth, comfortable, precise maintenance of the following distance appropriate for the operating environment and the vehicles in the platoon; 8) robust failsafe mechanical hardware onboard the vehicles; 9) robust electronics and communication; 10) robust, diverse forms of communication among the vehicles in and around the platoon for the benefit of the driver and for ensuring regular, reliable communications with a network operations center (“NOC”) such as maintained by a fleet
- NOC network operations center
- Figures 1 A-1 C show a lead vehicle and a following or trailing vehicle at the three stages of platooning in accordance with the invention: available, linking, linked.
- Figure 2 shows an embodiment of the forward-looking view seen by the trailing vehicle.
- Figure 3 shows a variety of communications links between platooning vehicles, ancillary vehicles, wireless transceivers, and a network operations center.
- Figure 4 illustrates a variety of factors that a central server, such as maintained at a NOC, might consider in determining candidates for linking.
- Figure 5A illustrates in simplified form an embodiment of a control system onboard a vehicle for managing communications as well as monitoring and controlling various vehicle functions.
- Figure 5B illustrates in simplified form an algorithm, operating on the onboard control system of Figure 5A, by which a lead vehicle issues commands to and receives data back from a proximately-located following vehicle.
- Figure 6 illustrates in simplified form a variety of types of messages sent between the NOC and the vehicles, together with simplified architectures for the onboard system and the NOC.
- FIG. 7A illustrates in block diagram form the operation of a platooning supervisor system, comprising a vehicle monitoring and control system in combination with one or more software layers, in accordance with an embodiment of the invention.
- Figure 7B illustrates in greater detail an embodiment of the processors, sensors and actuators of the vehicle monitoring and control system of Figure 7A, together with the associated software layers.
- Figure 8A illustrates in greater detail the Platooning Supervisor Layer of Figure 7A.
- Figure 8B illustrates, from a software functionality perspective, the operation of an embodiment of the vehicle control system of the present invention.
- Figure 9 illustrates in flow diagram form an embodiment of a vehicle data processing main loop in accordance with the invention.
- Figure 10 illustrates in flow diagram form an embodiment of NOC-vehicle communications management.
- Figures 1 1 A-1 1 B illustrates a long range coordination aspect of the present invention, including a geofencing capability.
- Figures 12A-12B illustrate in flow diagram form an embodiment of a process for coordination and linking in accordance with the invention, including consideration of factors specific to the vehicles.
- Figure 13 illustrates an embodiments of software architecture suited to perform the travel forecasting function that is one aspect of the present invention.
- Figure 14 illustrates in flow chart form an embodiment of a sequence for platoon pairing discovery and monitoring.
- Figure 15A illustrates in flow chart form an embodiment of an aspect of the invention by which platoonable road segments are identified.
- Figure 15B illustrates in flow diagram form a process for identifying potential platoon partners.
- Figures 16A-16E illustrates an embodiment of a process for segmenting a roadway for purposes of identifying sections where platooning can be authorized, and the resulting platooning routing for a pair of vehicles.
- Figure 17A illustrates a plurality of vehicles, among which is a vehicle to be identified and a vehicle seeking to make that identification.
- Figures 17B-17C illustrate in flow diagram form two exemplary embodiments of processes by which a "sensing" vehicle identifies a "sensed” vehicle through the use of a vehicle signature.
- Figures 18A-18B illustrates in flow diagram form alternative embodiments of a process by which a sensing vehicle identifies the back end of a sensed vehicle.
- Figure 19A illustrates a pair of vehicles traveling in close proximity to one another, and the GPS satellites seen by each.
- Figures 19B-19D illustrate in flow diagram form various alternative processes for ensuring that vehicles traveling in close proximity to one another and using GPS position information rely on such position information from the same satellites..
- Figure 20A shows an alternative approach for monitoring relative vehicle position among vehicles traveling in close proximity to one another, when the number of viewable satellites is fewer than normally desired.
- Figure 20B shows in flow diagram from an embodiment of a process for evaluating vehicle position where, as shown in Figure 20A, the number of viewable satellites is less than normally desired.
- Figure 21 A shows a pair of vehicles traveling in close proximity and approaching an incline having, for example, two different grades.
- Figure 21 B illustrates in flow diagram form an embodiment of a process by which the impact of the grade on vehicle performance can be anticipated and compensated for.
- the present invention relates to systems and methods for automated and semi-automated vehicular convoying. Such systems enable vehicles to follow closely behind each other, in a convenient, safe manner.
- the exemplary vehicles referred to in the following description will, in general, be large trucks, but those skilled in the art will appreciate that many, if not all, of the features described herein also apply to many other types of vehicles and thus this disclosure, and at least some of the embodiments disclosed herein, is not limited to vehicles of any particular type.
- FIG. 1A vehicle A, indicated at 100, and vehicle B, indicated at 105, are operating independently of one another, but each is available for linking.
- the displays shown at 1 10 and 1 15, for vehicles A and B, respectively, illustrate status, distance from a candidate partner vehicle, and fuel consumption, in some instances, although other data can also be displayed as will be better appreciated hereinafter.
- vehicles A and B are sufficiently proximate to one another that linking, or a merge into a platoon, is allowed.
- candidates for linking are typically selected at a network operations center, such as, for example, a fleet management center if the vehicles are large trucks.
- the NOC sends to each vehicle a message identifying suitable candidates for linking, together with information to facilitate both drivers reaching a target rendezvous point at the same time so that they can form a platoon.
- the lead vehicle maintains control of at least the acceleration and braking of the following truck.
- the vehicles are linked, as shown in Figure 1 C.
- the driver of the rear vehicle remaining in control of steering, such that the rear vehicle is operated only in a semi-automated manner.
- fully automated operation of the rear vehicle is implemented. It will be appreciated by those skilled in the art that semi-automated and automated are sometimes referred to as semi-autonomous and autonomous.
- the view from the front of the rear vehicle is as shown in Figure 2, again using large trucks as an example for purposes of illustration only.
- the lead truck 200 is immediately in front of the follow truck, and a display 210 shows the view from a forward -facing camera mounted on the lead truck.
- haptic or audio devices can be implemented to ensure that the driver of the follow truck stays substantially directly behind the lead truck while platooning. For example, should the driver of the follow vehicle veer out of the lane to the left, an audio signal on the left side can be activated to assist the driver in returning the vehicle to the proper alignment with respect to the lead vehicle.
- an audio signal on the right side can be activated.
- which audio signal is activated can be reversed; that is, a veer to the left can activate the right audio signal, and vice versa.
- a pair [right and left] of vibration sources can be implemented either in the steering wheel, or the driver's seat, or both. Alternatively, a single vibration source can be used in some embodiments.
- a short range communications link such as DSRC is adequate for communicating messages between the processors of each truck, although other forms of wireless communication can be used, for example, cellular.
- DSRC short range communications link
- a variety of data is sent from each truck to the NOC, including truck condition and performance, route changes, local weather, and other data. This permits the fleet operator to proactively manage truck maintenance and repair, adjust routing for weather problems or road construction, identify vehicle location in the event of an emergency, and manage a variety of other analytics.
- Figure 3 illustrates an embodiment of communications links for managing messaging in a system according to the invention. More
- Figure 3 illustrates an embodiment using a variety of
- Figure 3 illustrates an embodiment of a mesh network by which messages can be communicated between the NOC and a vehicle through intermediary vehicles. More particularly, vehicle 100 is in communication with platoon partner vehicle 105 via DSRC or other suitable wired or wireless technologies, as illustrated at 300. In addition, for most of vehicle 100's route, it is also in communication with NOC 310 via a cellular link 320. Similarly, vehicle 105 communicates with NOC 310 via a cellular link 320, absent a break in the wireless link.
- vehicles 100 and 105 are also equipped to access WiFi hotspots 330, which in turn communicate with the NOC through either a wireless link illustrated at 340, or wired channel illustrated at 350.
- WiFi hotspots are increasingly ubiquitous along the roadway, as well as at fleet operations centers.
- WiFi hotspots in vehicles based on 4G LTE or similar services have been introduced. Microcell and similar technologies can also provide a communications link in some instances.
- a relay technique based on an ad hoc mesh network can be used. For example, suppose vehicle 100 is traveling east, and just passed through an area of good cellular connectivity to the NOC 300 but is now passing through a zone that has no wireless connectivity. Suppose, too, that vehicle X, shown at 360 is traveling west, and has been out of contact with the NOC for some period of time, but will regain wireless connectivity sooner than truck 100.
- the NOC 310 knows with reasonable precision the location of each of the vehicles that it monitors based on travel forecasts, discussed in greater detail hereinafter, even when cellular or similar links are unavailable.
- NOC 310 needs to send information to vehicle X
- the NOC sends to vehicle 100 the message for vehicle X while vehicle 100 still has connectivity to the NOC. Then, when vehicle 100 and vehicle X are proximate, vehicle 100 relays the NOC's message to vehicle X.
- vehicle 100 needs to get data to the NOC, but is presently out of touch with the NOC, it can relay its data to vehicle X, and vehicle X retransmits the data to the NOC when vehicle X regains connectivity to the NOC.
- vehicles not within the management of the fleet operation can also be used to relay messages.
- vehicles Y and Z shown at 370 and 380, can receive messages from Vehicles A and B via link 390 and then relay them to NOC 310 if properly equipped for communication with the NOC, which can be by means of a standard protocol.
- NOC 310 if properly equipped for communication with the NOC, which can be by means of a standard protocol.
- a mesh network is created by which messages can be passed from vehicle to vehicle and thence to the NOC.
- Such a mesh network also permits the passing of status messages from vehicle to vehicle, so that, for example, the platoon of vehicles 100 and 105 is aware of the status of surrounding vehicles. For example, the platoon may be informed of where the car on the left needs to exit the roadway, which, for example, permits the platoon to avoid having that car cut in between vehicles 100 and 105 or otherwise behave in an unexpected manner. Likewise, emergency conditions can be communicated to the platoon, comprised of Vehicles A and B, well in advance, permitting increased operational safety.
- the central server 400 either alone or in combination with the system onboard each vehicle 410, 420, makes decisions and suggestions either for platooning or simply for improved operation, based on knowledge of one or more of vehicle location, destination, load, weather, traffic conditions, vehicle type, trailer type, recent history of linking, fuel price, driver history, and other factors, all as shown at 430A-n.
- the central server and the onboard systems both communicate with the driver through display 440.
- Those communications can involve linking suggestions, road conditions, weather issues, updated routing information, traffic conditions, potential vehicle maintenance issues, and a host of other data.
- a linking opportunity may present itself independently of the central server. In such an instance, once the pairing is identified that potential pairing is communicated to at least the onboard system and, in most instances although not necessarily all, also communicated to the central server. It is possible that either the central server or the on-board systems will conclude that the pair is not suitable for linking, and linking is disabled as shown at 450.
- linking opportunities can be determined while the vehicles are moving, but can also be determine while one or more of the vehicles is stationary, such as at a truck stop, rest stop, weigh station, warehouse, depot, etc. They can also be calculated ahead of time by the fleet manager or other associated personnel. They may be scheduled at time of departure, or hours or days ahead of time, or may be found ad-hoc while on the road, with or without the assistance of the coordination functionality of the system.
- an embodiment of an onboard system comprises a control processor 500 that receives inputs from, for example, an onboard radar unit 505, a video camera 510, and a lidar unit 515 via connection (a), typically but not necessarily a CAN interface.
- the control processor can configure each of these units and receive data.
- connection (b) to inertial measurement sensors or gyros 520 which can be wireless, gives the control processor acceleration information in 1 , 2 or 3 axes as well as rotation rate information about 1 , 2 or 3 axes.
- accelerometers can be substituted for gyros, although gyros are generally used for, for example, rotation rate.
- a plurality of data links 530 shown at (c) and expanded to show detail at the lower portion of Figure 5A, provides information about relevant characteristics of the leading truck 100, including its acceleration, or is used to provide the same or similar information to the following truck 105.
- the brake valve and sensor 550 connected on bus (d), provides data on brake pressure, and is used to apply pressure via a command from the control processor 500.
- the accelerator command 555 is sent via an analog voltage or a communications signal (CAN or otherwise).
- the control processor performs calculations to process the sensor information, information from the GUI, and any other data sources, and determine the correct set of actuator commands to attain the current goal (example: maintaining a constant following distance to the preceding vehicle).
- the data links include one or more wireless links 535 such as cellular, DSRC, etc.
- the data links 530 also comprise inputs from the vehicle, shown at 540, which are typically transmitted via the vehicle's engine control unit, or ECU, indicated at 545 and typically provided by the vehicle
- control processor communicates bi-directionally with the various input devices.
- FIG. 5B shows, for an embodiment, the general flow between the vehicle control units of two linked vehicles.
- two modes of operation are typically implemented: in a first mode, the front truck's control unit issues commands to the back truck's control unit, and those commands are, in general, followed, but can be ignored in appropriate circumstances, such as safety.
- the front truck's control unit sends data to the second truck, advising the trailing truck of the data sensed by the lead truck and the actions being taken by the lead truck.
- the second truck's control unit then operates on that data from the front truck to take appropriate action.
- the following or trailing truck sends data about its operation to the front or lead truck.
- the lead truck receives the data from the trailing truck, and senses motion and/or external objects and/or
- the lead truck then decides upon actions for the lead truck, shown at 570, and, if operating in the first mode, also decides upon actions for the back truck, shown at 575. Then, depending upon whether operating in first or second mode, the lead truck either sends commands (580) to the trailing truck (first mode), or sends data (585) to the trailing truck (second mode). If operating in the first mode, the second truck receives the commands and performs them at 590, with the caveat that the second truck can also chose to ignore such commands in some embodiments. If operating in the second mode, the second truck receives the data at 595, and decides what actions to perform.
- control programs for both units are, in some embodiments, the same, in most cases the resulting control of the second truck will be identical regardless of operating mode.
- the second truck communicates to the front truck what actions it has taken, shown at 600, so that each truck knows the state of the other. It will be appreciated by those skilled in the art that the control programs need not be the same for both vehicles in every embodiment.
- the above process is repeated substantially continually, for example, once per second, to ensure that each truck has the current state of the other truck, and the NOC has current status for both, thus assisting in ensuring safe and predictable operation of each truck even when operating in close-order formation at highway speeds.
- various warnings and alerts can be implemented as inputs to either the control processor or a separate warnings and alerts processor, as described in greater detail in PCT Application PCT/US 14/30770, filed March 17, 2014.
- a brake check process can be implemented both to ensure that the vehicle brakes are working correctly and to help determine which vehicle should lead, as the vehicle with the better brakes will usually be positioned as the follow vehicle, all other parameters being equal.
- the NOC 601 which resides in the cloud in at least some embodiments, comprises, in simplified terms, a link finder function 605, a link approver function 610, and a logger function 615.
- the outputs of the functions are conveyed through a communication gateway 620 to the onboard system 625.
- the onboard system 625 receives from the NOC 601 information about vehicle pairings that the NOC has determined to have linking potential, followed by linking authorizations at the appropriate time, indicated at 630.
- the onboard system receives hazard advisories, indicated at 635, which in general comprise hazards to the vehicle based upon the projected route of travel.
- the onboard system 625 comprises, from a functional standpoint, one or more electronic control units, or ECU'S, which manage various functions as more specifically described in connection with Figure 7A.
- ECU'S electronice control units
- FIG. 6 only a data ECU is shown, and it provides for message handling and communications
- an ECU as described herein comprises a controller or other processor, together with appropriate storage and other ancillaries to execute program instructions of the type discussed in greater detail as discussed herein and particularly beginning with Figure 7A.
- the data ECU 640 manages the WiFi, LTE and Bluetooth interfaces, indicated at 645, 650 and 655, respectively, and in turn communicates bidirectionally with a platoon controller ECU function 660.
- the platoon controller ECU function in turn communicates bidirectionally with other platoon candidates and members via a DSRC link 665, and also outputs data to the driver's display 670.
- the onboard ECU function communicates with the vehicle's CAN bus 730 which provides connection to a platoon controller 675, log controller 680, driver interface 685.
- the ECU also provides back to the NOC reports of vehicle position and health, or
- the ECU dumps its log to the NOC, as indicated at 699.
- the log can comprise all data, including video information, or can comprise a subset of that data.
- the log dump can comprise some or all CAN bus data including SAE J1939 data, some or all radar, LIDAR and video data, some or all GPS data, some or all DSRC data, and some or all status data for both radio systems. It will be appreciated by those skilled in the art that not all such data is transmitted on the CAN bus, and instead may be communicated via an Ethernet connection, a point-to-point connection, or other suitable communications link.
- Vehicle Monitoring and Control System 700 comprises one or more processors and related hardware as further described in connection with Figure 7B et seq.
- the System 700 provides data to and executes instructions from Vehicle Control Layer 705 via channel 705A and also provides data to and executes instructions from Platooning Supervisor Layer 710 via channel 71 OA.
- Platooning Supervisor Layer 710 also communicates with the Vehicle Control Layer 705 via channel 710B.
- layers 705 and 710 are software layers, executing on the hardware of the hardware layer shown as System 700.
- the Vehicle Monitoring and Control System 700 comprises one or more Electronic Control Units (ECU's) that receive inputs from various sensors and provide outputs to various actuators and other devices comprising, for example, the driver HMI and cell and DSRC transceivers, under the control of the Vehicle Control Layer 705 and Platooning Supervisor Layer 710.
- ECU's Electronic Control Units
- the System 700 also communicates with the Driver 715 over a connection 715A.
- the System 700 also communicates with a NOC 720, usually over a wireless link such as shown by cell tower 720A.
- a single ECU can perform all of the functions necessary in at least some embodiments of the invention, most modern vehicles have a plurality of ECU's, with each being assigned a specialty.
- a plurality of ECU's 725A-725N comprise the core of the System 700 and communicate with one another on bus 730 which can be, in at least some embodiments, a CAN bus although, depending upon the particular device being linked, the bus 730 can be a different type of bus or even a point-to-point connection.
- the ECU's 725A-725N which are merely representative and are not intended to represent an exhaustive list, receive inputs from video sensors 735, GPS device(s) 740, trailer sensors 745, hazard sensors 750, and tractor sensors 755. Depending upon the embodiment, fewer, more or different sensors can be used.
- the bus 730 also permits the ECU's to transmit control signals to tractor actuators 760, to provide data to and receive inputs from the driver via HMI 765, and to manage Cell and DSRC transceivers 770 and 775, respectively. Further, the bus 730 provides a link by which data from the various sensors and ECU'S can be stored on Data Storage 780.
- the various ECU'S 725A-N can comprise, among others. Radar ECU 725A,
- Other tractor ECU'S can also be implemented, as shown at 725M, and other trailer ECU'S can similarly be implemented as shown at 725N. It will be appreciated by those skilled in the art that the software comprising the vehicle control layer and the platooning supervisor layer can be distributed across one, some, or all such ECU'S.
- FIG. 8A the Platooning Supervisor Layer and its interaction with the Vehicle Monitoring and Control System 700 can be appreciated in greater detail. Except for the System 700, Figure 8A illustrates various software functionalities of an embodiment of the present invention.
- the Driver HMI functionality indicated at 765, interacts directly with the vehicle driver, and presents to the driver information from the System 700 as well as the Platooning Supervisor Layer as well as serving as the input mechanism for the Driver's commands and choices, for example, selections of a linking partner, or acceptance by the driver of an offered link.
- the NOC Communications Manager 800 establishes and maintains a secure communication link between the vehicle and the NOC, and provides the mechanism for passing messages reliably to and from the NOC.
- the NOC Communications Manager receives inputs from the Vehicle Monitoring function 805, the Hazards Monitoring function 810, the Software Update Management function 815, and the NOC itself.
- the Vehicle Monitoring functionality 805 samples and filters the vehicle state from any of the sources connected to the bus 730, based on requests from the NOC 720.
- the NOC 720 specifies what information is to be provided, and at what interval, or frequency, and also specifies how the data is to be processed before being communicated back to the NOC.
- the Hazards Monitor 810 "listens" on the Bus 730 for vehicle faults and communicates relevant vehicle faults to the NOC.
- the Hazards Monitor 810 also receives hazard alerts from the NOC, and, based on its inputs including vehicle status and environmental conditions, makes a local determination on whether to override a platooning authorization.
- the Hazards Monitor provides an Authorization Override to Authorization Management function 820, and also sends a hazards warning to the driver via HMI Services function 840.
- the Software Update Manager 815 responds to version queries and provides the
- the Hazards Monitor can locally override a linking authorization from the NOC in the event a condition is detected which either negates a planned linking, adjusts the platooning distance, or otherwise alters the conditions on which the authorization is based. Such conditions typically include vehicle status problems, or adverse environmental conditions. If the Hazards Monitor override is based upon a vehicle fault or other status issue, that fault or issue is also communicated to the NOC so that the NOC can take it into consideration when evaluating future linking involving the vehicle.
- Hazards override can result from issues external to the vehicle itself, such as weather, traffic or road conditions detected by other vehicles.
- issues external to the vehicle itself such as weather, traffic or road conditions detected by other vehicles.
- the information about the external issue can be communicated to the NOC by another vehicle, and then sent to the vehicle receiving the linking
- the onboard system passes the hazard information to the Hazards Monitor, which takes appropriate action to either cancel or modify the authorized linking.
- the Authorizations Manager 820 receives and interprets authorization packets from the NOC, via the NOC Communications Manager 800, in combination with absolute position, speed and heading information from the Vehicle Position Tracking function 825 [in turn received from the System 700] to help determine the proximity of the platooning partners proposed by the NOC, as discussed in greater detail hereinafter.
- the Authorizations Manager sends to the System 700 a link authorization status message together with a time to transition, i.e., a time at which the platooning partner is proximate and linking can begin.
- the Authorizations Manager also sends an identification of the selected platooning partner to Inter-vehicle Communications Management function 830, and, in some embodiments, sends to an Approach Guidance function 835 information regarding the selected platooning partner, its position, and guidance for linking.
- the Inter-vehicle Communications Manager 830 manages the mutual authentication of the platooning partners by providing security credentials to the System 700, typically communicated over a DSRC [Digital Short Range Communications] link.
- the Approach Guidance function 835 operates in two modes.
- the Approach Guidance function provides local approach guidance independent of the NOC, using position and speed information provided by the partner vehicle together with local vehicle tracking information, such as radar tracking status received from System 700 and data from Vehicle Position Tracking function 825.
- the guidance can comprise supplying the driver with none, some, or all of mapping, video and radar inputs, lane alignment, and any other data available from the system.
- the driver manually uses such data to position the vehicle for platooning, at which point the platooning controller engages and brings the vehicles to the desired platooning gap.
- the HMI Services function 840 provides the semantic layer for interaction with the driver of the vehicle, and converts status information from the vehicle, including the software layers, into relevant messages to the driver. In addition, the HMI Services function processes inputs from the driver.
- the HMI Services module provides presentation data to the Vehicle Hardware for display to the driver on the Driver HMI, typically a touchscreen display to permit easy entry of driver commands, choices, and other inputs. For the driver of the following vehicle, the display typically includes a video stream of the forward-looking camera on the lead vehicle.
- the software functionalities described above can be appreciated in the context of the software functions of the system as a whole.
- the Inter-vehicle Communications function 830 which includes management of DSRC Communications and Incoming Vehicle Signature Commands, discussed hereinafter at Figures 17A et seq. , sends messages to HMI Services function 840, which provides an interface to the Driver function shown at 765.
- Inputs from the driver interface 765 include link requests based on the driver's selection of a platoon partner. It will be appreciated that multiple potential platoon partners will exist on many routes, thus giving the driver multiple options. However, in some embodiments, such as a platoon partner.
- the platoon partner choices will be determined at fleet operations, for example where multiple trucks routinely follow the same route to the same or nearby destinations. In such instances the driver's options are either to accept the link or to reject it.
- the HMI Services function also provides to a Supervisor Layer 850 input events received from the driver, and receives from the Supervisor Layer presentation data.
- the HMI Services function comprises, in an embodiment, a GUI 840A, video feed 840B, physical inputs 840C, and audio inputs and outputs 840D.
- the Supervisor Layer includes a Link Management function 850A, cellular communications management 850B and data store and logging 850C.
- the Supervisor Layer also sends Link Authorizations and Vehicle Signature commands and data to a Platooning Controller function 855, and receives from that controller status messages including DSRC status, faults, and radar status.
- the Platooning Controller 855 comprises various functions, including Gap Regulation 855A, Mass Estimation 855B, Brake Health Monitoring 855C, Platooning Status 855D, and Fault Handling 855E.
- Gap regulation can involve setting a distance from the lead to the follow vehicle, or can involve setting a time headway from the back of the lead vehicle to the front of the follow vehicle. In either event, the objective is to ensure that the distance provides acceptable fuel economy benefits while at the same time ensuring the safety of both vehicles.
- the Platooning Controller receives inputs from the tractor representing status of various tractor functions, shown generally at Tractor Sensing 860.
- those functions include Lidar data 860A, Visual data 860B, radar 860C, GPS position 860D, wheel speed 860E, pedal position 860F, Engine Temperature 860G (sensed either from the block, from the engine bay, or other suitable location), steering 860H, inertial measurement 8601, brake pressure 860J, barometer and related weather sensing 860K, and combinations of such sensed data indicated as sensor fusion 860L.
- the Tractor Sensing function communicates bi-directionally with the Inter-Vehicle Communication module, in particular where some processing of the data related to vehicle signature occurs within the ECU'S associated with the Tractor Sensing functions.
- the Platooning Controller communications bi-directionally with the Inter-vehicle Communication module 830 regarding mass, position, velocity, torque/braking, gear and faults. More specifically, the Controller 855 receives, via the DSRC link, data about the other vehicle including mass, position, velocity, torque/brake status, gear, and faults.
- the Platooning Controller uses these inputs to provide the status data to the Supervisor Layer, as mentioned above, and also provides torque and brake commands, and gear. In the absence of a gear sensor, gear selection can be calculated for manual transmissions based on engine speed and tire rotation speed. Gear on automatic transmissions can be sensed directly from the Supervisor Layer, as mentioned above, and also provides torque and brake commands, and gear. In the absence of a gear sensor, gear selection can be calculated for manual transmissions based on engine speed and tire rotation speed. Gear on automatic transmissions can be sensed directly from the
- the Platooning Controller 855 also receives status and fault information from a Tractor Actuation function 865, which, in an embodiment, comprises the functions 865A-865F of steering, throttle, shifting, clutch, and braking as well as other driver-controlled actions such as a jake brake, etc.
- a Tractor Actuation function 865 which, in an embodiment, comprises the functions 865A-865F of steering, throttle, shifting, clutch, and braking as well as other driver-controlled actions such as a jake brake, etc.
- the driver [function block 765] can provide all of such inputs to the tractor actuation block 865, although both braking and throttle are under the control of the platooning controller 855 during linking and while linked as a platoon.
- a Tractor Indication function 870 comprising a Platooning Indication 870A, is also provided, and controls a physical indicator positioned on the tractor and visible to other vehicles proximate to the platoon.
- the physical indicator is typically enabled when a platoon is formed, and can also be enabled during the linking process.
- FIG. 9 the data processing which occurs on the vehicle can be better appreciated.
- the hardware starts up as shown at 900.
- the Data Bus handlers are registered with the system at 905, using either a default configuration or, if a
- a platoon authorization "listener” is started, whose function is to listen for platoon authorization messages from the NOC.
- the latest vehicle event data is processed, after which a check is made at 920 to see whether a platoon authorization notice has been received from the NOC. If so, at 925 the authorization record is posted to the controller by a software interface such as an API. If no platoon authorization has been received, a check is made at step 930 to determine whether a configuration change has been received from the NOC.
- the new configuration is implemented and alters what data is collected from the vehicle and reported to the NOC in a "breadcrumb" message, and a restart signal is sent to cause a loop back to step 905 where the data bus handlers are re-registered in accordance with the new configuration.
- step 940 a check is made to see if sufficient time has elapsed that position and status information are due to be sent to the NOC. If not, the process loops back to step 915. If so, the position and status information, or "breadcrumb" message, is sent to the NOC.
- the frequency at which such breadcrumb messages are sent to the NOC is, in at least some embodiments, defined by the configuration parameters received from the NOC, which parameters also define the event data that is to be sent to the NOC as part of the message. In at least some embodiments, the
- FIG. 10 illustrates an embodiment of the process by which connections between the NOC and the vehicle are managed.
- Service at the NOC starts as shown at step 1000, and the NOC waits for a connection from a vehicle on a known port, shown at 1005.
- the NOC validates the truck and opens a secure session, shown at 1010, followed by creating a publisher message with a message broker functionality as shown at step 1015.
- a publisher thread is then spawned at 1020, at which point the publisher connection and the network connection are passed to the thread.
- the thread listens for a message from the vehicle, for example a 'breadcrumb' message or an "I'm available for platooning" message, shown at step 1025. Once a message is received from the vehicle, shown at step 1030, the process loops and the NOC returns to listening mode at step 1025. If no message occurs within a given time window, the thread terminates as shown at step 1035.
- the process creates a subscriber message with a message broker as shown at 1040.
- a subscriber thread is then spawned at step 1045, and the subscriber connection and network connection are passed to the subscriber thread as shown at 1050.
- a check is made for queued messages at 1055, and any queued messages are sent to the vehicle at 1060. If there are no queued messages, or if the queued messages have been sent, the process advances to step 1065 and waits for the message to be published to the vehicle. The process then loops back to step 1060. In the event that the message could not be sent to the truck at step 1060, typically as the result of a connection failure, the messages are queued at step 1070 and the thread terminates at step 1075.
- Figure 1 1 A shows one embodiment of the coordination and linking functionality, indicated generally at1 100.
- a set of platoon-capable pairings is received.
- the set of pairings is, in at least some embodiments, received from the NOC and comprises a list of potential platoon partners.
- the driver may be presented with only a single platooning choice that is either accepted or rejected.
- the identification of platoon-capable partners can be generated locally.
- step 1 1 10 either the driver or the system identifies a vehicle available for coordination as a platooning partner, and a platooning offer is communicated as shown at 1 122, indicated in some embodiments by a self-acceptance message.
- the other vehicle the "far" vehicle
- the pair has agreed to coordinate for possible linking as shown at 1 130.
- a vehicle within linking range may be identified as a Following Vehicle Available for Linking 1 142 or a Leading Vehicle Available for Linking 1 144. If neither of these is the case, the system returns to coordination mode.
- the Self Vehicle then also accepts the link, step 1 155, initiating the link.
- the vehicles are now linked as shown at step 1 164.
- Other factors can include, for example, the proposed distance of the platoon, time duration, time of day, hours of service and related restrictions, fuel level and driving range, refueling possibilities, service level agreement issues, the need for the vehicle to be at a destination at a given time for further use or maintenance, driver meals and relief breaks, driver satisfaction, driver pay, traffic rules and regulations, etc. If a link is to be made, one or more of the factors can assist in informing the decision on which vehicle should lead, step 1 185.
- the route for a vehicle available for platooning must be known at least in part. This can be accomplished by generating a vehicle travel forecast, as shown in Figure 12.
- the process there starts by receiving position information for a vehicle, designated Vehicle A, at step 1200.
- the position information can comprise longitude/latitude information, or a coordinate pair plus speed and heading, or a series or trail of coordinate pairs.
- a GPS device as described in the foregoing figures, is suitable for providing such information.
- the process of Figure 12 continues by checking at step 1205 to determine whether Vehicle As route is known.
- vehicles such as large commercial trucks travel routes that are repeated frequently, or are set by a fleet manager or other supervisor.
- a particular vehicle's route is known and stored in a database, typically maintained at a NOC and, in at least some instances, also available locally. If, however, Vehicle As route is not known, a search is made at step 1210 for nearby routes that would be acceptable for platooning. The process of identifying such routes is discussed in greater detail in connection with Figures 14A-14B and 15A-15B.
- a travel forecast for Vehicle A is then generated in either a local or remote process, as shown at step 1235.
- the factors discussed above for developing a travel forecast one or more of the factors discussed in connection with Figure 1 1 B, above, are also considered in formulating the travel forecast for some embodiments.
- the travel forecast which is stored at the NOC in at least some embodiments, can then be used to search for potential platooning partners, as discussed in connection with Figure 13.
- the route information is fetched from the database of known routes. Vehicle As position is then compared to the known route, as shown at step 1245. If Vehicle A is off route, a determination is made at step 1250 as to where and when it is feasible for Vehicle A to rejoin the expected route. If rejoining is determined feasible, as shown at step 1255, the process loops back to step 1230 to provide Vehicle A with appropriate guidance for rejoining the route, followed by generation of a travel forecast. If it is not feasible for Vehicle A to rejoin the route, the process terminates, for the time being, at step 1260. A termination at either step 1220 or step 1260 is temporary, since platooning possibilities change as Vehicle As position on its route changes and, in at least some embodiments, vehicles report their changed position via breadcrumb messages.
- FIG. 13 One embodiment for such a search and linking process is shown in Figure 13, which can be seen to elaborate in some respects on the process shown in Figure 1 1 A.
- the process of Figure 13 begins with the receipt of a platoon request from Vehicle A.
- the request shown at step 1300, is received at a processor, located in the NOC in at least some embodiments but potentially located elsewhere in other embodiments.
- a travel forecast such as results from the process of Figure 12 is then either generated or retrieved, as shown at step 1305.
- a search of the travel forecasts stored in a database at the NOC, shown at 1315 is made to identify other stored forecasts with similar routing. Based on those similar routings, a list of potential platoon partners is generated in the processor.
- the driver selects from the list provided in step 1330, and a platooning offer is sent only to those partners selected by the driver of Vehicle A.
- the fleet operator determines the potential pairings and the driver receives only one choice, which can either be accepted or rejected.
- Vehicle As selection is retrieved, typically indicated by a manual or audible command from the driver.
- the responses from the potential partners, for example Vehicle Bi are shown at step 1350.
- a check for acceptance of the platooning offer is made at step 1355. Should there be no acceptances, Vehicle A's travel forecast is added, if not already stored, to the current travel forecasts database as shown at step 1325.
- step 1360 In most cases, Vehicles A and agree, in which case the process advances to step 1360.
- platoon approval is sent by the NOC, as discussed above in connection with Figure 8A-8B, together with advice for the respective rendezvous actions to be taken by Vehicles A and Bi .
- step 1365 the travel forecasts for Vehicles A and are removed from the database of current travel forecasts, since neither is currently available for platooning.
- platoons of more than two vehicles are permitted, in which case the travel forecasts of Vehicles A and are maintained in the database of current travel forecasts.
- the positions of vehicles A and B is monitored by the NOC, including during formation of the platoon and thereafter.
- the NOC monitors road and other conditions such as traffic, weather, construction, and so on, to identify conditions relevant to the platoon of Vehicles A and provides alerts to both drivers as well as providing relevant data or commands to the onboard systems for each vehicle.
- Such monitoring continues at least until the platoonable routing is completed, step 1380, or one of the drivers disengages, step 1385, after which the process stops at 1390.
- FIG. 14A illustrates one embodiment for a process for identifying platoonable road segments. The process initiates by breaking a roadway into segments based on any suitable criteria.
- a suitable criteria is to use mile markers, although latitude/longitude data and numerous other criteria can also be used. Then, each segment is evaluated to determine if it meets a basic criteria for platooning, as shown at step 1505.
- the basic criteria can include speed limit, known construction, known traffic choke points, excessive up- or downgrades, weather or other environmental problems, and so on.
- the process advances to step 1510, where the road segment can be evaluated in accordance with a class-specific criteria. Not all embodiments will use a class-specific criteria. However, some fleets or other traffic management systems may manage vehicles of various classes or types.
- the criteria appropriate for a platoon within a specific class may vary dramatically from the general criteria.
- the class-specific criteria may be less limiting than the general criteria noted above.
- the general criteria may be applicable for large commercial trucks, the class "18 wheelers", a fleet may also include smaller box vans or similar vehicles that can handle grades or other roadway conditions that the larger vehicles cannot handle.
- the segment is added to the database for the general criteria only, as shown at step 1515. However, segments that meet both the general criteria and the class-specific criteria are added to database including class-specific data.
- the process then advances to determine if there are other road segments to be analyzed, step 1525. If there are, the process loops back to step 1500 for the next segment. If not, the process terminates at step 1530.
- the results generated by the process of Figure 15A permit the comparison of a travel forecast with the database of platoonable roadway segments.
- the sections of platoonable roadway will be incorporated into the travel forecast developed by the process of Figure 12.
- the travel forecast includes only the routing, and the congruence of the routing with the database of platoonable roadway segments is determined by the appropriate processor at a later step.
- To identify a potential platooning partner requires not only that the vehicles travel the same route, but that they travel the same route at relatively close to the same time.
- the governor setting is accessible through the CAN bus [discussed at Figure 7B], and may be adjustable from the NOC.
- the rendezvous guidance may suggest speed adjustments for both vehicles.
- Vehicle A is typically guided to reduce speed to permit linking.
- an analysis of the time and routing for Vehicles A and B is performed at steps 1540 through 1555.
- the travel forecast for vehicle A is retrieved and at step 1545 the travel forecast for the first potential partner, is retrieved.
- the forecasts are compared for common road segments, shown at 1550. If there are sufficient common road segments, a check of the timing criteria is made. If that, too, indicates a potential platooning partner, then, for some embodiments where only a single class of vehicle is involved such as long-haul trucks, vehicle will be added to the list of potential partners for Vehicle A.
- a further check is made at step 1560 to determine whether the vehicles are in the same class. It will be appreciated that the step of checking the class could be done in any order. Further, in some embodiments an assessment of the cost-benefit of a platoon of Vehicle A and Vehicle is made in accordance with a predetermined criteria, as shown at step 1565. Potential partners that meet each of the applied tests are then added to the list of potential partners at step 1570 and then advances to step 1575.
- step 1575 the system checks to determine if other potential partners remain to be evaluated. If so, the process loops to step 1545 for the next potential partner. If there are no more potential partners, the process terminates at step 1580.
- Figure 16A-16E a visual representation of highway segments is provided to assist in understanding the identification of platoonable roadway segments and the development of a platoonable routing for a pair of vehicles.
- Figure 16A shows a section of roadway 1600 broken into segments, in this instance as determined by various mile markers such as 137.1 , 196.4, 233.1 and 255.6.
- Figure 16B overlaid on that road segment 1600 are smaller roadway segments 1605 and 1610 that are known to be unsuitable for platooning, such as a downhill grade indicated at 1605 and a construction zone indicated at 1610.
- the segment of roadway 1600 is platoonable except for the sections 1605 and 1610.
- the travel forecast for Vehicle A is applied to segment 1600.
- Vehicle A will travel on the road segment from mile marker 137.1 to mile marker 274.4, indicated at 1615.
- Vehicle B's travel forecast shows that it will travel on the road segment from marker 123.6 to 255.8, shown in Figure 16D and indicated at 1620.
- platoonable routing 1625 for Vehicles A and B is from marker 137.1 to marker 255.8, except for the downgrade and construction zone indicated at 1605 and 1610, as shown in Figure 16E.
- a ⁇ B ⁇ P [137.1 , 148.7] U [151 .3, 231 .4] U [234.5, 255.8]
- the total length ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ represents the maximum payoff of forming the platoon, i.e., the number of platoonable miles of the shared route.
- the set representation also forms the basis for creating a searchable database of current platoon opportunities, where, in an
- each record in the database contains at least:
- Truck identifier, expiration time, ... [00119] One challenge faced, at least occasionally, by vehicles seeking to travel in close proximity to one another, is to identify the partner vehicle or vehicles.
- vehicular traffic over a given section of roadway can involve multiple vehicles with similar
- Vehicle A is the intended partner vehicle for Vehicle B, indicated at 105. Both are proceeding in the same lane of a three lane roadway indicated at 1700. However, Vehicles C, D and E, indicated at 1705, 1710 and 1715, respectively, are all similar vehicles and all proceeding in the same direction as Vehicles A and B. In addition, Vehicles X, Y, W and Z, indicated at 1720 -1735, respectively, while smaller, are also proceeding in the same direction and inhibit relative movement between Vehicles A and B.
- Vehicles A and B are each able to communicate with one another, either directly through DSRC, microcell, or other wireless network, as indicated at 1740, and may also be able to communicate with one another via a proximate WiFi hotspot or similar, indicated at 1745. Further, Vehicles A and B may be able to communicate with one another via cellular data connection managed through a Network Operations Center (NOC) 1750.
- NOC Network Operations Center
- these communications links together with the sensors local to at least some of the vehicles shown in Figure 17A, can be used to affirmatively identify the vehicles to one another, or at least to allow the rear vehicle to identify the lead vehicle.
- a "sensed" vehicle typically the lead vehicle
- a "sensing” vehicle typically the trailing or following vehicle.
- These processes can be performed at a distance, or more closely, such that either vehicle to vehicle communication can use any available form of vehicle- to-vehicle communication.
- the process of identifying a sensed vehicle can, but need not in all embodiments, include fore-knowledge of various characteristics of the sensed vehicle.
- characteristics (if available) of the sensed vehicle can, taken together, comprise a "vehicle signature" of the sensed vehicle, thus allowing it to be identified by the sensors local to the sensing vehicle either alone or in combination with communications from either the sensed vehicle or the NOC.
- a sensed vehicle's signature can comprise either a natural action of the vehicle, or can comprise a purposeful action of the vehicle.
- a natural motion can comprise, for example, the vehicle's position and speed on the roadway as it navigates its intended route as though independent of any need to be sensed.
- a purposeful motion of the vehicle could be any of a lengthy list of arbitrary events, such as a lane change, speeding up or slowing down, flashing or blinking of either taillights or brake lights, or flashing of a platooning beacon, or any other suitable event that can be commanded remotely and can be reasonably performed without causing a safety risk.
- a process for detecting a sensed vehicle using the natural motion of that vehicle can be better understood.
- some identifying characteristics of the sensed vehicle are known to some part of the system, and are made available to the sensing vehicle. These characteristics can comprise route information, such as developed in accordance with Figures 12-15, above, or can comprise speed or position information, such as provided to the NOC in accordance with, for example, the breadcrumb messages shown in Figure 9, or other vehicle characteristics. In some embodiments date and time information may also be recorded along with position.
- the known characteristics can be provided by the NOC, or can be provided by vehicle-to- vehicle
- the process of Figure 17B begins at step 1753 by retrieving at the sensing vehicle such known characteristics of the sensed vehicle. Then, at step 1755, the sensors local to (i.e., on board) the sensing vehicle (1755B) monitor the vehicle signature event(s) determined by those known characteristics. At step 1760 the sensor data is compared to the vehicle signature identified by the known characteristics. If the two match, within a predetermined tolerance, the sensed vehicle is identified as the target vehicle, shown at step 1763, and the process ends. If not, the process advances to step 1765 to determine whether the vehicle signatures of other candidate vehicles remain to be evaluated. If so, the process loops back to step 1760, until the target vehicle is identified.
- the process redirects to the process shown in Figure 17C, where a purposeful vehicle signature is generated by the sensed vehicle. Likewise, if no more candidate vehicles remain, and the target vehicle has not been identified, the process can advance to step 1770, Figure 17C.
- step 17B While the exemplary process of Figure 17B is shown as capturing the vehicle signature of multiple candidate vehicles at step 1765, and then looping from step 1765 to step 1760 to process additional vehicle signatures, those skilled in the art will appreciate that the candidate vehicle signatures can be captured individually, for example serially, such that the process would loop differently, for example from step 1760 back to step 1755.
- the sensed vehicle is commanded to perform a particular, purposeful action to enable the sensing vehicle to identify the sensed vehicle by means of that purposeful
- the command can be generated by the system local to either the sensed vehicle or the sensing vehicle, or by the NOC. If the specific command is generated by the system or systems local to the sensed vehicle, the command can be, for example, in response to a message from either the NOC or the sensing vehicle that the sensed vehicle has not been identified. A time-out can also be used.
- the process of Figure 17C begins at step 1770 with the sensed vehicle being commanded to perform a purposeful maneuver or other commanded event, which it then performs at step 1775. If the source of the command is not the sensing vehicle, the sensing vehicle is provided the type of commanded event at step 1780, where the sensing vehicle captures the intended purposeful vehicle signature of the sensed vehicle.
- the purposeful vehicle signature may be provided to the sensing vehicle in advance of, or contemporaneous with, or after, the performace of the commanded event by the sensed vehicle.
- the sensing vehicle uses its local sensors to capture the vehicle signatures of all candidate vehicles.
- the expected vehicle signature is compared to the vehicle signature of the first (or next) candidate vehicle as detected by the local sensors. If they match within a predetermined tolerance, the sensed vehicle is identified as the target or potential partner at step 1795 If not, the process advances to step 1797 to determine whether more candidate vehicles remain to be processed. If so, the process loops back to step 1790 and the next candidate vehicle signature is processed. In most instances, the sensed vehicle will be identified. However, if for some reason the sensed vehicle cannot be identified, the process aborts at 1799 in some embodiments. Alternatively, the process of Figure 17C simply restarts by commanding the sensed vehicle to perform a different event to provide a purposeful vehicle signature.
- Figure 18A illustrates an embodiment of a process by which the back of the lead vehicle can be identified by the trailing or following vehicle.
- the process of Figure 18A is used is where the sensing vehicle knows some characteristics of the lead vehicle, but not its length, and can use its local sensors to determine other data sufficient to identify the back of the lead vehicle.
- the known characteristics can include one or more of: lane position, velocity, vehicle characteristics, information communicated V2V such as via DSRC or similar short range wireless links, relative GPS information, absolute GPS information, information communicated from the NOC, etc.
- the local sensors can include one, some or all of the sensors identified in Figure 8B, including radar, lidar, video or camera, etc. The interaction of the Vehicle signature functionality with the tractor sensors, Supervisor Layer and
- Platooning Controller are shown in Figure 8B and discussed in connection with that Figure.
- the process of Figure 18A begins by using sensors local to the following vehicle to detect the back of the lead vehicle, shown at step 1800.
- the data will be provided by sensors local to the sensing vehicle, or based on instructions received from the NOC, in some embodiments data can be determined visually by the driver, for example, if the length of a trailer is marked on the side or back of the trailer in a way that is not readily determined by the system.
- the known vehicle for example, if the length of a trailer is marked on the side or back of the trailer in a way that is not readily determined by the system.
- the characteristics of the sensed vehicle are retrieved if not previously received and stored, after which a comparison is made at step 1810 between the sensed rear of the vehicle and the known characteristics. Because multiple local sensors can be used to determine the back of the lead vehicle, in at least some embodiments comparisons are made among the results from the local sensors, and, if consistent, the multiple sensing modalities are used to confirm the location of the rear of the lead vehicle. In some instances, no vehicle characteristics are known, and only the multiple modalities of the local sensors are used to identify the rear of the lead vehicle. However, in those instances where vehicle characteristics are provided at step 1805, that additional data provides further confirmation of the length of the lead vehicle.
- GPS data can be particularly useful, where relative position is determined rather than absolute position. However, if GPS-based relative position data is used, it is important to know the location of the GPS receiver within the lead truck, and to adjust vehicle length accordingly.
- Radar data can also be very helpful in identifying or confirming the back of the lead vehicle with respect to the following vehicle.
- radar can be helpful in making an initial determination of which vehicle is the communicating partner.
- the structures in the vehicle that reflect radar waves can, in some instances, provide a signature pattern that assists the system of the sensing vehicle to identify the sensed vehicle.
- the native radar signature of a particular vehicle, such as a tractor, trailer, or automobile can be augmented by the addition of a radar reflector of a sufficiently unique shape that it permits easy identification of the desired characteristics of the sensed vehicle.
- the vehicle length is calculated at step 1815, and, in at least some
- the length is stored at step 1820.
- the gap between the lead and trailing vehicles can then be controlled and adjusted to permit improved performance while taking into account the prevailing operating conditions, as shown at step 1825.
- the check at step 1810 negates the confirmation, the process loops back to step 1800 and repeats. In the event of repeated failures, the process can be aborted in at least some
- the length of the vehicle is known in advance, and can be communicated to the trailing vehicle.
- some operators of truck fleets maintain a database shown the length of each trailer in combination with a unique identifier such as serial number.
- the process of Figure 18B can be used to identify the rear of the lead vehicle.
- the length of the vehicle and other known vehicle characteristics are retrieved from either the NOC, the local storage, the lead vehicle, or any other location accessible to the system on board the trailing vehicle, as shown at 1835. Based on that information, the expected back of the lead vehicle is calculated or otherwise determined at step 1840.
- the local sensors detect the back of the sensed vehicle as as step 1800, and the expected back of the lead vehicle is compared to the detected back of the lead vehicle at step 1850. If the comparison is a match, the process advances to step 1855 and the sensing vehicle identifies the sensed vehicle as the target or potential partner. Based on that, the system can adjust the gap distance between the vehicles based on length and operating conditions, as with Figure 18A. However, if the comparison at step 1850 fails to yield a match, the process loops back to step 1830 until either a match is confirmed or the system terminates unsuccessfully.
- the fusion of the data from local sensors with the data available either through DSRC or other short-range communications channels, or from the NOC yields more reliable and more accurate information than any single modality or source taken alone. This increased accuracy permits better vehicle management both when the vehicles are maneuvering into close proximity substantially under manual/driver control, and while that close proximity is being maintained in a semi-automatic mode.
- the fusion of such sensor data with communications links can provide a safer environment for fully automated vehicles of any type, especially where all vehicles on a roadway are equipped with compatible sensors, communications links, and control systems as disclosed herein.
- GPS position data is used at least to guide potential partner vehicles into close proximity, and in some embodiments, as discussed above, is used to provide relative position data; that is, the position of a first vehicle to a second vehicle such as the lead vehicle and the following vehicle in a platoon.
- relative position data that is, the position of a first vehicle to a second vehicle such as the lead vehicle and the following vehicle in a platoon.
- the accuracy of relative GPS position data can be within a few centimeters, and thus provides valuable data for managing the gap between the vehicles.
- Figure 19A illustrates a real world scenario where Vehicle A, indicated at 100, and Vehicle B, indicated at 105, are traveling at different points along the same roadway and in the same direction as shown by the arrows.
- obstructions such as those shown at 1900 and 1905 can prevent the GPS receiver in each vehicle from seeing the same satellites that are seen by the other vehicle. Differences in the set of satellites used by the two vehicles can cause significant errors in sensed relative positioning between the vehicles.
- obstruction 1900 can be a berm adjacent a portion of the roadway, sufficient to block vehicle A from seeing satellite 1910.
- obstruction 1905 can be a large building adjacent a roadway, and prevent vehicle B from seeing satellite 1915 or prevent both vehicles A and B from seeing satellite 1920.
- both vehicles A and B can see satellites 1925A-1925D, which is typically adequate for obtaining reliable GPS relative position data.
- the process of Figure 19B begins with each vehicle's GPS receiver identifying the satellites it sees at that time, shown at steps 1930A, 1930B. Each vehicle then sends to the other the satellites that that vehicles sees, shown at 1935A-1935B, or, optionally, one vehicle sends the satellites it sees to the other but the second vehicle does not send that information to the first vehicle.
- data representing which satellites are viewable by each vehicle at that time is sent to the cloud/NOC for storage as shown at 1940A-1940B.
- location information for the vehicles is also sent to the cloud, although the transmission of position information can occur as part of the breadcrumbs message shown in Figure 9 rather than being separately sent in the process of Figure 19B.
- the data is stored as shown at 1945A-1945B.
- the data can also include date and time information.
- one vehicle may transmit its satellite data to the other vehicle and leave the other vehicle to manage communication of that data to the NOC.
- load sharing permits better utilization of the communications links as well as permitting the non-responsible vehicle to perform other tasks.
- one or both vehicles determine which ones are the commonly viewable satellites, or other optimal set of satellites, and limits their GPS receivers to relying upon only the pseudoranging data from either the commonly viewable satellites or other optimal set of satellites as shown at step 1955.
- the limitation can be imposed either in advance of processing, such that only certain inputs are considered, or it can be imposed after processing by not considering the data from satellites that are not commonly viewable or otherwise part of the optimal set.
- FIG. 19C an embodiment in which the cloud determines which satellites should be relied upon by each vehicle can be better understood.
- vehicles A and B each determine which satellites they can each view, shown at 1960A-1960B. Again, each sends its satellite information to the cloud, steps 1965A-1965B, or, alternatively, one offloads its satellite data to the other and allows the other to manage communications with the cloud.
- the satellite IDs viewable by each vehicle's GPS receiver are stored in the cloud, steps 1970A-1970B and including date and time in at least embodiments, where the NOC or other cloud-based system determines which satellites should be relied upon by each vehicle and messages both vehicles accordingly, step 1975.
- the NOC or other cloud service receives location information for each vehicle, such as shown in Figure 9, in a manner that allows correlation with the satellite data.
- the process of Figure 19C permits vehicles C and D to rely on information maintained in the cloud regarding the satellite that are commonly viewable along a given route.
- vehicles C and D each provide their location, date and time information to the cloud in the routine manner.
- the cloud-based service or NOC retrieves from its database the stored data for which satellites are viewable at the locations of vehicles C and D at those dates and times. The cloud then determines the commonly viewable satellites and messages vehicles C and D accordingly.
- pseudorange data from satellites that are substantially collinear with the vehicles velocity vector Referring next to Figure 20A, for example, assume that vehicles A and B, indicated at 100 and 105, respectively, are traveling in close proximity along a mountainous roadway. Because mountains rise up on either side of the roadway, satellites positioned laterally to the vehicles are not visible. At the same time, Satellites 2000, 2010 and 2020 are visible, and they are substantially collinear with the roadway. Thus, vehicle A has line of sight 2000A to satellite 2000, line of sight 201 OA to satellite 2010, and line of sight 2020A to satellite 2020. Vehicle B has similar lines of site as indicated on Figure 20A. [00141] In such an arrangement, relative position data for vehicle A with respect to vehicle B can be determined by the process shown in Figure 20B.
- the process starts at steps 2030 and 2040 with each vehicle's GPS receivers collecting the available pseudorange data from satellites 2000, 2010 and 2020. Then, at step 2050, the pseudorange data is combined by either vehicle's control system or by a cloud-based server. Finally, at step 2060, the combined pseudorange data provides the gap distance between vehicles.
- the gap distance determined in this manner can, of course, serve as one modality of measuring gap, and used for validation of gap distance as measured by the vehicles' local sensors in the various manners discussed above.
- FIG. 21 A One approach to maintaining platoon position on an incline is to anticipate the occurrence of the incline, and to increase engine torque by an amount appropriate for the imminent incline.
- FIG. 21 A vehicles 100 and 105 are traveling down a roadway 2100, with incline 21 10 fast approaching.
- the overall incline may include more than one incline section, as shown at 2120.
- the process of Figure 21 B can be implemented. In particular, the process of Figure 21 B involves retrieving road grade
- the road database is augmented to include grade information, including identification of the location within a roadway segment where the incline begins.
- grade information including identification of the location within a roadway segment where the incline begins.
- Such data can be readily developed from the truck performance data provided to the NOC.
- the process of Figure 21 B starts by retrieving route information including grade information from the route database, shown at step 2130.
- step 2140 the time and distance to the upcoming grade is determined, followed, at step 2150, by determining the amount of torque adjustment appropriate to maintain platoon formation on the upcoming grade, as well as the appropriate time to modify the engine torque to achieve that adjustment.
- Those parameters are then passed to the control system [see Figures 8A-8B, above] to cause the vehicle to respond accordingly.
- the amount of engine torque increase, acceleration, or other change to vehicle command, and the time at which is can be best applied, can vary based on a number of factors, including vehicle performance, vehicle load, and other issues of vehicle performance which will be appreciated by those skilled in the art given the teachings herein.
- the present invention provides devices, systems and methods for vehicle monitoring and platooning, including in some
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Aviation & Aerospace Engineering (AREA)
- Automation & Control Theory (AREA)
- Traffic Control Systems (AREA)
- Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
Abstract
Description
Claims
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201514855044A | 2015-09-15 | 2015-09-15 | |
US201562249898P | 2015-11-02 | 2015-11-02 | |
PCT/US2016/049143 WO2017035516A1 (en) | 2015-08-26 | 2016-08-26 | Devices systems and methods for vehicle monitoring and platooning |
PCT/US2016/060167 WO2017070714A1 (en) | 2015-09-15 | 2016-11-02 | Vehicle identification and location using senor fusion and inter-vehicle communication |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3353615A1 true EP3353615A1 (en) | 2018-08-01 |
EP3353615A4 EP3353615A4 (en) | 2019-04-10 |
Family
ID=58558196
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP16858471.2A Withdrawn EP3353615A4 (en) | 2015-09-15 | 2016-11-02 | Vehicle identification and location using senor fusion and inter-vehicle communication |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3353615A4 (en) |
CA (1) | CA3004051A1 (en) |
WO (1) | WO2017070714A1 (en) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10520581B2 (en) | 2011-07-06 | 2019-12-31 | Peloton Technology, Inc. | Sensor fusion for autonomous or partially autonomous vehicle control |
US20170242443A1 (en) | 2015-11-02 | 2017-08-24 | Peloton Technology, Inc. | Gap measurement for vehicle convoying |
US10520952B1 (en) | 2011-07-06 | 2019-12-31 | Peloton Technology, Inc. | Devices, systems, and methods for transmitting vehicle data |
US10254764B2 (en) | 2016-05-31 | 2019-04-09 | Peloton Technology, Inc. | Platoon controller state machine |
US11334092B2 (en) | 2011-07-06 | 2022-05-17 | Peloton Technology, Inc. | Devices, systems, and methods for transmitting vehicle data |
US9582006B2 (en) | 2011-07-06 | 2017-02-28 | Peloton Technology, Inc. | Systems and methods for semi-autonomous convoying of vehicles |
US11294396B2 (en) | 2013-03-15 | 2022-04-05 | Peloton Technology, Inc. | System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles |
US20180210463A1 (en) | 2013-03-15 | 2018-07-26 | Peloton Technology, Inc. | System and method for implementing pre-cognition braking and/or avoiding or mitigation risks among platooning vehicles |
US10369998B2 (en) | 2016-08-22 | 2019-08-06 | Peloton Technology, Inc. | Dynamic gap control for automated driving |
JP6690056B2 (en) | 2016-08-22 | 2020-04-28 | ぺロトン テクノロジー インコーポレイテッド | Control system architecture for motor vehicle |
CN116203551A (en) * | 2016-11-02 | 2023-06-02 | 佩路通科技股份有限公司 | Gap measurement for vehicle navigation |
GB2572210B (en) * | 2018-03-23 | 2020-09-16 | Jaguar Land Rover Ltd | Controlling vehicle platooning |
US10899323B2 (en) | 2018-07-08 | 2021-01-26 | Peloton Technology, Inc. | Devices, systems, and methods for vehicle braking |
US10762791B2 (en) | 2018-10-29 | 2020-09-01 | Peloton Technology, Inc. | Systems and methods for managing communications between vehicles |
US11173921B2 (en) * | 2018-11-19 | 2021-11-16 | Micron Technology, Inc. | Sensor fusion to determine reliability of autonomous vehicle operation |
US11427196B2 (en) | 2019-04-15 | 2022-08-30 | Peloton Technology, Inc. | Systems and methods for managing tractor-trailers |
CN112750297B (en) * | 2019-10-31 | 2022-09-16 | 广州汽车集团股份有限公司 | Fleet control method, scheduling processing system, vehicle and control system |
EP4002320A1 (en) * | 2020-11-24 | 2022-05-25 | Volvo Autonomous Solutions AB | A method for cooperative adaptive cruise control |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3681241B2 (en) * | 1996-11-19 | 2005-08-10 | 松下電器産業株式会社 | Relative position calculation device |
JPH112675A (en) * | 1997-06-13 | 1999-01-06 | Mitsubishi Electric Corp | Relative position detecting system and relative position detecting device |
US8380362B2 (en) * | 2009-07-10 | 2013-02-19 | The Boeing Company | Systems and methods for remotely collaborative vehicles |
JP2011106870A (en) * | 2009-11-13 | 2011-06-02 | Toyota Motor Corp | Relative position calculation apparatus |
US9766350B2 (en) * | 2013-07-29 | 2017-09-19 | Hitachi Construction Machinery Co., Ltd. | Relative position calculating system for work machine |
US9079587B1 (en) * | 2014-02-14 | 2015-07-14 | Ford Global Technologies, Llc | Autonomous control in a dense vehicle environment |
-
2016
- 2016-11-02 EP EP16858471.2A patent/EP3353615A4/en not_active Withdrawn
- 2016-11-02 CA CA3004051A patent/CA3004051A1/en not_active Abandoned
- 2016-11-02 WO PCT/US2016/060167 patent/WO2017070714A1/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
CA3004051A1 (en) | 2017-04-27 |
WO2017070714A9 (en) | 2017-06-29 |
EP3353615A4 (en) | 2019-04-10 |
WO2017070714A1 (en) | 2017-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11100211B2 (en) | Devices, systems, and methods for remote authorization of vehicle platooning | |
EP3353615A1 (en) | Vehicle identification and location using senor fusion and inter-vehicle communication | |
JP7005526B2 (en) | State machine of platooning controller | |
WO2017035516A1 (en) | Devices systems and methods for vehicle monitoring and platooning | |
JP2018531474A6 (en) | Vehicle monitoring and platooning apparatus, system, and method | |
US20190279513A1 (en) | Vehicle convoying using satellite navigation and inter-vehicle communication | |
WO2018039114A1 (en) | Systems for vehicular platooning and methods therefor | |
RU2761270C2 (en) | System and method for providing transportation | |
US20200080853A1 (en) | Systems and methods for rendezvousing | |
US11345359B2 (en) | Autonomous driving vehicles with dual autonomous driving systems for safety | |
WO2018036197A1 (en) | Driverless vehicle control method, terminal, server, and system | |
CN113366544A (en) | Method and system for establishing cooperative driving engagement with vehicles having different levels of autonomy | |
GB2560111A (en) | Autonomous vehicle towing | |
CN110267857B (en) | Vehicle exterior track for difficult situations | |
US10996668B2 (en) | Systems and methods for on-site recovery of autonomous vehicles | |
JP2017151041A (en) | Driving support device and center | |
WO2019046164A1 (en) | Systems and methods for changing a destination of an autonomous vehicle in real-time | |
JP2019530609A (en) | Modular architecture autonomous vehicle | |
EP4241146A1 (en) | Systems and methods for dynamic data buffering for autonomous vehicle remote assistance | |
JP2019046034A (en) | Rank traveling management device | |
KR20220014790A (en) | Autonomous vehicle stations | |
JP2014048297A (en) | Route calculation method using central station | |
US9463799B1 (en) | Control for a high or fully automatic driving function | |
US20240232319A9 (en) | Devices, systems, and methods for remote authorization of vehicle platooning | |
US11386783B2 (en) | Guiding device for at least one vehicle |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20180601 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: O'CONNOR, MICHAEL Inventor name: SMARTT, BRIAN Inventor name: SWITKES, JOSHUA P. Inventor name: STANEK, GANYMED Inventor name: LYONS, DAVID FREDERICK Inventor name: GERDES, JOSEPH CHRISTIAN Inventor name: SCHUH, AUSTIN Inventor name: PRICE, CHARLES A. |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
A4 | Supplementary search report drawn up and despatched |
Effective date: 20190313 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G01S 19/51 20100101ALI20190306BHEP Ipc: G08G 1/0968 20060101AFI20190306BHEP Ipc: G08G 1/123 20060101ALI20190306BHEP Ipc: G05D 1/02 20060101ALI20190306BHEP Ipc: H04W 4/40 20180101ALI20190306BHEP Ipc: G08G 1/00 20060101ALI20190306BHEP Ipc: G08G 1/16 20060101ALI20190306BHEP Ipc: G01S 19/28 20100101ALI20190306BHEP Ipc: H04W 12/04 20090101ALI20190306BHEP Ipc: H04W 12/02 20090101ALI20190306BHEP |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20191009 |