Brad Templeton Home


Robocars
Main Page


Brad Ideas
(My Blog)


The Case

Roadmap

Roadblocks

Car Design

Problems

Privacy

Stories

Deliverbots

Whistlecars

End of Transit

Objections

Geeks

Parking

PRT

Notes

Motornet

Glossary

Robocar Blog

The Motornet -- Robocars and data

The Motornet -- Robocars and data

While robocars must be able to operate autonomously, relying on no more than GPS from the outside world, they will be better if they can be part of a data network.

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 services and from car to car.

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.

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

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.

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.

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.