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

Modularizing PRT

Let’s Hope, for Santa’s sake, that the nations of the world make 2016 a banner year by actually acting on the agreements reached at the recent international climate summit! PRT is too good of a solution to languish for long in a world that is finally getting serious about carbon reduction!

One problem that is holding up the implementation of PRT, ironically, is the speed of technological progress. In eras past, such big projects could be tackled with the assurance that they would remain cutting-edge for years to come, so any government contributions would remain relevant and financial stakeholders would enjoy a fairly long-term leg up on the competition as well. These days, better techniques, materials and methods come along almost faster than whiteboard ink can dry. In particular, the progress toward electric and self-driving cars, better batteries, robotics, communications and so forth creates the impression that any major innovations in transportation field may well be obsolete or unneeded soon anyway. After all, many of us still have our share of VCR players, film cameras, and cassette tapes somewhere in the basement, and what mayor or transit chief wants to create a highly visible, far-flung legacy that ends up looking as modern as an eight foot home satellite dish? Like it or not, cutting-edge means little-explored, unvetted, vulnerable to being leapfrogged. With the speed of technological change being as fast as it is, is it any wonder that neither government (local, state or federal) nor private investors want to stick their necks out on tech ventures that involve so much untested ground?

Making sure that the PRT infrastructure remains useful for decades to come requires a careful analysis of the problems that PRT is supposed to solve and designing the machinery, software and architecture with an eye on that distant future. To do this, we must bet on various assumptions, many of which are, luckily, quite likely. For example, it can be wagered that land for stations in the inner city will not get cheaper or more plentiful. It can be assumed that the expectations for comfort, speed, quietness, will become more demanding over time. It is not good enough to come up with the best option currently available. What is needed is a solution that will evolve to be better and better, and will never be eclipsed by some new technology that unexpectedly becomes polished and cost effective.

Too bad the challenge isn’t confined to the just the vehicles. Daily use always reveals design shortcomings, and new additions to a fleet will surely sport many improvements. Evolution happens more quickly for parts of a system that are frequently replaced. Conversely, (and this is the problem) since the track should last for many decades, we are seemingly stuck with whatever we start with.

The obvious downside of making such wrong choices was a motivation for establishing this blog and a call for consensus and standards. It soon became clear, however, that various PRT developers would always differ on what design approaches would win the day, and that it hardly mattered anyway. Financial backers have little interest in anything beyond getting an initial contract and ownership of proprietary technologies. Yet perhaps there is a way to address this whole problem of obsolescence that makes sense for all stakeholders in both the long and short term; Modularization!

Modularizing PRT (or any other system) ensures that only a barest minimum of components cannot be easily swapped with updated versions. As readers of this blog know all too well, a tremendous amount of work has been done herein on bogie designs that were later scrapped. The bogie, of course, fits within a mating track, so if the bogie is not perfect all of the track for years to come will have the same shortcoming. It is like introducing a bad gene into an organism that will be carried down through generations of offspring. By modularizing the mating components, this risk can be minimized. In particular, PRT track, of the sort we are dealing with here, can be divided into two functions. The first is to provide rigidity across a span, like a bridge, and the second is to provide the interior with rolling surfaces, electrical and data carrying structures, and so forth. This second aspect can, in whole or in part, be replaceable, adjustable, or otherwise be modifiable. This is not an intuitive way to treat track design, the first instinct being to make the track as simple, strong and affordable as possible through tight integration. There are, however, natural boundaries within the track that can be exploited. Issues of thermal expansion, sound and vibration isolation, third rail and cable maintenance, etc. all tend to favor fastened inner structural elements over direct, permanent (welded) attachment to the structure. Note also that, within the SMART framework, there are already specialized track “innards” for climbing or making tight turns. Even the structural shell has some modularization, first, because lengths of track would most likely be manufactured off-site in prescribed lengths and turning radii, but second, because the left and right halves from a length of track would optimally be detachable from each other so as to facilitate the insertion of switch points or just for ease of access.

Modularizing elements of the track also makes the initial design of the bogey much easier because it can be designed for what is most practical and cost-effective today without as much fear of introducing some demon-seed design detail that will be impossible to exorcise at a future date.

Modularizing key track elements also facilitates adjustability. Rather than setting internal dimensions in stone, why not build-in a range instead? Especially if it only involves punching a few alternative bolt holes – sort of like adjustable shelves? 

This illustration shows just how simple modular PRT running surfaces can be. Two pieces of angle steel, (red) and two inner guide rails are the only continuous components in this (evolving) “Mama Bear” configuration, other than the “third rail” electrical contacts and “leaky cable” Ethernet communications. (Not shown.) In other words, if a city were to, for some reason, change to some other system, there need not be a whole lot to swap out.

Today, PRT’s advantage shouldn’t be seen so much in terms of robotic vehicles, but rather as the most practical way to enter, exit or bypass the stop-and-go ground-level congestion that is an unavoidable part of urbanized life. It is the exploitation of unused “air-corridors,” and it can only be accomplished in such an affordable and compact fashion (and with such high vehicle density) using automation, or it would have been done long ago. We may well even be entering an era of “If you build it, they will come,” when it comes to PRT track, since exploiting these corridors represents a quantum efficiency advance in the same vein as the ongoing efforts of companies like Amazon, Google, Apple, Tesla, etc.       

In a future where ground-based automated vehicles are commonplace, PRT will still add an important, complimentary contribution, but besides being affordable and long lasting, it must be versatile. Making track components modular and adjustable seems like a vital first step in making sure that first iteration systems do not become obsolete in the face subsequent designs and this, of course, is prerequisite to being seen as a good long term investment for a city. In other words, any PRT system isn’t seen as future-proof is toast because nobody will take a chance on it in the first place! Well, back to the drawing board...

Happy Holidays from Dan the Blogger!

There Will Be a Quizz.

In the last post I referred to PRT as a kind of “Urban Wormhole” and spoke of how self-driving taxis could never replace PRT. I would like, in, this post, to follow up on that a bit. I think it is important to make the relevant arguments clear and on the table for all who will listen. An entirely new and untried transportation infrastructure is a tall order, yet I believe there are unassailable arguments why such an augmentation to our current systems is necessary and inevitable. I have included a short quiz in this post, designed to (hopefully) win someone over. Now, if I could just come up with a really catchy slogan….

  

The robotic car push reminds me of that stage of the internet revolution that centered on perfecting the dial-up modem, which of course, can only be as good as the phone wires it is connected to. In the case of mobility, at least in urbanized areas, the main problem is that there is an inherent cap on our surface transportation’s efficiency. It is, at best, 50%. The reason is simple. Simple physics dictates that if 50% of traffic wants to go east/west, and the other half wants to go north/south, each will have to yield right-of-way 50% of the time, once a line for each direction has developed. Nothing but passing over or under that crossing traffic can improve this dismal number. And that is the best case for the intersection itself. Were we to measure efficiency based on the time difference between “making the light” in no traffic and what can typically happen in rush hour for individual cars, that efficiency number would be much, much worse… 15 – 20% perhaps? And that is only one, and they add up! In what other endeavor would we put up with such inefficiency?

This is all unfortunate because, with the possible exception of bike trails or sidewalks, there is no current surface transportation infrastructure that can be elevated or buried economically enough to generally allow multi-level, non-stop traffic flow. If it WERE economical, we would not have such gridlock today!

Vehicles, and the surfaces constructed for them to roll upon, (this includes rail) have evolved to be too big, cumbersome, and expensive to be the only alternatives in space constrained, urban areas.  How ironic that, in a quest for the efficiency of carrying more load per vehicle trip, we have accomplished exactly the opposite! In all fairness, bigger really IS better, once you get out of town a bit – yet gridlock is the elephant in the room when it comes to urban mobility and robotic cars can only be of peripheral help in the current context. Any real solution demands an infrastructure specifically designed for non-stop travel in all directions at once, and logic dictates that this architecture be smaller, not bigger. The fiber optic cable of transportation! Actually, it is within this framework that automatic driving technology can really shine. With a faster, yet smaller “pipeline” the driving decisions would come at a much faster rate as well. No place to be texting!

So here is the quiz. It is more for making people think and to stimulate conversation than anything else. Maybe it will help win a few converts!

1] Non-stop ground transportation can only be achieved by incorporating overpasses/underpasses but this is impractical for widespread use because of the heavy loads that our current roads and rail systems are designed to carry.  True/False

2] The majority of vehicles on the road are carrying payloads, including people, that weigh just a tiny fraction of what roads are built to carry, and this represents a waste of resources if more appropriately scaled infrastructure is possible. True/False

3] The ONLY way for most travel to be non-stop within an urban/suburban environment is to create a new, more affordable infrastructure which is necessarily aerial and sized appropriately for lighter payloads, such as people.  True/False  

4] The technologies for automatic vehicular and traffic control to utilize such an infrastructure have now come of age.   True/False 

There. Saying “False” to any one of these will hopefully start a thoughtful debate at least. “Grass roots” movements have to start with consensus, and consensus must start somewhere!   

When I started this blog, part of the mission was to create some standardization, particularly with regard to the track. Seen in this light, it can be better understood why so many PRT bogie/track designs have been explored on this site. The world needs an infrastructure for urban/suburban mobility that allows non-stop travel. Dual-mode? Fare based? Privately owned? In a way it really doesn’t matter. To me the question is, “What are the mechanical/architectural underpinnings that will best encourage the development and proliferation of such a system?”  We need the combination of present practicality and boundless future possibilities if we want to propose it as a solution worthy being added to skylines across the globe. I believe a PRT track can be designed that includes very little beyond the architectural structure that is required for spanning between support posts. Sort of a standard PRT building block, which (as most of you know) I have dubbed the SMART (Suspended Multi-Axis Automated Rail Transport) platform.

A brief progress report is, perhaps, in order. In the design pictured up top, I have continued with the theme of using off-the-shelf-parts, and experimented with putting the four motors between the drive wheels instead of off of the ends, and this shot highlights a new cam-driven lever-type switching-guide-wheel mechanism.

Right this minute, the holdup is this – I love the idea of being able to remove the side of the track that normally switches off (right if you are American, left if you are British) without diverting PRT traffic. This would allow switches to be added or removed with minimal disruption in instances where no alternative routing exists, such as is likely to happen again and again on the outer edges of any growing network. Unfortunately this entails running on the left wheels alone and doubles the load on them. If the wheels are to be soft enough to cushion vibration and smoothly handle expansion joints, and especially if they use ordinary, safety-rated pneumatic tires, they will compress under the load and maybe even deform side to side, adding substantial complication to what could otherwise be a super simple switching scheme.

In these last two pics first note that the steering wheel guides have been turned upside down (compared to the one on top) and there are no longer two sets per side, like in previous posts. It looks like this would be sufficient, even in this "half-track" mode, if we wanted to use custom solid tires designed not to rock or compress too much. Unfortunately I would like to make this cheap and straight forward enough for an individual, company or university to build for experimental purposes…, hence the “off-the-shelf” trailer tires. (Smaller, higher pressures and stiffer sidewalls than automotive)

Finally note how the track’s spine is missing the opposing C channel, since that side has been removed. That otherwise sandwiched plate is a splicing means, a potential hanger for cable stays and placing an upside down “U” channel over it can create a waterproof seal, like in a standing-seam metal roof, when used with the sheet metal sheathing, which is curved to stiffen it between structural ribs.  Work continues! 

168> Self-Driving Cars and the Urban Wormhole

In our last exciting episode I promised to explore cooperative robotics, but there is an unavoidable side issue that is worth at least one post in itself, one that high-jacks the whole subject. What I am referring to is self-driving cars. It is not just that PRT and automobile automation have such obvious similarities that makes the subject a prerequisite to discussing PRT control. It is also the fact that self-driving cars may actually change the definition and purpose of PRT.

Self-driving cars are not just about following directions and staying on the road. Spinoff features such as automatic braking for collision avoidance are already widely available in everyday production models. Since self-driving features often involve technologies that clearly can enhance safety, there is an “arms race” in this regard.  With communication between vehicles (“I’m slamming on the brakes, so you better, too!”) and awareness of real-time traffic, (such as could be monitored, compiled and reported by the vehicles themselves) it is not hard to see how cars could be made to operate within a sort of “hive mind,” to the benefit of the group. This is basically a PRT operating system and is a wakeup call to self-steering PRT systems like ULTra or ToGethere, whose technologies are getting leapfrogged by this trend. Notably, the self-driving paradigm is proving that a high degree of autonomous control is doable, challenging the centralized control schemes of only a few years back.

Does self-driving auto technology render PRT irrelevant? Do self-driving cars eliminate the same problems that PRT was to solve?

The short answer is no. The question does, however, illustrate how various flavors of PRT have very different challenges in this new technological landscape. What, for example, should the business model be for ULTra in a world transitioning to self-driving taxis that may not need guideways or stations? Of course that may be quite a ways off, and maybe it is Google who should be approaching ULTra. After all, every cent ULTra has made is a cent more than Google has made on its robocars, with Google putting all of their eggs in a business-model-basket that is still a bit of a head-scratcher and is contingent on many  unanswered questions when it comes to safety.

So far Google and the others have seemingly only taken their vehicles out in decent conditions, weather-wise, content to garner impressive numbers of miles without incident. But how do they handle being behind a vehicle that is dropping debris? Or on patchy “black ice?” Fresh snow or street flooding can completely obscure where the road is. Timid response, in these instances, that would prevent lawsuits is also the kind of driving that would snarl traffic. Imagine a car that is afraid to go through ankle-deep water and so just stops! Can a robocar understand when weather conditions are deteriorating too much to enter the freeway or understand the significance of a funnel cloud? Humans usually know when they should stay put or go back. Will Google be able to give that much common sense to their cars? What about morality? Will they know to hit the truck to avoid the woman with the baby carriage?

It has been reported that, at least some states, they cannot dispense with manual controls (such as a steering wheel) nor the human seated so as to operate them. This leads one to wonder under what conditions the authorities would permit such use. Beyond that, what is the profit model that trumps the obvious, added liability issues? Do drivers really want to relinquish all control and do manufacturers really want to sell mechanically stripped down cars with no sex appeal?

A safe starting point would be a special lane or only going at fairly slow speeds. (i.e. a mode similar to current pavement-running PRT systems) After all, many localities allow golf cart type vehicles on public roads, and these need no horns, airbags, seat belts, etc., as they don’t go that fast. While this would probably be allowable, it does little to solve urban congestion and so, by itself, risks irrelevancy.

Interestingly, there are flavors of PRT that have just the opposite problem. SkyTran, for example, is really built more for speed than for serving little stations in every nook and cranny of a typical city. Suspended systems, in general, have the potential to move people from one side of town to the other quite quickly using an inexpensive, minimalistic track, but like all PRT, suffer from the potential problem of not having a sufficient number stations and walk-up customers to create the cash flow to pay-down the system components and still provide a return on investment. It’s the old first and last mile problem. Could self-driving automobiles be the answer to aggregating more PRT passengers at fewer stations? Quite possibly.

Uber has expressed interest in self-driving cars, and car sharing schemes like Zip Car raise interesting questions about ownership. Why garage a vehicle that could be gainfully employed elsewhere while you are not using it? Why own a vehicle at all – especially if there is one parked close by that will come to you when summoned?

Once upon a time, PRT offered a unique combination of benefits that could not be had otherwise. It was automated, elevated, personal, fast, but it was only practical within an interdependent framework of technologies. Over time, developments in sensor, communications and computing gave advantage to a variety of methodologies enabling new designs that emphasized varying missions and business models. The emergence of autonomous cars, it seems, puts a focus on one of the original themes, which is a network of fast, elevated, non-stop corridors that are unencumbered by the gridlock below. This mission is unthreatened by the self-driving car revolution and, indeed, may well benefit from it. PRT, at this point, needs to be considered not as a fleet of automated taxis, but as a network of personally navigable urban wormholes. The automated taxi aspect is now only a means to an end, not the end itself.

Originally the idea was to space PRT stations so that each was reasonably within reach by walking. Now perhaps each station could garage a half-dozen automated taxis, giving such stations much broader reach. This associated service would not have to extend very far to cut the number of stations to a fraction of what would otherwise be required. This scheme works perfectly with car sharing, carpooling, or even private ownership. Even if each fully self-driving “car” can only go a few blocks, with similar vehicles and capabilities at each end of the PRT “wormhole,” the combination could be very synergistic. The timing and payments between the two systems could be integrated, even if under different ownership. On such limited routes where the speed limits are low there is much less reason to require a driver, meaning self-driving cars are clearly ready for this NOW. Where special lanes could be created, ULTra is also ready to go as well.  

Side note: The above combination offers less advantage for the SMART PRT designs shown within this blog because SMART is specifically designed to address the “last mile” problem with vertical capabilities and stationless pickup and drop-off capabilities. Of course any infrastructure, surface or elevated, will undoubtedly face obstacles on certain routes, and so alternatives are always welcome. That being said…

It is important to note that slow, short-haul, self-driving “taxis” also offer synergy with other forms of mass transit, such as light rail, subways, scheduled shuttles and so forth. Even with limited routes, (There might be too much traffic on public roads and no room for a special lane) phone apps could be used to locate the nearest suitable pickup point. Such pickup points could enhance the value of properties that are otherwise inconveniently remote from mass transit. Short hauls to such existing transit hubs seems like a good business model for such a product/service right now and deployment of such FULLY robotic vehicles, even at slow speeds, might serve similar R&D aims as the current, unpaid efforts and would offer a potential opportunity to cement a leadership position in the field while generating revenue.

Self-driving cars, capable of full city and highway use without special lanes or a standby driver are still a long ways off for general use, and the eventual payoff for the producers of such vehicles is questionable. Short range, slower vehicles face no particular obstacle to immediate adoption, however, and everybody from ULTra to Google to Uber to Zip and the various auto makers should jump on this opportunity to become leaders in this transitional space. Meanwhile PRT wannabes need to take note that the current technological backdrop no longer supports slower, station-intensive, short range systems. Instead, PRT companies should concentrate on designs that foster the cheapest, fastest network of elevated track possible, filling that one niche that automation itself cannot address. 

Elevation has always been the answer to surface traffic congestion, but has always been prohibitively expensive (not to mention ugly and in-the-way) when scaled for heavy vehicles, and so gridlock continues. Like fiber-optics compared to copper, some form of light, affordable, high-speed “pipes” for moving people are inevitable, and the first barrier, autonomous yet cooperative automation, is falling away fast. Like that fiber-optic cable, the second barrier is what happens at each end – how data is efficiently transmitted and received. Hopefully self-driving vehicles will help provide comparable, easy-to-implement solutions for either end of the mobility solution that cities need so badly - that Urban Wormhole technology called PRT.

167> Easier Every Day

Creating a PRT system is getting easier every day. Increasingly, it is a matter of employing off-the- shelf components in ways that have already been established for other purposes, using software that basically provides a “fill in the blank” framework, and communications that work reliably at blazing speeds using ordinary protocols. These days each individual PRT vehicle will have far more computing power than yesterday’s entire system, and what used to be worrisome safety issues can now be addressed by a redundancy of cheap processors and sensors that can check and recheck everything under the sun hundreds to times per second, using self-diagnostic AI software that is ever more capable.

When I started this blog one of my primary worries was that cities would never accept a whole new infrastructure that would be dependent on all kinds of exotic, proprietary technologies and specifications, understood only by the PRT system developer. At the time, only a precious few corporate giants had the technological credibility and depth of resources to give much political cover and comfort to local transit officials. Those days are fading fast. While any project can turn south, particularly when attempted by an untested company, at least the next generation of PRT systems will be understandable and serviceable by ordinary professionals, no doubt with considerable free help from component vendors. Indeed, the idea of an automated taxi service, what with self-driving cars already roaming our streets, only seems truly futuristic in regards to the uncertainties of the street – the darting dog, the patch of ice and so forth. Such a service within the controlled confines of a track hardly seems like a technological challenge anymore, just a monetary, logistical and political one.

With that in mind, there is a case to be made for setting aside any remaining system components that are overly exotic. Although self-turning wheel motors are absolutely perfect for robotic transportation, at present the selection of such motor/controller packages in the appropriate power range is still quite limited.  Therefore, it is not a great idea for me to tightly couple my open-source designs with these motors, as though the designs are dependent upon them. Mechanically, a self-switching bogie for carrying a suspended load (such as PRT passengers) is almost ridiculously simple, even with off-the-shelf motors. I have therefore used four ordinary BLDC motors in the above design. SMART (Suspended Multi-axis Automated Rail Transport) designs require a motor for each wheel because switching from cruising to climbing (and vice versa) requires the front and back wheels to momentarily rotate at different speeds, and turning in very tight quarters calls for the left and right wheels to rotate differently as well. The redundancy of four motors also dovetails well with reliability, continuing a philosophy of completely eliminating any possibility of a single vehicular breakdown, let alone anything systemic.

Shown are Golden Motor’s 5000w offerings, for a combined total of about 26 hp. It is reasonable to assume that these motors would be powerful enough for full “SMART” functionality, such as even climbing straight up if necessary, while still being “geared” to reach highway speeds, or close to it. (Contingent on final aerodynamics/permitted load.) Continuing with the “You can build it in your garage” theme, I decided to use trailer tires, which, despite their small size, are designed with tougher sidewalls and higher inflation pressures than automotive tires while still being load and safety tested. In production solid tires would be preferable, although there are various strategies that could allow this vehicle to limp along, even with multiple flat tires. Note – although I picture a 16”OD tire, as is clear from the end view, the raised steering guide wheel assembly ended up considerably higher, defeating the reason for that size wheel. With a few modifications, a 20.5 OD drive wheel could be used that will have a greater (1050 lb. each) load range.)

From my 3D simulations, it appears that this bogie can achieve turning radii (horizontal and vertical) of under 60 inches, keeping with a design philosophy of enabling PRT to go essentially anywhere with minimal conflicts and expenses regarding right-of-way or station placement. A whole PRT vehicle could easily pull a U-turn within the floor space of a small two car garage!

Briefly, a description of the drawing - Wheels A only come under load when stabilizing a turn, unless encountering gale-force side winds, or helping to support vehicle in the event of a deflated or over-weighted tire. (running slowly on only the two left wheels enables the switching side of the track to be modified or even removed, such as to add a junction, without completely detouring or halting all traffic, but this would tend to compress pneumatic tires until wheels A are sharing the load.)  Wheels B have opposite rotation because they hold the bogie down, (engaging the bottom side of the channel that A uses) especially at high speeds into gusty head winds, where the aerodynamic “pushback” would otherwise lift the back wheels, or when climbing “cog” style, using the pinion gear (or sprocket) C. Note that the pinion gear C and the drive wheels F are driven in unison while wheels B are free-turning. Normally engaged, oppositely rotating wheel pairs D keep the bogie centered. Raised steering guide wheel E does not normally contact the track because the guide rail is discontinuous and tapers into contact at junctions only. Note that steering guide wheel E gets raised and lowered with the upper wheels A of the OPPOSITE side, not the same side, as in previous designs, since the steering guide mechanisms (shown in violet) now crisscross each other. This more securely holds the bogie to one side or the other by basically scissor-clamping that side of the track, while hooking the top guide rail, so as to completely support the vehicle, if need be. The channels that hold these upper guide wheels (A) would, by the way, have a liner (shown in blue) that would only be thick enough to make forceful engagement at sharp turns and junctions. Although this bogie might, at first glance, seem to be bristling with various wheels, most only see use for a tiny fraction of the time. Their various sizes are proportional to the durations and load of such engagement. Not shown are the electrical and communications interfaces between bogie and track. Contacts for third rail” electrical feeds would be side-mounted. “Leaky cable” Ethernet could go almost anywhere. I have not yet worked on emergency brakes for this design. Also, the track is shown as a simplified representation of the various contact surfaces: It is not some miracle extrusion!

Finally, I would like to reiterate the rationale for the “Mama Bear” design. I can sympathize with readers who have, for years now, seen design after design come forward from this site, only to be replaced by yet another, presumably better one. Hey! The Model T was a great design as well, but that does not mean it was the “last word” in automotive functionality! In the case of prior PRT designs, there was always an inherent conflict between the holy grail of minimal track size and the obvious merits larger, automotive-sized wheels for heavy loads, higher speeds, and less maintenance. While simply splitting the difference is one solution, this essentially means that future designers must “round up” both the track and the bogie size to accommodate the largest and fastest anticipated vehicle and impose that same design on neighborhoods where such a system could prove unpopular or too costly. But the only other alternative is to limit the potential speed or size, which does not seem like a good starting point either. A high speed, 6-10 person, scheduled shuttle between an airport or a park&ride and downtown seems like a practical arrangement, and would be better yet if the track is PRT compatible. But let’s keep such “muscular” track out of peoples’ front yards! Simply eliminating mechanical reliance on a track’s “ceiling” height allows this flexibility, so that the smallest vehicles, designed for using equally small track, can still larger track wherever needed. Smaller track, we should remember, is much cheaper and so has inherent advantages in addressing the “last mile” problem, (or simply providing more coverage for a given cost) and we should not dismiss places like campuses, that don’t need a family-sized vehicles in the first place.

In conclusion, I would just like to point out how mechanically simple this whole thing is. There are two moving assemblies that go up and down on a cam, mounted on a frame (yellow) that holds four motor powered wheels. Other than that, what is left is basically an exercise in cooperative robotics, a technological environment that is becoming increasingly commonplace. I will be addressing aspects of that next time.