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.