160> The Trainwreck Finally Happened

To my friends in the PRT community… I want to explain my sudden disappearance and long absence. Some of you may have experienced challenge of caring for an aging relative. Well, I have three such relatives, and they have all been living together in a big old house, unable to agree on when or where to move to get the kind of assistance they increasingly need. The youngest, (83) is particularly stubborn and has basically told me to “Butt out” for years. Obviously this standoff could only end badly, and now everything has really broken down. We are have been dealing with senility, anxiety disorder, financial difficulties, mobility and a host of other problems for a while now. Now the mainstay of the group has required 2 emergency surgeries in the last 5 weeks. It is stage 2 cancer. As the only "available" family member this has put me in a tough position. It is especially difficult, I have found, to clear my head enough to write this blog. Frankly, every time I start writing, I simply fall asleep. Such is my physical and emotional exhaustion. Also there are, after all, over a 150 posts already, so most of the more important topics have been discussed and re-discussed, and the main mission of this blog has been largely achieved. The kind of incremental design improvements that remain will hardly make gripping reading material, so its not a great time to have writer’s block. Moreover, any efforts toward this site would seem to be best spent organizing the existing material into a more cogent presentation. As it stands now, most of the best material is already deeply buried, and I am not inclined to add fluff just for the sake of posting new reading.

But believe it or not, there is a silver lining. When I am under a lot of stress I have always found relief by tinkering in the shop. Lately, in the evenings, I have found myself pushing forward on the scale model of the “SMART” PRT system. (Suspended Multi-axis Automated Rail Transport)  Such pursuits are easy for me to organize into sub-projects that can be worked into my bits of free time. It’s like knitting. The project may be big, but it’s relaxing and easy to pick up and put down. In this way I have actually made a fair amount of progress, and this seems like a better use of my time right now.

I have come to believe that society really isn’t ready for PRT. It is too big of a change and too counter-intuitive to be championed by anyone in the public sector. Yet I believe it will happen eventually, since leaps in efficiency are inevitable over time. Revolutions come when evolution is stymied. I believe that the case for PRT will be made obvious (and therefore less risky) by related technologies becoming more commonplace. Delivering people around a city is not that different from delivering packages around a distribution or mail center, delivering meals in a hospital, baggage in an airport or pallets around a warehouse. Robotic technologies will increasingly replace current systems and evolve, I believe, toward overhead rail-based systems. “Pick and Place” is already one of the most common uses of robots, and it seems inevitable that their gantries will only get longer and robots will need to be untethered. It also seems inevitable that work will increasingly be done cooperatively by multiple robots on these overhead rails. A system using many untethered robots, moving materials around larger and larger arenas, basically demonstrates and proves the PRT concept. Jeff Bezos, in unveiling plans for home deliveries via drone helicopters, is surely conscious that his (3D) solution also applies to a similar problem existing within Amazon’s own distribution centers. Miles of conveyor belts are a slow, awkward and inflexible (basically 2D, gravity-based, inertia limited) architecture that is roughly analogous to the roads he seeks to circumvent. A small army of pick and place robots running around a 3D rail network could reposition items many, many times faster - without the insane hive noise and energy consumption of the drones.

Since this is my take on the PRT situation, I think the next step is for me to demonstrate just how simple the mechanics of such a system really are. Unfortunately I no longer have a machine shop at my disposal, but even this is sort of a blessing. After all, if I can build these things with simple hand tools, it’s a pretty strong indicator that mass production won’t be problematic. One disclaimer though; Making this model to scale is not at all easy. My homemade circuit boards, for example, would scale up to be suitcase sized, but I need to fit them in somewhere, nevertheless. There is a necessary learning curve where parts are built just to act as place holders and to experiment with the fabrication methodology. Then they are tossed and replaced by something better and easier to make. So let’s just say patience is a virtue!

So that’s the situation. The blog, for the foreseeable future, will be basically on hold, although I plan to post occasional progress reports. (or anything else that may come to mind, just as long as it basically writes itself!)  At some point I hope to reorganize the material on the site to make it a better resource. My apologies for my long absence and for not returning any emails or comments during these trying times.  I hope to get to them soon. Unfortunately, it appears that the situation here will be tough for a while, as chemotherapy will be starting in the next few weeks. (And she doesn’t want nurses in the house!)  So this may be my last contact for a while. But when I return, mark my words, I’ll have something pretty interesting to show for my absence. Happy Holidays and Adios ‘till then!

160> Lessons From Industry

How does running a PRT system compare to, say, running an assembly line full of robots?  Or how about compared to industrial processes like a chemical plant?  There is a lot of reason to ask such questions, because the controls for such complex processes are always being upgraded with the latest equipment, so it’s interesting to see what they are using and why.  Could such solutions be ready-made for PRT?

Let’s start with the onboard computer.  What is needed is a stripped down system, both in terms of physical and software architectures.  Half of the stuff on a typical motherboard is completely unnecessary and therefore detrimental.   Also, a computer for industrial processes can’t run on Windows or any other ordinary desk operating system because such systems are specifically designed to take as long as necessary to finish a task.  This is so the time may be divided between however many programs might be running at the time.  Industrial processes, on the other hand, usually need to perform within an exact time frame.  You can’t have one robot run more slowly than the others in an assembly line whenever it is receiving new instructions, for example.  Also, industrial control computers need to be designed for potentially harsh environments.  Dust, changes in humidity, temperature, even insects can cause failures in PCs as well, but not catastrophic, dangerous failures that could result in loss of life or extensive physical damage.  Finally, there is great advantage to giving industrial control computers lots of input/output terminals, something missing on ordinary computer motherboards. These computers are often used as an intermediary between sensors and switches, so having simple input terminals for the sensors with corresponding outputs for those switches simplifies matters greatly. Actually, this role (and history) of being used in place of a simple relay or arrangement of relays is reflected in the name, trademarked by Allen-Bradley. (A division of Rockwell Automation)  They are called Programmable Logic Controllers, or PLCs for short. (I have also seen them simply called “controllers” by other manufacturers)  Of course when they were first invented they were really more about switching than computing.  However certain capabilities, like dealing with complex analog data or modern communications protocols have necessitated greater and greater processing power, not to mention the desire to incorporate more and more processes into a unified control environment.  Now whole banks of PLCs can be rack mounted, or very inexpensive and compact units are available that have only a half-dozen input/outputs, an Ethernet or RS232 port, and little else. 

Controlling large numbers of PLCs or other EDIs, (Intelligent Electronic Devices) including from long distances, is very common.  One broadly used term for this is DCS (Distributed Control System) and another commonly used term is SCADA, which stands for “Supervisory Control and Data Acquisition.”

(The differences are minor, with SCADA being more data collection oriented and DCS being more action oriented. Since PRT control is highly involved with both, I will just keep it simple and use “SCADA.”)   SCADA systems are used throughout industry - to control traffic lights, a building’s HVAC and access, electrical grids, pipelines, wind farms, water treatment plans - even space stations!

SCADA systems have become so commonplace that there are dozens of venders and many internationally recognized standards, protocols and practices.  The SCADA architecture does not necessarily require PLCs, but can also be used to control the PLC’s simpler cousin, the RTU.  Remote Terminal Units, (Or Remote Telemetry Units) are microprocessor controlled sensor/switches with networking capabilities.  Obviously the line between a full featured RTU and a bare-bones PLC is a very blurry one, and getting blurrier every day.  On the very lowest end, there are also microprocessor controlled relays, sometimes called “control relays,” which enable some rudimentary control capability from sensors or neighboring equipment.  A typical example would be to use such a unit as a safety switch, where some sensor(s) can cause a process to stop - say, to stop something from overflowing, overheating, or trying to work in a flood.

The SCADA architecture is extremely flexible, in that there are no set rules for where primary control of any given process resides.  Supervisory control can be exercised from more than one site, and much of the “decision making” can be done in the field by PLCs, RTUs, or even hardwired relay arrays.  This is facilitated by software which is designed around ladder logic, which itself has its roots in relay design for automation and process control.  There are a number of options for communication, and they have increasingly included TCP/IP and Ethernet, something that has recently raised security concerns when it was revealed that all kinds of “back doors” are easily discoverable in systems controlling essential infrastructure such as the power grid. (The flip side is that with such common communications protocols, standard firewalls and other security procedures can be easily deployed and updated.)  As with the field-based equipment, a real-time environment may be required for more remote communications as well, which is a much greater challenge than would otherwise be the case, especially with lots of nodes over a wide area.  The time lags that we have all experienced on phones, TV or email are testament to the thorniness of this issue. This has been partially addressed by a dozen or so Ethernet-based solutions which separate communications channels that must perform in real-time from other sorts of chatter.  Any distributed real-time system is restricted to relatively fewer nodes in closer proximity, though, although dedicated infrastructure, such as fiber optic lines, obviously change those parameters.   As might be expected, if the communication is of a type that can tolerate quarter-second lag or more, hundreds or even thousands of nodes can be dispersed over great distances.  

As to how all of this affects the design of PRT control, the last point is perhaps the most important. Barring an absolutely clean, dedicated, failure-proof real-time signal to each vehicle, there is obvious advantage to keeping millisecond decisions local.  That is really not a problem, as that is what PLCs are designed for, and clearly each vehicle needs one or two. The questions arise a bit further up the control ladder.  In switching, for example, there would be great benefit in allowing direct, real-time communications between vehicles.  I do not think this is out of the realm of possibility with ordinary SCADA solutions, although it’s a bit unusual.  It is certainly unusual in that new vehicles would have to dynamically introduce themselves into a LAN (local area network) whose members (and location) would be constantly changing.  Ethernet, however, allows such discovery, and as I mentioned, some variations of Ethernet allow real-time communications. These capabilities are bound to rapidly become more versatile and easier to implement, due to the continuing proliferation of processing power toward the edges of the network. (i.e. the machines themselves) That is because as machines or processes are increasingly self-directing and regulating, it means that if other processes further downstream are affected in any way, it may make sense to have the equipment collaborate directly rather than via some remote control room, miles away.  This has led to substantial interest in facilitating such collaborative automation by creating software and hardware standards specifically designed for this. I know of nothing custom tailored for vehicle-to-vehicle collaboration yet, though, and for the foreseeable future I doubt anything will be able to replace onboard decision-making as a backup.

While I’m crowding our minds with new acronyms, I just have to mention one more.  There is something called PID (Proportional-Integral-Derivative) control, which falls into the realm of tasks most PLCs can perform.  It works like this: Imagine steering a big ship.  When you turn the rudder, it takes a while for the ship to follow suit.  If you are not careful, you may over steer, since the momentum of the turn, once started, is difficult to stop.  Or how about the velocity of material in a pipeline  - or the pressure?... or the heat of very large amounts of material?  Again, there is this quality of delay followed by momentum. This has relevance in PRT traffic management.  Consider the question of what happens when one part of a network is heavily trafficked and another isn’t.  If enough vehicles, either autonomously or by central control, all seek the less trafficked route at once, it could create an instant traffic jam, while the previously trafficked route could go suddenly empty.  This is clearly the type of thing a PID controller is designed for.  Isn’t it nice to know this stuff is already on the shelf?

  

It is interesting how the distinction between vehicles and robots is disappearing.  What started deep inside the family car for better fuel efficiency and braking has exploded to the surface with self-driving features, and this is clearly the direction for PRT as well, so it only makes sense to control PRT vehicles in the same way that other collections of robots are controlled.  It is also clear is that there is a basic commonality between  the control requirements for PRT and many other fields, so there is no need to start from scratch.  There are sensors, and things that must be physically or electronically done based on what they show.  There are processes that must be initiated, monitored, and terminated.  There are times when machinery must act autonomously, and times when it may be best to control it from afar.  There are times when far-flung pieces of equipment need to receive updated numerical values or instructions and times when similar data needs to go in the other direction.  The point is that most possible PRT control topographies are already established in other industries, and it is not just the equipment or software. It is the human expertise. There are classes in SCADA and ladder logic and PLC implementation, so the experts are out there as well.

Long ago, when I started this blog, I called for standardizing aspects of PRT, so that entrants to the field this could offer products built on a firmer foundation than could be found in the custom (ad hoc) solutions invented by the PRT designers themselves.  This call was met with some skepticism, as there are always issues as to whose standard is better, and if the standard will become an obsolete encumbrance.  The point was also made that investors in PRT companies would want patent protection and other proprietary advantages to safeguard those investments.  My point, though, was that there was entirely too much trust being asked of purchasers of PRT systems.  Who would want to buy a system controlled by a magical black box full of proprietary equipment?  What if it doesn’t work as advertised?  What if the company folds?  The framework mentioned above goes a very long way toward addressing my concerns, as well of the concerns of another group who I rarely hear mentioned in conjunction with PRT - insurers.  After all, large factories and refineries are presumably insured, and are run by SCADA systems, so the safety track record of given systems is a matter of public and private record. For PRT, all of this is, (in the words of Martha Stewart) “A good thing!”

159> Headway? I Don't Need No Stinkin' Headway!

I wonder if PRT is a technology that, up until now, really wasn’t as ready for prime time as we would have liked to believe.  I started pondering this while considering the concept of “line speed.”   What good is it?  It seems to me that its primary function is to stop insufficiently intelligent vehicles from rear-ending each other.  I know what you are thinking.  Anything other than a set line speed is unnecessarily complicated.  With every vehicle trapped between two others, what is the point?

Let’s consider the unthinkable - congestion on the network.  Yeah, I know, PRT congestion is just not supposed to happen.  Some magical computer in the sky will prevent it.  Yet we know better.  If the network is big enough, and there is excessive demand in one part of it, it will happen, and having the system refuse passengers going to certain destinations is hardly a solution.

Our previous discussion regarding the three lane bridge really brought the matter home. The bridge represents what PRT planners would want to avoid the most; a bottleneck.  This is the antithesis of the grid systems traditionally envisioned for downtown use.  Yet we all know that people’s transportation needs are not uniform, either in time or location.  We also know that there is liable to be scant funding for any route that is not expected to see a whole lot of business.  That means that the less trafficked parallel routes that would take up the slack in rush hour are unlikely to be there in the first place.  Simple “move forward/back by a half-slot” type of merge control becomes a clunky version of variable speed anyway since, in heavy traffic, opening up a slot for a merging vehicle creates a chain reaction that must extend far backward and/or forward until space is found.

One obstacle to a good remedy is the idea of needing a set headway - especially sufficient headway to come to a complete stop if there is an immovable object ahead.  This so-called “brick wall stop” rule is an ill-suited extension of railroad regulations, which I believe may currently extend to “automated people movers.”  No such law, I would note, has been extended to Google’s self-driving cars, which are a much closer comparison to PRT than trains.  Aren’t self-driving cars automated people movers? Be careful of what you call yourself!

Without adding track, the only way to get greater vehicular throughput is to reduce headways and/or increase speed.  And so we must ask the logical question:  “How much headway is really necessary?”  I contend that it is possible to design PRT systems where there need not be any headway at all.  After all, crash damage occurs due to the speed difference between vehicles, (or objects) not the speed per se.  This is a very different situation from either automotive or railroad scenarios.  Unlike either, some PRT designs are be completely captive within the track, preventing lateral skidding or derailing in any weather.  They can also be designed to clamp the track for emergency stops. (preferably at a rate just shy of throwing the passengers around)  Also, unlike cars, PRT vehicles can be designed with perfectly aligned “bumpers.”  With the suspended gondola designs, forward momentum transfers to upward momentum in a swinging motion, potentially eliminating the possibility of contact between cabins altogether. (There would need to be a way to rapidly decelerate the swing before making contact with the track bottom, however)  And let’s not forget the fact that the braking capacity is independently replicated on each vehicle, with no drivers to the slow reaction time.  When a lead vehicle slows, a vehicle twenty cars back can instantly decelerate as well.  Since normal braking is electromagnetic (the motors simply slow down) the deceleration rates can be virtually identical.

These features, combined with variable speed, enable true cooperative merging and the safe elimination of headways, so vehicle density on a track could be taken to the limit.  That limit is having vehicles actually touching, essentially forming a train, but with every vehicle exactly matching the movement of its neighbors through its own propulsion.  And coupling?  Actually, with regular servomotor technology, it really would not matter if they were coupled or not.  Coupling, in the railroad sense, is simply a way for one car to pull another, so that they don’t all need independent propulsion.  Since PRT vehicles have independent propulsion that can produce highly accurate velocities, it really would not matter if the vehicles actually have an interlocking mechanism or not.  I imagine a cushioned magnetic linkup would be just fine, as long as the connection was elastic enough to allow each vehicle to “read” its own performance.  (Servo mechanisms require a steady stream of position information that is derived from their own effort, so that they may continuously adjust their performance.)  A good physical data connection would be useful, though.

Here’s how I see it all working.  Vehicles would have a “suggested” speed, but also would try to distribute themselves to facilitate maximum flexibility at merge points.  As the traffic increases, however, headway distances naturally become shorter.  At some point, this “suggested” speed (which, with sufficient traffic, is a de facto line speed) may be reduced - or not.  This is, after all, just a line of code and a judgment call by the system administrators and the city;  They, don’t, after all, want to scare the passengers!  Anyway, as more vehicles enter the stream, and the spaces between vehicles become too small for easy merging of vehicles, the algorithms that make the vehicles self-distribute change to make the vehicles couple into self-distributing trains (platoons) to open up whatever space is still available.  The entering vehicles merge to fill these spaces. Of course there is a limit to how far even this can go before there are simply no spaces.  There will still be the need to regulate traffic from the stations - to temporarily prohibit certain destinations if need be, but at least the track would be utilized to the full extent possible.  

Why not just skip the first step and have the vehicles group from the start?  Mostly because any system is unlikely to have a traffic problem for quite some time, and even then, heavy traffic would never be anything even close to systemic.  It would almost certainly require a natural bottleneck, such as the bridge, and be for short times.  Why design for the exception rather than the rule?

That being said, the incentive to overload a track infrastructure is undeniable.  Adding vehicles, each of which produces income, could be a very easy and painless way to gain transit revenue, and cutting network costs by never adding less essential routes seems inevitable.  That, while PRT providers need to provide the most “bang for the buck.”  The self-distributing model, I think, is the best, and the other can be seen as a work-around, for lack of adequate routing options.  It seems prudent to build in such a capability from the start, though as PRT should ideally be an unbreakable system that does not require particularly great planning or oversight.

Without diving too deeply into control issues, here is one supporting observation:  If there is enough traffic, the ability to merge will become increasingly difficult to execute locally.  In the extreme example, a specific merge might not even be possible without being timed from the onset of a vehicle’s leaving a station.  Yet this is not how the process is best done in normal circumstances, because coordinating all traffic centrally relies too much on shared computer and communication hardware, not to mention latency and connectivity issues.  The system would be vulnerable to all sorts of possible maladies.  Spreading traffic out massages the problem into one that can be normally solved locally, through vehicle to vehicle communications, (cooperatively) and with sensors and stored data.(autonomously)  Again, the system should be unbreakable.

And that three lane bridge?  Even in the nearer future, before people need or trust “zero headway” enough to use it for human passengers, empty vehicles could still platoon to use such a lane for the least possible time.  Without humans to confuse, a third lane can switch directions as often as needed.  In just a couple of minutes, a train of dozens of empty vehicles could zip across at breakneck speed, and then the lane could be returned to regular traffic or its role as an emergency/ maintenance lane.  Obviously the space saving advantages of platooning empties extends beyond the bridge as well.   

PS - Alert readers will note that the designs shown in this blog have compact bogies that do not touch before the hanging passenger compartments do, complicating platooning, or even safely pushing vehicles.  Elongating the bogies could make them hard to fit in an enclosed, tightly turning track, and figuring out the best compromise is high on the design agenda.  (We are talking about nearly 2 ft. projections, front and rear) It may be that the climbing (pinion) sprockets can be used for such tight turns using the “rack,” instead of the normal track guide surfaces. This could allow constraining parts of the track to be removed or relocated, thus solving the problem.  All of this will made easier to visualize with a physical model, and I am still working on that.

In that regards, in case you missed it, I have started by hand building some servo hub-motors, like in this video, (go to the 5.5 minute mark to just watch it work, without the technical jibber-jabber!)   The remaining three wheels are all coming along… I just completed and tested motor #2, which is really the “production” prototype.  (I wouldn’t like to try to replicate the first one…it was just too complicated!) Motors 3 and 4, modeled after number 2, are in various stages of completion.  What a shame that just when I learn how to build the things in an efficient, procedural way, it is time to move on!  Even worse, now know how to make them much stronger and more efficient, but I need to match motor #1. This is effort is based in Texas, but I am preparing to return to New England, where my more bucolic endeavors reside, so be patient - I think it will be worth the wait!

158> More on Bridges

In my last post I echoed one reader’s suggestion that bridges might be extremely beneficial in rolling out a PRT system.  After all, a bridge for PRT could carry the same number of passengers as much more expensive traditional bridges and could be routed more flexibly on either side.  By solving these particularly vexing transit problems, PRT could offer cities a much more compelling value proposition than would otherwise be the case with a limited starter system.  Like an aircraft that needs to surpass a certain speed to achieve lift-off, PRT systems need a certain number a stations and a certain amount of track to make enough economic sense to be worthwhile.  These numbers, unfortunately, are high enough that there are currently almost no interested parties.  A bridge or two might tip the balance.

This raises the obvious question of just how much cheaper a PRT bridge could be. One of the first tricks to getting the most span for the money is to use cable instead of trusses, as in suspension bridges.

Here is a transportation system where they have taken the concept a bit far, at least for my tastes.  (It’s called Aerobus, and this was a temporary installation, though it did carry quite a few passengers in its short life...)  Note that this is a two-way (double) track, so that the “M” supports are actually a pair of “A” supports.  Also note the arching of the track in the far section. Presumably weight of the vehicle is pulling on the main support cables, which are then lifting adjacent sections.  The bottom pic shows what is, apparently, a switched, off-line station.  The one thing I like about that top picture, though, is that it points out something about suspension bridges (not to be confused with cable-stayed ones) that is worth pondering.  I am referring to the thinness of the track itself between the vertical “hanger” cables.  Since these cables act as simple skyhooks and are closely spaced, the track needs very little structure to stiffen it.  In this way a suspension bridge can be extremely long, yet the “roadway” portions each only need sufficient girth to support themselves between hangers…  at least in theory!  (There are wind loads and natural resonance issues to factor in.)

Long bridges for lighter loads than for automotive use are actually quite common.  This is because pipelines (and the occasional ore conveyor) also must also cross natural obstacles.  Here is a pipeline bridge in China, for example. 

Notice the cabling on the sides to prevent movement from crosswinds.  This is actually a fairly standard feature in pipeline bridges.  Here is another example, although I have to say that I find the parallel main cable design puzzling for a single pipe.  I like the bottom one, which splays those support cables to handle cross-winds.

Since bridges for transit are almost certain to be bidirectional, and since I have never really explored double track for PRT, I built a couple of 3D models.  Note that there is no triangulated truss structure, since such short spans do not require it.  Such sections would simply bolt together end-to-end, with each spanning the vertical support cables. 

While working on the section above, I realized that a pedestrian walkway would be a simple addition, and so I stopped working on that model and started playing around with adding precast decking sections. 

While working on that, however, I got yet another thought, which is the matter of emergency evacuation.  I guess it doesn’t pay to start modeling without the full vision of what you really want.

Even with vehicles that are sufficiently autonomous to render system-wide failures impossible, if a bridge becomes impassible for any reason there is the prospect of backing up and turning away a lot of traffic.  Depending on the span, number close stations, time of day, etc. this all might take some time.  If the bridge is equipped with U-turns at each end, however, and traffic is instantly diverted away from even approaching those, it seems like a bridge could be emptied fairly quickly by backing up, taking the U, and going back toward the station of origin.  There is also the matter of evacuating the occupants of a hypothetical vehicle which is blocking the way and cannot, for some reason, even be pushed.  And let’s not forget about ordinary maintenance.  This brings up another thought that I had long ago, which is to have some way to roll a small hanging platform along the tracks without blocking them.  Another thought is simply adding an extra lane.  With crossovers, a middle lane could be used for diverting traffic for any reason.  Wider GRT vehicles would be able to fit on such a bridge as well.  Maybe I’d better ponder this all a bit more before starting yet another 3D model!