Greetings, Updates and Plans from Dan the Blogger

As some long time readers or diggers into old posts may know, I have, for quite a while now, been dealing with some issues that have been competing for the attention previously devoted to this blog. In particular, I wrote several years ago that I was caring for four elderly family members. That number is down to two, and I have finally simplified their living arrangements (sold two houses) to where they can still manage to live semi-independently. This has given me a large part of this last summer and fall to catch up on pursuing my long-term goal of developing my humble homestead on some land I own in New Hampshire. This is a monumental and urgent task for a man of my age, (62) especially since some amount of sweat equity therein has always been an important (and long postponed) component of my retirement planning.  At 85 and 87, my remaining relatives will surely and increasingly pull me away from these goals again in the near future, and so I must work around the clock while I can. My current lodging is completely off-the-grid, in a remote streamside cabin (not pictured) which I have managed to make quite comfortable except for the winter months, when provisions would have to be brought in by snowmobile. I love this Thoreau-style life, but there is no internet and even phone signals are very spotty. My projects there are varied and challenging, both mentally and physically, and I have found it difficult to switch my focus away from matters at hand even when I get to more connected places, such as the town library. (the nearest McDonalds is 25 miles away!) I do fly back to Houston frequently to help out and try to get caught up when in the city, although I am busy here as well. So I guess what I am saying is please bear with me, and don’t hesitate to comment, even if I take a very long time to reply! BTW, this problem is years old. Way back in post 106  you can see the experimental bent-roof structure pictured above when it was just a skeleton of 1x3 boards, and note that even back then I was making excuses for being out so of touch!

Recent long, cold nights, however, have afforded some time to sit by my wood stove and do some design work on the “Mama Bear” bogie design. What I am working on, specifically, is a design that is fully buildable for prototype and testing purposes. To this end I am refining the design from a standpoint of what is most practical in terms of milling, welding and assembly procedures. 

Pictured above is an exploded view of a SMART (Suspended Multi-axis Automated Rail Transport) PRT bogie of the mid-size variety. (Mama Bear) If you are completely new to the site and the concept, this is the motorized part of a hanging Personal Rapid Transit vehicle that rides within the track, so that the carriage may hang from it. This design features an unmatched combination of tighter turning, steeper climbing, faster speeds, and other many other attributes that long-time readers will recognize from earlier iterations. If it seems like there are an awful lot of parts, I would point out that many are identical, may be machined with the same set-up, can be ordered pre-cut to a shape from a steel or aluminum supplier, and so forth. A mass produced equivalent would be quite different, ideally with self-turning wheels (axial flux, hub motor driven) mounted on a stamped metal frame. This design relies on a lot of supplier-cut sheet and plate shapes, with lathe-cut “stand-offs” and lots of threaded rod, nuts and bolts to hold it all together. Below are the assembly stages. Note: I did not include every single nut and bolt, nor is this CAD file scaled to the precision customary for shop drawings. Some plate thicknesses might vary, depending on choosing aluminum or steel. If plates appear thick, they are probably aluminum.

The design starts with 1.25” square and rectangular tubing, flame-cut 1/8^” sheet steel and some round tube and bar, all welded.

The stand-offs are pipe which is filled with foam that is drilled to help center the pieces during assembly. 

The track switching components are assembled separately. These utilize pre-milled (for exact thickness) aluminum plate material, which is an off-the-shelf item. Aluminum can “smear” into ripples instead of wearing smoothly, so for more than a few thousand switching cycles nylon or bronze bearing surfaces should be inset for those dark blue (steel) switcher arms.

This assembled unit shows how both sets of switcher arms are sandwiched between milled aluminum plates, and how this assembly must be stout enough to never become bent to where the arms might become bound. Note that each arm’s pivot point is across the unit while it is raised and lowered by a cam near its midpoint. This geometry transfers load directly to the frame without stressing or inducing rotation to the camshaft once set into the up or down position.  

Above we see how the nearly completed switcher assembly is inserted and bolted into the frame, and additional motor mounting parts (plates and stand-offs) are added.

Finally, standard trailer wheel spindles are added as are the guide wheels and axles.

There. Now you just need 4 of Golden Motor’s 5 kw BLDC motors, ($376. Each) for a total of 26 HP, some timing belts and pulleys, 4 heavy-duty trailer tires and hubs and you are practically “good to go.” 

Lastly, sprockets are attached to the belt pulleys, (so they rotate as one) and a free spinning wheel tops off each wheel axle assembly. The sprockets act as cogs for climbing a “ladder” of dowl pins or even a mounted chain. The free-spinning wheels are used to press the sprocket into engagement, so it cannot skip. When the sprockets are engaged the tires free-spin. In this mode the bogie is extremely manuverable and can even climb straight up. That is it; except, perhaps, for adding some safety sensors to keep an eye on things out in the field, wire harnesses and other small stuff.

And one last thing – ideally the bogie should have a controller package that can make the motors behave like servos – that is to be able to numerically select (via a real-time program) the speed and number of revolutions of each motor so that, for example, the outside wheels can rotate proportionally faster than the inside ones while turning, or the front and rear wheels can rotate at different speeds when switching from cruising to climbing mode.  Post 131 explains climbing and 162 discusses using digital rotational control in general. It is, however, possible to use 4 of Golden Motor’s ($585.00 - Ouch!) controllers, unmodified, in a pinch. This is an inelegant control solution because it is inaccurate and overly complex, but it would do for now… I will discuss this option in a future post.

So, do we have any volunteers to go out and build this puppy? Oh yeah… Track will be (I would guess) about $200.00 per ft. erected… What’s that, you say? Too expensive?...  Baby bear?... Well, that is still on the drawing board.

Anyway, have a great time these holidays! Best Wishes from DTB! (Dan the Blogger)

PRT is Dead. Long live PRT!

With the various advances that have come to transportation lately, PRT has lost its monopoly on many of the virtues that once made it unique. It is, perhaps, natural to wonder if PRT’s time has come and gone. Once upon a time only PRT could manage its traffic because the vehicles were centrally controlled. Now, with traffic apps, roadside electric billboard alerts, etc., drivers by the thousands can increasingly be alerted of upcoming congestion and change their routes accordingly. In the very near future cars will be “talking” to signs, traffic lights, the cloud and to each other. In the past the whole idea of a driverless vehicle was unthinkable without a dedicated track or guideway, simply for safety reasons. That is clearly changing. Once, PRT alone made electric vehicles practical, because an electrified rail eliminated the need for the heavy lead-acid batteries that made electric cars slow and short-range. Another advantage gone. Does all of this mean PRT is dead? Can PRT’s essential advantages can be had in different ways? Let’s dig a little deeper.

One must first realize that progress has not been confined to cars alone. PRT’s centralized control scheme was a liability as well as an asset – A single glitch could strand everybody. Autonomous driving benefits PRT right along with automobiles. This is especially important in that it facilitates variable speeds which, in turn, enable tighter turns and faster straightaways, making PRT much more versatile. Those sweeping, graceful turns once depicted in PRT promo material were far from an asset – who would give up their valuable corner property without a fight? Advances in batteries benefit PRT as well. Now there are many “third rail” options including none at all, being a discontinuous, a charge-on-the-go system, supplementing solar collectors, etc. Wireless connectivity, combined with more “intelligent” PRT control makes for a very robust and fault-tolerant system. In other words, any PRT system that is devised today can be far superior to past designs by almost every metric.

Although many designs still represent a basically workable, even elegant transit alternative, enough has changed in the technological landscape to justify a re-think of many key aspects of the whole proposition. It’s not just self-driving technology and batteries. It’s smart phones, the cloud, how things are prototyped and manufactured. The world itself has changed, including people’s expectations and behavior. About the only thing that hasn’t changed is the need. The fundamental problem with “surface” transportation is that paths inherently cross, leaving no alternative but for someone to stop and wait, whether you’re a pedestrian, train, on bicycle or on horseback. The large size and weight of commercial vehicles on our current roadways curtails extensive use of curative overpasses and even when elevation is absolutely necessary, the high inertia of these vehicles is such that massive cloverleaf designs must be created or they would simply skid off the road at reasonable speeds. This, with the shrinking amount of available ground-level space, ensures troublesome bottlenecks. Self-driving cars, alone, can never solve this dilemma. Private passenger vehicles do not require anything close to such a heavy infrastructure, yet they comprise the lion’s share of vehicular traffic. There is, therefore, great advantage to be gained by giving such smaller vehicles a modern, non-stop infrastructure all their own, which can also eliminate the need for plowing, policing, and save lives. So if a smaller gauge, elevated (and presumably automated) system for moving people is still needed what, specifically, has changed?

PRT has always been a mix of utopian dream and practicality. You walk a short distance to a station, there are private vehicles waiting, and you get whisked away, non-stop, to your destination. But wait: A “short distance?” How short? “Private vehicles waiting?” Every time? Isn’t that kind of wasteful, having that much precious investment sitting idle? What about vehicle capacity? Should all vehicles that will usually carry one be built for four, “just in case?” And what about “non-stop?” If a vehicle can pick up a passenger or two without adding substantially to the travel time, isn’t it kind of inefficient not to? Or what about “To your destination?” How close are we really talking about? Above all, is this practical as a business?

Unfortunately, the whole notion of PRT becomes very iffy when many important stations have yet to be added, because it is that much less likely that there will be potential passengers, at any given time, within walking distance of a given station. Trying to start a PRT system without a multitude of destinations is like opening a grocery store that only stocks pet food, diapers and milk and expecting it to grow from there. No selection, no customers. I suspect we all agree, however, that PRT would prosper fabulously were it extensively built-out to the point of having stations on every corner. That would be a “Walmart” of destination choices! But how do we realistically get there in stages? This has always been the fly in the ointment and is where the latest technological trends may just come to the rescue, even if the remedies aren’t exactly what a PRT purist would like. Let’s start with the first part of the supposition above, walking that “short distance” to the station.

It is no secret that Uber is working on self-driving cars. Yet as the recent fatal crash of a Tesla on autopilot points out, there will be a lot of bumps along the way, especially in terms of liability and ethics when it comes to driverless cars going lethal speeds.  For robotaxis, it is more likely that completely driverless vehicles will cut their teeth on the slower, short-haul market for quite some time before attempting to navigate amongst drivers who themselves are often driving unsafely, sometimes on foggy, icy or flooded streets. A preferable start for an Uber would be, therefore, somewhere that would leverage the convenience of a ride hailing app with a greater value than a short, slower ride would ordinarily suggest. Such situations already exist in cities with long established and heavily used transit systems, where some neighborhoods are just out of comfortable walking distance to the nearest station. Assigning a few robotaxis to each station would extend a transit system’s reach. Better yet, however, would be to service a PRT station, because that would mean that an entire trip could be arranged in a single step. In other words, a robotaxi/PRT/robotaxi trip could be arranged by phone, giving the full door-to-door service of a traditional taxi but with the non-stop, flyover capability of PRT, hopefully for the lion’s share of the trip. This would require far fewer PRT stations than the traditional grid approach, with the PRT simply acting as a wormhole from one part of the city to another. Such a partnership is as good for Uber as it is for PRT.

Then there is the matter of sharing the ride via Group Rapid Transit, or GRT.  Automated self-driving technologies enable a mix of vehicles. There can be 2 seaters, 4 or 6-10 seaters or cargo vehicles all sharing the same track. A cloud-based phone app could do more than simply synchronize the ground transportation for a PRT passenger. It could also pair passengers with vehicles “on the fly” to create the most efficient shared routing. Since nascent networks will necessarily have only a few major destinations to start, it is vital to implement a business model that can survive this stage. Such stripped-down networks tend to lend themselves more to GRT than PRT, since it makes little sense to send large numbers of people to the same destination in separate vehicles. Readers of this blog will note that the concept of a multiple-tier, yet compatible track system (Baby, Mama and Papa bear track) has been proposed herein, and GRT track is of the “Papa Bear” variety, which supports high speeds and heavier weights, but not steep slopes or tight turns that would be best for confined, densely developed areas. Although not as flexible as a smaller track, it is assumed that many important destinations are accessible by major highways anyway, and such track would generally follow these or other uncontested routes. In a more mature system these would form an arterial backbone for smaller, yet compatible PRT track and station designs that are sized to more comprehensively serve neighborhoods where space and flexibility is at a premium.

This is where cloud-based “intelligent” routing and scheduling really makes a difference. Consider the compromise reflected in all forms of shared, scheduled transit: Running infrequently makes for full vehicles but discourages use of the system while running frequently promotes system use but it may operate at a loss because the vehicles are nearly empty. With app/cloud-based systems, however, the need can be monitored in real time and responded to accordingly. This strongly implies an approach that incorporates multiple vehicle sizes, something that would make sense anyway, from airplanes to buses, if only such vehicles could be staged “at the ready,” and there was a means to accurately predict occupancy. A paradigm of distributed, algorithmically anticipated, haled (rather than scheduled) vehicles makes this possible for the first time, essentially turning everything we thought we knew about mass transit on its head.

In a fully automated, cloud-based deployment scheme, artificial intelligence would be used in real time to choose both vehicle type and destination to best eliminate waiting and minimize travel time while maximizing throughput. Unlike a city bus, which often has a sign that shows route/destination information, A GRT vehicle’s sign (and destination) might change as it pulls into a station based on the more democratic principle of majority rule.  Perhaps such a system could even arrange a passenger transfer to another vehicle, maybe even calling that passenger by name and giving instructions. For that matter the vehicle would also “know” if a passenger is making a mistake and getting off at the wrong station. The system could even respond to passenger preferences and histories, such as not pairing an unaccompanied woman or minor alone with a stranger, or only pairing students of a local college with other students. Hmm… This might give new meaning to the term “speed dating”! Seriously though, bad experiences can be reported within a passenger app, and with cameras becoming ever cheaper and clearer, this all bodes well for safety and passenger satisfaction even without the watchful eye of a driver.  

All of the above stands in stark contrast to the “everything or nothing” proposition of traditional PRT, and we all know which of those two cases has come true to date. Is PRT “dead?” Perhaps, in a way. If this is so than it is death by a thousand cuts… a business model that is not quite compelling because dozens of very minor (though often solvable) factors add up to a no-go, especially in the early stages when there are too few stations to create the “network effect.”  Still, besides creating a dizzying array of choices, our current technological prowess has made the path towards those original goals more likely and achievable, not less. At present it seems that GRT (rather than PRT) is probably the way to start because the drawbacks of group travel have been largely eliminated and GRT offers a better business model for the fewer stations that are an essential stage in building out a network. GRT, like PRT, with a robotaxi at each end, offers true door-to-door service, ideally with near zero wait time. It is also notable that even with a GRT system there would be naturally be a need for smaller vehicles. Late at night, for example, it would make little sense to use vehicles that are sized for rush hour. This bodes well for the prospect of arterial track sections that are eventually populated by both PRT and GRT vehicles. 

Any ground-based leg of the trip, of course, will still experience traffic delays. That, for PRT (and elevated transport in general) is a good thing, as it will encourage expanding the aerial network into more and more areas, and encourage players like Uber, Google, or even Ford to enter the elevated transit business. The contrast between crawling along on the ground and flying over the city will be like night and day, and it is hard to imagine that they will not see the light. It is also noteworthy that future robotaxi logs would give solid statistical evidence as to where the elevated track should expand to next, by predicting how such a “spur” would perform monetarily, removing the financial risk of such an expansion.

PRT does seem dead or dying as a singular, all-inclusive product/service, in that the old model is  analogous to treating cars and roads as a single thing, when they are many: There are many types of roads and many types of vehicles that drive on those roads and that’s a Darwinian strength. The specific vehicle/track/operational methodologies of many past PRT designs were often tightly integrated to compensate for technological limitations of the day and so now require total revision in the face of the game changing advent of autonomous vehicular control. In this new world the track itself is the most important part to get right, because it is, ultimately, the limiting factor. Track that is too expensive, uses too much real estate, requires stations that are too expensive, is noisy, is affected by weather, cannot easily be modified for various loads or spans, cannot support high speeds, cannot be quickly and inexpensively  constructed or modified, etc., won’t fulfill its promise, or the promise of anything running on it. Above all it needs to be flexible, and that means being designed for much more than PRT. It seems increasingly likely that vehicles from multiple venders may be the business model that is most likely to flourish in the ecosystem of grade separated, automated transport, so we have to keep the track simple.

The roll of the “control system” has clearly changed. There has always been some degree of autonomy in PRT, say to slam on the brakes to avert a collision, for example. With newfound autonomous capabilities however, centralized “control” becomes, more and more, merely a role of scheduling and traffic optimization. Under such a scenario, the central computer basically makes suggestions in real-time that are normally followed, so it is essentially the same as central control. The difference is that the vehicles are quite capable of working independently, just at a more cautious pace. This may seem like splitting hairs, but it is an important distinction from a business perspective, because it redefines what role a PRT company would have in continuing operations by reducing an important role to a discreet, probably largely cloud based, software layer.

  

What if, we might dream, a city were to say to a Google, Tesla, Amazon or an Uber, “If we provide this track and these stations will you design and build robotic vehicles for it? Or perhaps provide the central traffic optimization (control) layer? While it might seem, at first glance, that such companies would have little to gain, it is actually a pretty interesting sandbox, as described in the previous post, and the cost of prototyping and mass producing the actual machinery is falling every day. There has always been a natural dichotomy in PRT between that which is naturally a city’s business and what a PRT company can be expected to produce and perform. Autonomous vehicles enable a “dumb” track that requires less oversight, is less likely to become obsolete, is less tied to a specific vehicle manufacturer, and is therefore generally less burdensome and risky to a city. This, in turn, relieves vehicle manufacturers from a business they want no part of, that being planners and builders of urban infrastructure. The PRT provider really becomes more of a go-between, a builder of partnerships. Everybody’s happy!

The PRT of old seems pretty much dead... if it was ever really alive to start with. Loosely defined, however, where we are simply referring to smaller, haled robotic vehicles operating on a network of lightweight, elevated tracks... well that, my friends, is alive and well. Long live PRT!

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?”