At the recent AUVSI/TRB symposium, a popular research topic was platooning for robocars and trucks. Platooning is perhaps the oldest practical proposal when it comes to car automation because you can have the lead vehicle driven by a human, even a specially trained one, and thus resolve all the problems that come from road situations too complex for software to easily handle.

Early experiments indicated fuel savings, though relatively modest ones. At practical distances, you can see about 10% saving for following vehicles and 5% for the lead vehicle. Unfortunately, a few big negatives showed up. It's hard to arrange platoons, errors can become catastrophic multi-car pile-ups, other drivers keep inserting themselves into the gap unless it's dangerously small, and the surprising deal-breaker that comes from the stone chips which are thrown up by lead vehicles which destroy the finish -- and in some cases the radiator or windshield -- of following cars. They can also create a congestion problem and highway exit problem the way existing convoys of trucks sometimes do that.

One local company named Peloton is making progress with a very simple platooning problem. They platoon two (and only two) trucks on rural highways. The trucks find one another over the regular data networks, and when they get close they establish a local radio connection (using the DSRC protocol that many mistakenly hope will be the standard for vehicle to vehicle communications.) Both drivers keep driving, but the rear driver goes feet-off-the-pedals like a cruise control. The system keeps the vehicles a fixed distance to save fuel. The trucks don't mind the stone chips too much. Some day, the rear driver might be allowed to go in the back and sleep, which would allow cargo to move 22 hours/day at a lower cost, probably similar to the cost of today's team driving (about 50 cents/mile) but with two loads instead of one.

Trucks are an easy win, but I also saw a lot of proposals for car platoons. Car platoons are meant to save fuel, but also to increase road capacity. But after looking at all the research a stronger realization came to me. If you have robocars, why would you platoon when you can carpool?. To carpool, you need to find two cars who are going to share a long segment of trip together. Once you have found that, however, you get far more savings in fuel and road usage if the cars can quickly pause together and the passengers from one transfer into the other. Then the empty car can go and move other commuters. This presumes, of course, that the cars are like almost all cars out there today, with many empty seats. When the groups of passengers come to where their path diverts, the vehicle would need to stop at a transfer point and some passengers would move into waiting robotaxis to take them the rest of the way.

All of this is not as convenient as platooning, which in theory can happen without slowing down and finding a transfer point. This is one reason that the carpool transfer stations I wrote about last month could be a very useful thing. Such stations would add only 1-2 minutes of delay, and that's well worth it if you consider that compared to platooning, this carpooling means a vastly greater fuel saving (almost 50%) and a much greater increase in road capacity, with none of the other downsides of platooning.

If you're thinking ahead, however, you will connect this idea to my proposed plan for the future of group transit. The real win is to have the computers of the transport service providers notice the common routes of passengers early, before they even get into a vehicle, and thus pool them together with minimal need to stop and switch cars.

A number of folks have imagined designing cars that can physically couple, which would produce very efficient platoons and not add a delay. The problem (aside from the difficulties in doing this safely) is that this requires a physical standard, and physical standards are much harder to get working than software ones. It requires you find a platooning partner who has the same hardware you do, rather than software platooning, which can work with any style of car. Automated matching and carpooling makes no requirements on the individual robocars and their design, which gives it the best path to success.

It is possible (though a bit frightening) to imagine a special bus which could dock to robocars to allow transfer of passengers at speed. Some of you may have seen that a Chinese company has actually built the formerly hypothetical straddling bus (really a train) that has cars drive under it. If you were assured a perfectly smooth road one could imagine a docking extension which could surround a car door of a perfectly synced robocar and allow transfer. I suspect that's all pretty far in the future.

Beyond the carpool

In a robocar world, we should see a move to having vehicles with fewer empty seats. This happens if more people use single person vehicles for their solo trips, and as carpooling and other technologies make sure that the 4 seater vehicles end up with more people. Indeed, if the carpooling works, that happens naturally. At that point one might say, "now's the time to platoon." There is merit to that, but it comes later, rather than sooner. At this later date we can be more comfortable with the safety, and have a greater density of vehicles making it more likely to find others vehicles ready to platoon. Of course, we'll also have more vans and buses on the road who can combine even larger groups, if you find groups with a lot of journey in common. Platooning is practical even for a few miles, while carpooling tends to need a longer amount of shared journey to make it worth the switch.

At that point in the technology, you can do much more serious platoons, with larger groups of cars, and distances which are short enough for even greater benefit, and short enough to strongly discourage people trying to insert themselves in the middle of the platoon.

So platoons will come and give us even more road capacity. Carpooling, though, is already happening, with 50% of Uber requests in San Francisco being done in UberPool mode. It is the more likely early answer.