Wednesday, March 23, 2016

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


Henry said...

Thanks for this really nice and informative article,
expansion joints

James Joyce said...

So this so the posts on his blog seem to have died down. Would it be possible to generate public interest by building a scale model, or even a full sized cab in cheaper materials (I.e plastic in a large 3D printer)? This cab would not be durable, but would show people how things could work on a 50m test track.

Dan said...

Hi James, thanks for your comment.
Unfortunately I have been way to busy of late to give much thought to PRT. I had hoped to make such a model some time back but I had to put that on hold. I have two remaining elderly relatives who I just moved into a downsized place, which took almost 400 hrs incl. selling the house, estate sales, movers, junk guys, charities and so forth... All while I am trying to build a home 2500 miles away!
The problem is not so much the cab, which could certainly be printed, but the mechanics of the thing. In order to initiate a climb the front and back wheels need to have precise, but differing rotational speeds. This is more like controlling a CNC machine than an ordinary vehicle. Just hanging a motorized model from a track wouldn't be much better than, for example, the Youtube simulations offered by Metrino.
Meanwhile self-driving cars and Uber are changing the whole PRT proposition to one of simply providing the best alternative to being stuck on pavement. Luckily this doesn't take quite as much imagination as the old days. I am increasingly confident that PRT is inevitable, with or without this blog. I'll continue to post when I can!

James Joyce said...

Does this mean that the bogie is going to be expensive to make and perhaps delicate.

James Joyce said...

How much would it cost to build a 'baby bear' sized bogie? Could we get an Indiegogo fundraiser going to achieve this?

Dan said...

Dan the Blogger returns from the wild forest!
Sorry for the lengthy delay, James. I am back in the land of internet for at least a week, though, depending on what a doctor says. One of those elderly ladies has a lump that probably needs removing.

What you ask about is a fairly complicated issue whose answer is, perhaps, worthy of a separate post, and it is certainly about time for one of those! Let me start on it a while in the waiting room, and I'll get back to you.

cmfseattle said...

I hear you on the aging relatives thing, Dan; my GF is helping her mother and grandmother with a garage sale (slowly emptying 2 storage units, year by year). We've been thinking smaller and simpler (not quite a tiny house but 750sqft seems manageable).

Meanwhile, if 3D printing can allow us to make much of what we need, travel may become more of a pastime than a daily routine....

Do us a favor, please: sit down with Bill Nye and discuss PRT!
Bill Nye: The City of the Future

Dan said...

James – Sorry, I’m still working on that post. I ended up getting mired in researching new trends in motor control. What is needed is some sort of affordable hack that allows FOC controlled small vehicle motors to behave like servos by taking real-time instructions. Right now they simply expect a “more” or a “less” input signal from an accelerator pedal or twist-grip, so they can set their own speed-controlling frequency accordingly. The hack would to let the motor accept streaming frequencies from a computer instead. For PRT this would create highly predictable timelines and many other benefits. This is not a new idea for industrial automation, just for anything commoditized or optimized for transportation.
Making a demo Baby Bear (or any other size) is really about the demonstration itself. Will it climb? Merge? Park? Maintain headway? How many vehicles will that take? Does it use a real OS or is it that simulated, say, by remote control? As I have illustrated, the mechanical part is very simple. I think I figured once that Mama Bear track would be about 100 lbs. per ft. so at, say, $3 per lb., constructed, that isn’t exactly astronomical. But where do you put it? The motors (4) for a real demo Baby Bear would probably run under $400 each, with controllers being about the same. For a simulated (RC) version, a single motor would do. Obviously cabin quality reflects the resources that go into it. Finally, about Indigogo or Kickstarter campaigns – It is imperative to have a solid plan with limited, achievable goals, expressed concisely. Even explaining what PRT is to potential contributors is a huge challenge.

Dan said...

Cmf – great to hear from you… it’s been a while! Thanks for posting the link. At least there is a tiny bit of “food for thought” between my infrequent posts! 750 sq. ft.? More power to you! Personally, I started only a bit higher, but I as I started fitting in furniture, appliances, etc. the design just kept growing. It’s hard to fit the first floor essentials in under 600, and then adding a second floor is really cheap, especially if you’ve already done a well, septic, foundation and so on. Also, there is the resale/asset-diversification aspect. A younger me would probably just have gone geodesic, but the older me worries, “Can I borrow against it, if need be?” So now it’s a too-big 1250, but every room is just right – Plus I get to have a good sized “clean-shop” (away from the sawdust, welding, etc.) for tinkering through the long New England winters! Unfortunately I have spent an enormous amount of time (away from this blog) creating a Sketchup model of it, explodable to separate the floors, siding, framing, plumbing, roofing, ductwork, foundation and so forth, right down to individual studs, so I can price it all, iron out all of the procedures, even precut everything. (I should probably market the model) If I ever can break free of my step mom and her sister, I’m about ready to stake out the site, buy a used backhoe and start digging!

For PRT, in the meantime, there are a lot of useful technologies and symbiotic business opportunities that are just around the corner that may profoundly affect the system design, especially something along the lines of automated short-distance (i.e. slow and safe) cabs or buses that can feed the stations. I will attempt to explore this further in that upcoming post I mentioned.

James Joyce said...

My original suggestion was why not just build a mock up unit. Since then I have seen that MisterPRT actually did this in Poland, and the results were pretty underwhelming:

It does give you an idea of what the cab looks like, but unless you can see the system actually moving people around a track and stations... it is kind of hard to get your head around it ever being a serious transport option. So now I understand why Dan and others think and actual proper demo is so important.

Daniel Cismas said...

As Einstein suggested, in order to solve a problem we have to leave the framework within which we created the problem, we have to study our new system, its conditions, and based on our examinations we have to create a totally new system.

Any PRT supporter is asking the following question over and over: what PRT is missing from getting its acceptance and mass deployment? Truth is, this is a million dollar question.

However, there is a way to figure this out. The answer is not coming from a think tank who’s predicting the future, is coming - guess what - from the future itself 

Bear with me. Let’s imagine we are living in the future, more precisely: year 2116: we wake up in a single detached house… (yes, in 2116 the Earth would still be large enough for single detached homes)
…We look through the window and we see that we are located on a palm-like town like the Dubai’s Palm Islands. We have 2 kids… (just hypothetically): the smallest is a middle school student: we put him on a PRT car which gets programmed wirelessly and automatically through his iPhone77 to drive him to the school located at the “trunk” of the “palm”. His big brother just started university and he will take the PRT to the base of the palm to get the subway to a nearby palm-like town and then he will continue his ride through another PRT network to his university of choice. Don’t worry: it’s a 30 minute ride and he’s not driving all this time but watching courses.

As soon as we get rid of the kids we take a closer look at the PRT (no, don’t ask where is the wife, she has already got embarked on the PRT just before the kids got their breakfast). Like spies from a movie, we take impetuously pictures of the PRT with our iPhone so we can sell the ideas to the guys from the past: the PRT has its network embedded underneath the road (yes, in 2116 there will still be roads but they will be just for emergency vehicles or family vehicles, not for weekday personal transportation).

Because the palm architecture with waterbeds, the roads are elevated and the PRT tracks are sideways, underneath the road/sidewalks. The access to the PRT is from every house, from the basement of the house, so nobody will do shovelling in the winter. Walking or jogging through the PRT path is a four-season activity with nice views of the water and beach. These windows of the PRT tunnels are in-between the houses to make sure nobody gets phobia if inside the PRT path would be too dark.

The PRT vehicle is a 1.5-occupancy vehicle running on elevated tracks. In the residential area is buried under the sidewalks but in the “downtown” is either buried or elevated on posts. The vehicle itself is a 2000 mpg electric vehicle running on V2G technology which can be also driven manually in case of emergency. The motor and switching technology is based on openprtspecs… but let’s stop here because we have already found the answer we were looking for:
…what PRT is missing is (moment of suspense like at the best talent contest shows): THE INFRASTRUCTURE, a PRT network built on a totally NEW city INFRASTRUCTURE.

How can this be possible to build a new infrastructure? Yes, it is possible. Who is living today in a 100-year house? Not so many. Maybe 10%. Who will live in 2116 in a 100-year house? Not so many. The new infrastructure would be possible to built it if we start building it now. We have to start a totally new system, an out-of-box system. Who’ll have the honour and courage to start it?

Hello? Hello? Is anybody out there?