Brad Templeton Home


Robocars
Main Page


Brad Ideas
(My Blog)


Robocar Blog


My Forbes Articles


(Book from 2008)


The Case

Roadmap

Roadblocks

Car Design

Problems

Privacy

Stories

Deliverbots

Whistlecars

Future Transit

Objections

Myths

Geeks

Competition

Parking

PRT

Accidents

Notes

Teams

Government

Regulation

Motornet

Urban Planning

Development

Congestion

End of Transit

Definition

Statistics

Glossary


Sidebars: Charging

Speed Limits

NHTSA Levels

Valley of Danger

Simulator

Google Cars

The Motornet -- Robocars and data

The Motornet -- Robocars and data

While robocars should be able to operate autonomously, relying on no more than GPS (if even that) from the outside world, they will be better if they can be part of a data network. This network will be some time coming, and other than today's wireless data cloud services, is not something you use in version one, but it has potential for the future.

This data network would likely consist of several levels. There would be broadcast data aimed at cities, streets, intersections and spaces, and there would be point to point transmissions (internet style) between cars and network services. There are plans in the ITS community for vehicle to vehicle (V2V) direct networking, along with direct links between the vehicle and roadside infrastructure (V2I).

Since robocars must be able to know about everything from signs to pedestrians, it is not possible to depend on data transmitters for safety functions, though they can act as an added input.

Here's some of the data that might flow on this motornet to make a robocar (or other advanced networked cars) work better.

Map and Data Updates

Storage is so cheap that all networked cars will likely keep a complete set of maps of everything they can in the system. Not just street maps but full details on where everything should be -- driveways, curbs, street numbers, lanes, signs, traffic lights etc. A good robocar should detect all these things with its own sensors, but the database will be a 2nd voice -- if the database and the sensors disagree, that's time for further examination. If the either the database or the camera reports a stop sign -- that's a good indication to stop. The database also will be used for planning what to do in the future.

If the database gets wrong, humans in the cars, and often the automated systems in the cars, will point this out, and this will quickly lead to corrections so the database remains very accurate. Of course, the vehicle will never drive somewhere just because the database says there is a road there. This it will confirm with sensors at all times. But it probably will need a manual override to drive where the database falsely says there is a building.

Live traffic signal and traffic broadcasts

Broadcasts should reveal the timing schedule for every traffic light, so robocars can plan trips. In addition, the traffic density and speed on every street should be broadcast to help pick routes. Broadcasts will include not just current conditions but predictions for future conditions. These predictions will be generated from algorithms and from data from cars that have said they intend to be in certain areas during certain time windows.

The ITS plans include actual broadcasts from traffic lights using the I2V protocols. This requires expensive intersection upgrades, however, so its deployment will be slow. In some cases signals already are in communicaiton with central servers, and in these cases the WAN (cellular) networks may be fine for this as long as the time of signal switching can be predicted a second or two in advance. (Lights which want to change on an instant's notice might still need I2V.)

Reservations

A robocar might ask a central computer for reservations for various resources, including parking spots, or a moving piece of pavement. Traffic lights might even change because many robocars announce a plan to use an intersection at a given time.

Indeed, 4-way stops could become virtual traffic lights for robocars. In this situation, robocars would make reservations to allow them to blow through the stop sign if there are no HDVs or pedestrians in the intersection. HDVs would still stop (like any 4-way stop today) but robocars could make reservations and flow through like there is no stop sign.

Some programmers have designed algorithms to even do live intersections. These are level crossings, but all the cars get a reservation for when they will pass through. Reservations are handed out in a way that no car hits another car, even though cars are going through in both roads at the same time.

Earlier I pointed to a simulation of such a system at U of Texas. Try the 6-lane version. I think this would scare people until they became very trusting of the system, though.

Reservations could also be made for congested areas. There is no point in entering a congested zone, and in fact proper management of congested zones involves making sure they are never used beyond capacity. Better to let the zone decide how many cars to allow to enter for smooth flow. Just as it does no good to zoom up to a red light, it does no good to be the car that oversaturates a road. This is what metering lights do, in effect. If too many cars want to use one road, better for you to use the one next to it.

When requested time-slots are not available to a robocar, it will just slow down its trip so that it doesn't arrive too early. If it is known well in advance that slots are not available right away, the start of the trip may be delayed, so the passengers don't waste time waiting. More advanced metering could involve waiting at home rather than waiting in an on-ramp inching up to a light.

Road clearing signals

Robocars can park anywhere, even places like driveway entrances that normally one should not block. That's because a transmitter at the driveway can send a signal asking that robocars remove themselves temporarily from the area. When driving you home, if your own robocar wishes to park in your driveway or garage, then a minute before it gets to the house, it would signal the house, and the house would send a local signal of "any cars in our driveway, please clear out." Those cars would move out quickly and you would arrive, never even having been aware they were there.

When it's time to leave, the data signal could work again, but any smart robocar would simply move out of the driveway in tandem with your car as soon as they see it getting ready to move.

This protocol allows a huge increase in the available parking in today's cities. Indeed, as traffic volumes decrease, robocars could park or double park or even triple park on wide streets, leaving only a single lane at times when traffic volumes are low enough that a single lane will do. Even New York City or old world cities may find they have enough parking for robocars.

Trust relationships

Robocars will attempt to identify and communicate with any other cars near them on the road. They will determine of those cars are robocars or HDVs, and what models they are. This will allow them to learn things about those cars like stopping distances, reaction times, acceleration and turning abilities and so on.

In addition, they will get a certificate to determine if they can trust a vehicle. This means trust of its characteristics, but also trust that it will perform coordinated moves when needed.

For example, in the school of fish test, if you see an obstacle on the road ahead, you will need to swerve. But if traffic is very thick you won't be able to swerve if there is a vehicle on either side of you. Unless that vehicle tells you that it has a blank space on the other side and it will swerve if you request it -- clearing a blank space for you to swerve into.

Any robocar should do that, without any special negotiation of course. Any robocar that sees a vehicle moving into its space should move into any safe spot it can find, just as a quickly reacting human would. If trust is established, the car can decide that it can depend on such behaviour. Normally a robocar will be trying to assure it has an "out" for any unexpected situation, like a pedestrian stepping on the road, or an accident happening in front of it. One can have these outs at all times if traffic density is low enough to leave enough gaps. And that's not all that low -- normal human traffic usually has plenty of gaps for an astute driver to use.

However, if you decide you can trust other vehicles to swerve as quickly as you can, you can get away with fewer gaps and still escape almost any obstacle. Of course, if the trust is misplaced, there will be an accident -- but there will be a record of who is at fault.

Generally robocars will go through a certification process. A basic process will assure they can be safely operated on the roads, not unlike a drivers' licence. Private entities might do higher levels of certification, so that you will know what cars you can count on to deal with emergency situations.

HDVs will not be trusted in the same way, and will require more gaps. This is how it works today. Experimental robocars and owner-modified robocars will also not get the certification as trustworthy, and thus will require more gaps to keep the situation totally safe.

Of course all cars, trusted or not, HDV or robocar, should send out data signals when they have to brake unexpectedly, or turn. This is just a more reliable version of brake lights and turn signals, which robocars will also flash, and need to be able to decode.

Mesh Networking and V2V

While most motornet data flows will not require high bandwidth, if they do, cars can mesh network to provide very high bandwidth short haul links. As those can't be counted on, crucial data will still go over links to fixed locations. If the density of networked cars gets high enough, mesh networking might become reliable, and then it can be used for time critical applications. This is a long way away.

Road Conditions

One useful bit of data from other cars would be live reports on road conditions. As each car goes over the road, it can notice bumps, potholes, wet spots and icy spots. If wheels every lose grip, this can be recorded and reported to the cars that are following.

While GPS is not accurate enough to spot such items, optical markers on the road or sides of the road would allow cars to get very accurate location data when they exist. This would allow the next car to know exactly when it will hit a patch of ice, and to prepare for it.

Occluded vehicles

If vehicles are transmitting their location using the Connected Vehicle/ITS protocols (A radio system known as DSRC, 802.11p, WAVE and other names) then this can be used to detect the presence of vehicles that can't be seen by sensors or even the human eye. This can prevent a small number of accidents, and that only if there is massive deployment of such radios. There is an effort to get a requirement that all cars install such radios, a decision is expected in 2013, and the radios will start appearing around 2019 in new cars if it passes.

Summoning

Of course, robocars will have a network with which they can be summoned or hired out, as well as report things to their owners.

Yielding control

Normally a robocar will be autonomous, following the orders of its passengers or owner. In some cases, the passengers or owner might elect to cede control to an external signal. For example, when entering large parking lot, the robocar will probably let the lot decide where it is to park, and how to get there. The human occupants will probably have left and just told the car to obey the parking lot until later.

Convoys will also invovle some ceding of control.

Parking Data

Many types of communication will be useful for parking. Robocars wishing to wait will probably query on the internet to a "spot market" in parking to bid for the cheapest available parking near to them. (Of course in many cases it will be calculated that free parking is available nearby and the robocar will go there.)

Parking lots might start offering special discount robocar parking at rates far below rates for HDVs. In particular, the lot could offer parking under these rules:

  • Robocars must head to the designated zones in the lot which are more remote and not popular with human drivers. For example the outside edges or top floors of lots.
  • Once there, with confirmation the area is all robocars, the robocar should park valet style, tightly packed with the other robocars.
  • When any robocar inside wants to get out, it can signal in various ways (over data network or WAN, with lights or by just nudging forward) and other vehicles will all pull out in tandem to let that vehicle out, and then go back to fill the empty space. Cars with longer planned waits should move to the back.
  • If the parking lot requests it, the robocars will leave even before their time, or pay a higher price.

This latter one allows the lot to sell space to robocars fairly cheap. While the lot might be "full," the lot's computer can, when a new full-price patron arrives, simply tell the robocars to leave. They will have to find parking somewhere further away. The new patron is able to then take a spot vacated by a robocar, not even aware it was there. So the lot is never full unless it fills up with full-price patrons, and the robocars never deprive the lot of revenue.

Rescue for vacant vehicles and delivery robots

At the time when vehicles without competent occupants need to travel the road, they may encounter situations where they need the advice of a human to decide how to proceed. This might also occur if the occupant of a car becomes unconsicous or incapacitated due to health reasons or a traffic accident (which may well have been caused by another driver.)

Confusing situations might include a road blocked by an accident or unknown construction. They could include a construction worker or police officer ordering vehicles to do unexpected things. They might invovle disasters such as floods or earthquakes.

At such times, the vehicle will need to be able to get to a safe state on its own, but after doing so, it would like to quickly summon the aid of a remote human being who can resolve the situation. This remote operator will need to see both high quality stills, audio and low resolution video of the situation. Due to latency, the remote operator won't drive the vehicle directly but will plot a course for it to take using its own systems. In an emergency the remote operator could drive the vehicle slowly, relying on the vehicle's own obstacle avoidance systems and only applying well considered overrides. For example, a vehicle might find the street blocked by a large cardboard box. The remote operator would see if any people are around to ask for help. If not, it might try another route, or failing that, gently bump the box to see if it is empty, and allow the vehicle to gently push it aside if it is.

This requires a high-availability network which will not exist on every street. As such, empty vehicles may need to avoid certain network dead zones.