J Edward Anderson, for those who don’t know, is sort of the “grand elder statesman” of PRT. He holds patents, has written books, countless papers, and currently heads up PRT International. One of his papers is “15 Rules of Engineering”, and rule number 9 is “Recognize and Avoid NIH (Not Invented Here)”
So am I just re-inventing the wheel? A quick look at PRT patents would tend to support that case. Here is just one sample illustration. Look familiar?

Well here is my defense. Dr. Anderson left out one rule, one that I will call, “Think Super,” and it goes something like this.
All designs come up against natural constraints such as the laws of physics, social preferences, budgets, time, etc. All designs also carry the limitations implicit in the definition of project itself. Dan’s sixteenth rule of engineering would caution against accepting such restraints without being absolutely sure that there is no simple way to work around them. For example, how big should a PRT vehicle be? Answer. Somewhere between microscopic and celestial, until some factor forces constraint. I know what you’re thinking… (OK, not really…) “If it’s called “Personal Rapid Transit” It should be sized for its purpose, say big enough for 4 adults.” By that logic, it should be sized for one and one only. After all it says “personal”. But are we not designing an automated parcel delivery system where the parcels are people? If all else is equal why exclude the possibility of delivering anything? Now before someone starts writing about the downside of cargo delivery, understand that this is just an example. The downsides that that writer would list would be the constraints I have spoken about.
It is an unfortunate side effect of the profession that engineers are tasked with creating a design from decision-makers with time and budget constraints of their own. I know few engineers with the guts to really think “outside-the-box” in the critical initial stages of a project. Limiting the objectives of a task limits the work involved and speeds completion. That’s sound business practice in most cases but it leaves improvement for later models, making for slow, evolutionary change.
So why re-invent PRT? Because all of the designs I have seen are constrained, not by what is possible, but by what is expected. For example, 95% of PRT is track. It’s the permanent part. Yet it seems to me that precious little time has been spent considering the final form and function of this potentially enormous investment. To my knowledge, I am the only one (or at least one of precious few) suggesting designing-in the capability for carrying modernized street lighting and utilities or having a configuration that could be adopted for use in a warehouse. If functionality can be designed in with no additional cost, why not?
Near my camp in New Hampshire there is bike trail utilizing the remnants of a railroad track that went all of the way to Boston. It was built, however, for smaller trains than are standard today, with narrower track and bridges. Its present use speaks for itself. How did this standard get on the wrong side of history? How do we avoid making the same mistake? In a discussion about an existing PRT design I was reminded that vehicles need not corner quickly because it would buffet the passengers too much. What about a trip to the hospital or freight delivery at 3 am? Or repositioning empty vehicles? I was reminded that all of the vehicles travel at the same speed. Why? I will remind the reader that for most of the history of PRT, control without crashing was the issue. I think we’re moving to a place where the cars can have the intelligence to follow a much wider menu of directives.
So this is my philosophy on designing a PRT system. How fast? Lightning fast. How steep? Vertical. How tight the turns? On a dime. I say, let’s design SUPER PRT first and then back off from there, as required by current constraints, rather than putting time, thought and money into designs that perpetuate limitations simply to expedite a business model. Don't get me wrong. I have nothing but respect for the people trying to bring this technology to market. I just want to prevent track coming down in 20 years because better, newer systems and new uses require a slightly different design.

Lastly I would like to point out that I am endeavoring to create a set of standards first, not a set of blueprints. As I envision it, these standards would be useful for future designers, inventors, contractors and their customers as a means of simplifying navigation in a sea of complex functional concepts. Prioritizing the above-mentioned constraints inevitably leads to differing opinions on design options, and so a natural branching occurs. Such a branching has already occurred regarding PRT vehicles which hang and those that don’t. Have we ever really defined the trunk from which these branches emanate? Or are we just going to let it be defined by Wikipedia or Webster and design from that?










+Control.jpg)




