Michigan Plans Special Robocar/ADAS Smart Highway On I-94; A Dumb Highway Is Better

A recent announcement from the state of Michigan and the Cavnue consortium (Pronounced “cavenue”) outlines how it has raised $130M and will build a special corridor on I-95 between Detroit and Ann Arbor for “CAVs” or Connected Autonomous Vehicles. The plan is to develop “connected road” features, “adding the roadway into the connected driving experience.” This goes against the development path taken by most, if not all of the leading self-driving car developers, who prefer the decentralized “smart vehicle” approach over the more centralized and infrastructure based “smart road” approach.

Robocar developers have taken the dumb-road approach for a wide variety of reasons. The strongest is the practical one — you can’t change the world and the road, you can only change your vehicle, so you have to drive on the road you’re given. Even the biggest of the developers, like Waymo/Google
GOOG
, don’t have power to adapt the world to their needs. Instead, they took the approach of “virtual infrastructure,” like maps, to let them deal with the roads as they are, and this has worked well — though some players, like Tesla
TSLA
, dislike even having maps and want the vehicle to drive on any road it encounters almost entirely on what it sees, as they imagine a human does.

I have previously written about the lessons of the internet, and how they preach the idea of stupid infrastructure and smart devices, and thus the idea of smart cars on stupid roads. The internet took over the world by following the principle of “innovation at the edges, not in the network” and resulted in more change and innovation than anything else in history. It is very hard for people who come from an infrastructure mindset to accept this principle. If what you know is infrastructure, you think the solution lies in infrastructure.

When it comes to things like roads, the pace of innovation and deployment is even slower than it was for network infrastructure. The internet promoted a “layer” approach that made it possible to have innovation take place at different speeds. While the apps on your phone were innovating like crazy, the physical cables were independently — and vastly more slowly — changing from copper to fiber, from 2G to 5G wireless, from wifi to wifi 6. The lower levels try to be as dumb as they can, and any interaction between the layers, known as a “layer violation” is strongly discouraged and usually gums things up.

Installing physical roads and rails is a very slow process. The planning takes years, the appropriation takes years and the physical construction also takes years. The overall scales are often measured in decades. It can be faster for things that are placed to the side of the roads, but the pace is still in years. That’s a problem when you live in the fast moving world of the computer, as the car now does.

Our intuitions can fool us. One might imagine an application for which smart infrastructure seems like a great solution or even the only solution. The problem is that years later, when it is deployed, it’s very likely to be already obsolete. The smart cars will be annoyed at the construction zones installing something they stopped needing long ago.

The phone is the clearest example of this, as people replace phones every 1-2 years. It’s almost impossible for the phone not to win eventually, even if that seems ridiculous today. Cars last 20 years, but that will change with robotaxis, which will wear out by the mile and drive 3 to 5 times as many miles in a year. They will also be designed for “field” upgrades — many Tesla owners have already had the computer in their cars replaced in Tesla’s quest for self-driving. Robotaxis will be designed to have various important components replaced with the lastest new technologies that weren’t even imagined when the vehicle was first imagined.

In robocars, a “field” upgrade isn’t really a field upgrade. These vehicles can deliver themselves to service depots on demand to get their upgrades, unlike any other hardware product deployed into the field.

We can try to do a bit of that with roads. We can make sure roads have empty conduits buried in them through which future cables can be pulled. We should do this, but it is somewhat of a lost cause and just the hope of a layer violation. Instead, the lesson for infrastructure and road builders is to keep the roads simple — bare pavement — and move as many things to the virtual as possible. Infrastructure needs to stay within its layer. Communications relays can be provided, but this should be done the same way we build mobile data networks — the people innovating the generations of mobile data will work at a far faster pace than anybody working in road infrastructure.

A lesson on this is already visible in the DSRC plan. In 1995, a plan was laid out for a short range radio protocol for cars to talk to one another. It was a modification of wifi protocols. 25 years later, it’s still not in use, and probably never will be, any more than people are using their 25 year old cell phones. People in the mobile data business created a competing protocol based on their work called C-V2X which appears to have “won” the battle with DSRC. Even C-V2X is already trying a layer violation and still is not deployed or used.

In 2010, while working on Google Chauffeur (now known as Waymo) I entered the world of DSRC and V2X (vehicle to vehicles/infrastructure/etc.) direct communications. It turned out that for the Google car team, there was nothing there of use, and there was no likely to be. Almost all the leading self-driving car teams — the ones not embedded in car companies — still have no plans to make use of V2X communication or “smart road” technologies. At most, they say they might use them if they show up, but they will make no plans to depend on them, and base none of their plans on them showing up. This is true even though two teams — Argo and May Mobility — are partners with Cavnue on its project. For them, it’s an experimental project, not an important pillar of development.

One team, Baidu
BIDU
, has a commitment to V2X. They have even done experiments of having cars without sensors self-drive, just relying on roadside sensors. That’s doable — there are even advantages to getting views from remote locations in your sensing — but makes a car that can only operate on such a special road, and requires trusting the road and communications of it with your life, which most players do not want to do.

Baidu is pursuing this because while they believe they can make a car with no V2X be safer than a human driver, they think V2X will help them go the rest of the way to near-zero incidents. That had better be a small distance since you need to be very safe on all the roads, not just the roads with V2X

May Mobility thinks it will be interesting for cars to tell traffic lights they are approaching, so the signals can change without needing the car to drive over a sensor to be detected. Argo says that they don’t need V2X for safety but “are interested in exploring how autonomous vehicles can help V2X technology improve traffic flow even further, and conversely, whether our own mapping and predictive capabilities can be enhanced by integration with smart infrastructure.”

Today, cars already communicate and cooperate, even with human drivers, through tools like Waze, where cars report their movements and humans report things observed on the road. This is a “dumb infrastructure” approach where the smarts are in the phone and the driver/passenger, and it already is out and works well.

This conflict is also the conflict between centralized and decentralized approaches. Centralized plans, like Baidu’s “Apollo Air” road can make sense, and even appear cheaper and superior on the day you design them, but they only allow driving on that road, and no individual car team can innovate on their sensors because they depend on getting the road authority to implement their innovation. The decentralized plan, with everything on the vehicle, allows competition and innovation in away that is always the way to bet.

The Cavnue road

A depiction of Cavnue’s vision can be found on their web site, namely a dedicated lane for connected and autonomous vehicles. While dedicated lanes are a poor approach, Cavnue’s design at least has the lane shared among all types of vehicles, as long as they have sufficient technology. Previous efforts for transit dedicated right-of-way have been very wasteful, as transit vehicles don’t typically appear at rates better than one/minute, while ordinary traffic lanes run at 30 vehicles/minute. It’s not unknown to have RoWs that see only one vehicle every 5 to 10 minutes. Train lines (in tunnels or on the surface) usually do at best one vehicle every 3 minutes, but more commonly have headways of 5, 10 or even 30 minutes. They make up for that by using very large vehicles but still waste most of the capacity of their RoW. Train tracks can only carry trains, while pavement lanes like Canvue’s can carry any kind of vehicle (including, importantly, vehicles not yet invented) but they may not be suitable for pedestrians or cyclists.

This depicted vision is beyond the I-94 corridor plan that was announced, which only involves a special managed lane which is open to all cars, including non-connected ones, according to Cavnue. Indeed, it’s initial focus will be more on the ADA
ADA
S-Pilot vehicles coming on the market now, and potentially standby driver (mistakenly called “level 3” systems) as they arise. They also hope to provide services to truckers, though again, it’s not clear why one would want any infrastructure in the road, rather than in vehicles to get them the data they need.

In the more forward thinking image above, we see a van that has stopped to deploy a ramp and board a passenger. This vehicle is blocking the lane, stopping the bus and all other vehicles behind it. While a wheelchair passenger needs extra boarding time, this is not a good plan even for faster boardings. City buses that use ordinary lanes tend to pull out of traffic for boarding, and of course private cars do this as well — even if Ubers and Cruise vehicles are known to cheat on that. Offline stopping, which allows traffic to continue when vehicles stop to exchange passengers, is a massively useful feature, but it is difficult to do with central lanes where you need to suddenly make stopping lanes as well as pedestrian platforms. This is far easier on the sides of the road (which is why bus stops usually go there) where you take space away from parking, sidewalk dining or even buildings if designing from scratch. The problem there, though is that regular traffic has to cross the dedicated lane to enter/leave the road.

Robocar developers have shied away from dedicated lanes and special infrastructure after a brief flirtation in 1990s experiments. Generally, you either need the dedicated lane or you don’t. If you don’t, there is not much incentive to pay the cost of making it. If you need it, you have a vehicle that can only go in places you have built new infrastructure, which is very much not what robocar developers want to build. As soon as you expect safety from the dedicated lane, this implies you are less safe outside of it, which is a dangerous approach. You want to drive most places and you need to reach sufficient safety in most places, not just places where you have special infrastructure.

This leaves the dedicated lane as an expensive path to modest benefit, which is never a great proposition, even if it didn’t take decades to build and become obsolete before it is finished.

The value of direct communications between vehicles and other vehicles and infrastructure is greatly overstated, and is arguably negative due to computer security reasons. Almost all applications are better served using “vehicle to HQ (Cloud)” with the HQ servers arranging any cooperation between vehicles. Thanks to today’s 5G, latency on communication to and from the cloud can be under 10 milliseconds, and works even when there is not a line-of-sight path between vehicles. While V2HQ is arguably centralized when compared with direct communication, this is one of the few cases where centralization wins because it solves issues around trust, interoperability, innovation and as noted, non-line-of-sight. Innovation in direct communications requires both endpoints to change, while in V2HQ, only one company has to update.

Virtual dedicated lanes

While people from the world of infrastructure think of lanes as physical things, in the software world they can be virtual things. The good news is we already achieved the “connected car” many years ago, by virtue of the fact that almost every car on the road has a smartphone in it, and a large fraction of them have some sort of navigation app running while they drive. Making use of the existing, constantly improving “infrastructure” found in the mobile data networks and smartphones, combined with in-car computers that receive regular software updates, provides a great deal of capability at no cost, and it also keeps getting better on an exponential path for free. No custom approach can beat it for more than a very short time.

It is possible for cities to manage their roads using the virtual layer without creating new physical infrastructure, with no costs other than software and some occasional random enforcement cordons. You mark lanes as managed, and to drive in them one needs a vehicle or smartphone app which is compatible with the system. (Popular apps like Waze, Apple Maps etc. would simply become compatible to serve their users.) Users of the virtually managed lanes would obey their app — as they already largely do — and those who attempt to use the lanes without doing so would be caught and ticketed by occasional enforcement sensors. Today’s managed (HOT
HOT
/carpool) lanes almost do this, but they install surprisingly expensive infrastructure to talk to transponders in cars because they were designed in the pre-smartphone era. As always, any design that isn’t in smartphones or downloadable software becomes obsolete quickly, no matter how much sense it made at the time.

Read/leave comments here