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.
