A Simple Question

I have a simple question for Google, Tesla, Apple, GM, BMW or any of the other makers (or potential makers) or self-driving cars. It goes something like this:

Let’s suppose you put 4 robocars in a parking lot, and they all want to leave at once. Who goes first, and why? Taken a bit farther, if a couple of your competitor’s self-driving cars enter the mix, then what? Can I bully my way out first if I am the only human driver? What if I yell, “My wife’s water just broke!”  What if one is a bus? Do large or full vehicles get priority over a vehicle with a single passenger? Or here’s one for Amazon. What if a bunch of delivery drones arrive back at the warehouse at the same time? What about when multiple robo-forklifts rush pallets to a waiting truck? How is all of this coordinated?

What we are talking about here is something very fundamental, even in nature… When herds navigate a river crossing or when bees enter a hive, there must be a pecking order. Extended to movements en masse, there are behaviors such as flocking, schooling and swarming. This is an essential building block that must be integrated into the programing of any autonomous robot that moves around amongst other mobile devices. It is more complicated than simply allowing the first in line to take the lead. As noted earlier, there are mitigating circumstances than can change the priorities. “First come first serve” won’t work, for example, if the first in line is a nimble little vehicle but the second is very much larger and/or moving faster. These parameters must be mathematically quantified in computer code.

Whenever autonomous vehicles (of any type) approach each other there must be some kind of mutual greeting, and exchange of self-descriptions, and declaration of current and intended movement. In the simplest example, two equal vehicles are traveling in straight lines and those lines cross up ahead. A check of velocities determines that both will arrive at this crossing simultaneously, so one or both must adjust speed accordingly to prevent a collision. This greeting need not be last-minute in either time or space, but rather should occur as far ahead of time as is practical.  After all, if an automated train pulling thousands of tons is one minute away, the other vehicles that will be crossing that track would be well advised to anticipate this arrival! In the automotive realm, convergence of large numbers of cars at a single choke point will form gridlock, so advance warning of this would obviously be advantageous. In other words, what is collision prevention close-up is traffic prevention if done ahead of time. A cloud-based, queryable master timetable can be generated by monitoring such intervehicular communications, so all upcoming interactions on any particular vehicle’s itinerary can be foretold by simple sorting. In other words, every vehicle can know who it will encounter on a journey and when.

Because of the many manufacturers and types of robotic vehicles that might be involved, “interspecies” traffic management will eventually require a holistic approach, and so a number of standards will need to be established. Otherwise muscular Teslas will be bullying Google cars and neither will understand why a bus keeps stopping. Aspects of such protocols will be widely applicable to various forms of human controlled transportation as well, providing an additional layer of safety for road, air, harbor or rail traffic. (Existing standards and practices will have to be folded in.) Drones could simply be “repelled” by air traffic corridors when they are active, road traffic would automatically start pulling over with the approach of an ambulance and so forth. Even inanimate objects could participate.  Perhaps someday stop signs may literally stop you!  

And what, pray tell, does any of this have to do with Personal Rapid Transit? First of all, collision avoidance and traffic control are problems that equally apply to PRT, and no such software for autonomous PRT vehicles currently exists, even though it would have huge advantages, such as eliminating any chance of a systemic failure. The fear of such failure has been one argument against compact track designs that are otherwise cheaper and less visually intrusive, since they cannot double as an emergency walkway.  Autonomously controllable vehicles could reroute, backup, or even push a disabled vehicle, making any such problem much more manageable. In short, a system based on autonomous vehicles has the robustness demanded in today’s world.

Secondly, such software will have to be written anyway, as it is the core of any system that can coordinate self-driving cars or other mobile robotic systems. It is that last assertion that is key: The software will have to be written anyway, because will likely be done before any comparable code is written specifically for PRT. The problem for PRT, besides the wait, is that there is no particular reason to believe that the developers of self-driving cars will tackle this problem as a holistic platform until they are forced to do so. It is much easier to stick with “first come, first served” until forced to do otherwise. Until you ask the parking lot question, the matter appears to be a simple extension of obstacle avoidance – a mere footnote in the code. Someone needs talk to these folks and point out that there probably is a sizable DARPA grant in there for whoever takes this on as an independent field of R&D. It has incredibly important military, as well as civilian, applications. 

The good news for PRT is that it just happens that this platform can, in most cases, be researched more easily with PRT than with cars or other steerable robots. To illustrate this, let’s start with connectivity.

The same year as I started this blog, Kevin Ashton coined the term “internet of things” referring to a world of pervasive internet where everyday devices would communicate with each other, the cloud, the owner, and/or the manufacturer. Such a world is slowly coming to be, from doorbells that ring your phone to, of course, GPS navigation in your car. Yet fast and completely reliable real-time connectivity is still a problem, something that the upcoming 5G cellular standards will try to address. In the meantime, for automakers, this limitation adds to the constraints in developing the kind of vehicular coordination discussed earlier. Between the unpredictable street environment, the lack of connectivity, and the lack of other cars with which to communicate, it is likely that traffic coordination directly between vehicles will become mired in, conflated with, and given a back seat to these other issues. PRT, in contrast, is a perfect testing ground for such coordinated control because it lacks these complications. “Leaky cable” (as proposed by Skyweb Express, Flyways, and others) is a method of extending the range of wireless communications that is basically protocol agnostic; Perforated coaxial cable acts as a track-wide linear antenna for both broadcasting and receiving wireless signals, and inside of a shielded track at a range of mere inches it can provide super-clean transmission of wireless Ethernet, Bluetooth, or experimental protocols designed to exploit or supplement next generation cellular technologies. In other words, Google’s cars might not be able to reliably chat with each other from long range now, but with leaky cable equipped PRT they could simulate that future connectivity in a way that they can’t out on the streets.

To prevent collisions (or to merge PRT vehicles) we need more than a “handshake”. We need to act on real-time velocity and trajectory information. The parking lot example illustrates just how complicated this is. The cars can be initially positioned and aiming anywhere, and their preferred paths can be curved by any amount or into an “S,” for that matter. Meanwhile they can speed up or slow down by any amount, all while trying to maintain a comfortable ride and watch for obstacles. In short, the possible combinations are nearly infinite. Track-based PRT reduces this to absolute bare-bones. Trajectory information is nil (or zero, for straight ahead) because the vehicle is captive on a track, and changeable only to 1. (to switch tracks) This means that while still needing to be written into the program, all of that complex turning radii and angle information is reduced to one single, binary “bit.” - Little more than a place marker -  I told you it was easy!

Velocity information for PRT is also highly reliable in comparison to self-driving cars since, out on the streets, moments of uncertainty rightly cause moments of deceleration which results in unpredictable travel times. In the controllable environment of a track the interactions between vehicles can be programmed to milliseconds even when it will be many minutes before the encounter occurs. This simplifies experimentation with algorithms for shaping traffic of any type including air, harbor, warehouse, rail, etc. One immediate and valuable use of such software is to more accurately simulate proposed highways and modifications to them.

PRT is also the ideal way to experiment with adding “the cloud” into the mix. If two vehicles will cross the same merge point in 5 seconds, that interaction should be transacted locally. If the encounter is 3 minutes away, however, that is something that should probably be cloud-based. The interaction of cloud and local communications and processing resources is hard to study out on public streets, but is essential for making robots behave as a team, not just for transportation but for fields such as space or undersea construction, search and rescue, or for military uses - anywhere where swarms of small robots acting in concert could gainfully replace teams of humans.

Moving from simulations to making occupied vehicles actually cooperate takes testing in the physical world, and this is expensive. For such testing, it is very hard to imagine a mechanical system that is simpler than a PRT bogie which, since it doesn’t have to steer or handle bumps, can be reduced to the absolute minimum of moving parts possible for a self-mobile device. This simplicity and affordability enables experiments that require large numbers of vehicles. For scaled-down, indoor model testing, track could be something as simple as a one piece extrusion. Such experimentation is not frivolous. Consider the problem of sequential merges, for example, such as would happen with multiple on-ramps feeding a single lane. How many vehicles can you add and how fast, when they are all “thinking” for themselves? Can you throw in a simulated emergency vehicle? Mastering this ultra-simplified, track-based environment would be a valuable precursor to doing the same on the open road.

The bottom line is that to get those cars out of the parking lot, you need to write a program, and that program needs structure and a foundation. To go about their business efficiently, self-driving cars, (or other forms of mobile robotics) need to coordinate their movements by communicating and planning ahead. Doing this effectively across a broad range of devices constitutes a huge but necessary challenge, and a chance for interested companies to create standards and otherwise influence a whole new and emerging, yet fundamental platform. To get this right, they will need to develop and test a system whereby autonomous vehicles will resolve conflicting routing intentions in real time and circumvent future conflicts by some method of fair prioritization. Doing this for drones, in full 3D, will be an astronomical challenge, and even coordinating vehicles in open parking lot or warehouse space involves a nearly infinite number of possible paths, not to mention timing. Doing this for rail-based PRT would, perhaps, be the simplest testable starting point, because the vehicles are as elemental is possible, the steering is binary, the rolling surface is smooth and controllable, and the wireless communications are free from interference and distance limitations. A near-perfect laboratory.

For PRT, this presents an interesting business model. What if, for example, a city were to agree to partner with a Google or Apple or Uber (or a consortium) to create such a laboratory in the form of an actual PRT system. In this case the city and its local partners would be primarily responsible for track and stations, which I have demonstrated can be quite minimal. The majority of the system could be developed with funds already earmarked for similar experimentation. This combination also falls neatly into federal funding programs already underway, and we should not underestimate the influence these tech giants have in setting the agenda for such funding. The US Department of Transportation may not be interested in PRT per se, but they are clearly interested in everything that makes PRT tick!   Also, the (PR) optics of the whole program would be great for everyone involved. To these companies (unlike the government) bold is beautiful! Such a scheme squarely addresses PRT’s three greatest problems, those being [1] the “PRT-needs-a-large-network-to-be-profitable” problem, [2] the “government-bias-toward-pavement-based-solutions” funding problem, and [3] the “reluctance-of-cities-to-try-anything-new, especially-with-an untried-startup” problem.

I have one more, simple question for the tech giants, not to mention our respective governments. “Do you want to shape this coming paradigm or do you want to cede this field to someone else?”