Seeing how 2001 is irreversibly behind us, and 2010 is just behind the corner, I feel some unrest that not only there are still no flying cars, but also that I have to actually drive my car every weekday morning to work, instead of using that time to drink my cup of coffee. It’s one thing to enjoy driving, the road, fresh air, the scenery. But when I’m in traffic of thousand other cars, surrounded by traffic lights, smog, billboards and stress, it’s not driving anymore. It’s more of a struggle to get from point A to point B. In such cases being behind the wheel could be quite a chore.
Being able to read morning news, drink a cup of coffee, or work right from the car when traffic is extremely heavy… All these thoughts push me to write my view of how a fully autonomous vehicle is automated.
The EUREKA Prometheus Project and more recent DARPA Grand Challenge have all concentrated primarily on the car itself. And while perfecting automation of single entity is definitely a worthwhile pursuit, I do not think it alone will be enough for driverless car to become a reality. Isolated intelligence is limited in it’s isolation, and as deviation from reality could constantly grow, it will inevitably need human intervention. So instead of reading newspaper and sipping your favorite drink, you’ll need to pay attention to the road anyway, just in case your driverless car will mistaken something for something. This makes driverless car not driverless at all, but driver assisted.
I think we need to automate more than a car. Not to the point of building wireless transmitters every hundred meters, but enough to keep most events under control. My idea is comprised of three aspects of automation:
- Automated car
- Distributed Arbiter
- Road State Database
First, the automated car. For my implementation the current state of car automation stemming from above mentioned projects is already advanced enough. Therefore primary changes will be mainly related to integration with the other two aspects.
Distributed Arbiter is a relaying device with limited intelligence that will be installed into every traffic light. It will be able to make decisions on local level, like guide an automated car through intersection, or stop an automated car if there is an immediate danger. It’s primary function is to control incoming cars by means of synchronizing with it’s immediate peers and Road State Database and also by radar-like scanning of it’s assigned side of intersection for potentially dangerous situations (e.g. incoming manually controlled vehicles, pedestrians, etc.). Communication components are active radar to scan the immediate vicinity for moving objects, wireless communication module operating in regulated frequency ranges to communicate with automatic vehicles, and wred communication module, to communicate with peer distributed arbiters and Road State Database. Device is always installed as part of standard traffic light system, inside a traffic light. This provides for best overview of immediate area for radar scanning and backward compatibility with manual vehicles – using standard light signals to control their movement.
Decision intelligence will be central in form of Road State Database (RSD). RSD will gather information about state of road segments (stretches of road between traffic lights), congestion, road accidents, road works, etc… and based on these facts system will make a decision of where the car should go. A central decision point, it’s primary functions are to collect state information from every distributed arbiter and communicate decisions back to arbiters. Whenever any distributed arbiter detects a change, it is reported to RSD. Based on that information RSD calculates best path to take for automated vehicles, taking into account vehicle capabilities (maximum speed and acceleration), segment length and its speed limit, number of arbiters in path, congestion calculated from queue size before arbitration, average segment transit time as compared to predicted time (e.g. unknown obstacle), unreachable arbiters (untrusted segment). Segment in this case means stretch of a road between two arbitration points, usually two intersections.
After entering an automated car, a passenger will enter intended destination. The car will not actually care too much about the destination. It’s only signal will be to start moving. An arbiters or similar low cost guiding device that will be installed near parking areas (e.g. near light bulb of lamp posts for redundancy and high overview) will guide the car to the nearest Distributed Arbiter along the road segment. When in proximity of Distributed Arbiter, following actions will take place:
- Traffic light and distributed arbiter informs the car of it’s presence and commands the position to wait for signal in case the decision will not be made by then.
- Car acknowledges receipt of command and information. If it does not, the traffic light goes to first step and increments an error counter.
- Car sends information about it’s destination, which distributed arbiter relays to Road State Database.
- Since Road State Database (RSDB) has complete overview of all states of all Distributed arbiters and destination addresses, it makes a firm decision on where the car should go. If some roads are congested, it will route the car to longer but much less congested direction. If there is distributed arbiter failure, it will route the car to the working one. RSDB will have at least all the robustness of OSPF routing protocol.
- Distributed arbitrer informs all of it’s immediate neighbors servicing the intersection about the RSDB decision.
- Neighbors confirm the information and all synchronize the state of their input queues (queue length, queue tendency, dangerous behaviour, fast incoming vehicles etc.)
- Distributed arbiter either commands the car (informs it about decision) including time to carry out the Command, or commands it to hold.
- Car acknowledges the command.
- In this case, the command from arbiter was to turn right. Car follows predetermined path guided by arbiter at the time when the situation was safe enough for time to cross intersection. This is achieved by synchronizing timers and every arbiter scanning it’s own side of the intersection for potentially dangerous situation (e.g. manually controlled cars).
- After change is completed, in this case since a car cleared left the input queue of one arbiter and moved to the output queue of another arbiter, all changes are synchronized by all immediate arbiters to the RSD. This process can optionally be optimized that only one arbiter synchronizes the state to RSD on behalf of the intersection.
- RSD acknowledges new state back to the arbiter(s).
Car then travels along a road segment, from one traffic light to another, constantly being guided by arbiters and RSD, until destination is reached. Destination will be communicated by last arbiter in form of “travel 850 meters, then find a place to park”. This info will be generated by RSD based on presence of parking areas. Local parking lot arbiter will then guide an automated car to the parking spot.
Passenger will then be notified of arrival.