163> Turkey Day!

At this time of year, seems like everybody’s sharing culinary secrets. So here's my recipe for perfect PRT.  First you take individual desirable attributes, like speed, energy efficiency, and so forth, and, one by one, design for that attribute. The idea is to take each one as far as you can before it is clearly too much of a good thing. Take that design, set it aside for future use. Then you repeat the same process for the other, often competing attributes you have identified. Once all of that has been done, you have premixed the ingredients for truly great PRT, and the fun begins. Like adding spices to a soup by experimenting with small quantities, you add a little of this and a dash of that, backing off when you add too much, until the proportions are just right.

Recently I have been mulling over where I left off with SMART PRT, and have realized that there is still a lot of work left undone. If attributes like small turning radius, high-speed switching or low maintenance are the object, then I am done. But at what expense? I designed a system that is "track-compatible" with GRT, (larger group vehicles, such as scheduled shuttles) equal a car in speed and comfort, can even climb straight up… but what about all of the single passengers only going a couple of miles in the inner city? Have I excluded this important demographic? After all, to many who live and work in the inner city, this is what PRT is really about. Many do not even see an important role for suburban systems, as I do. Not everyone lives in a freeway-dependent mega-city. Perhaps I omitted an important ingredient from  the dish.

This reflection has also been prompted by a couple of factors. After my last post, about programmable motors, I discovered that since last time I looked into it, a huge amount of progress has been made in this field, and not just to make servo motors run programmed routines. They are using specially shaped waveforms for optimal speed or torque performance as well, in a process called Frequency Oriented Control. (FOC)  Unfortunately wheel motors with matched FOC controllers (with position control) have not yet arrived, and I hate promoting designs that rely on parts that are not available at practical prices. I love direct-drive wheel motors, but the advantages of FOC, when it comes to integrating motors into a larger system software architecture, are huge. Also, the appropriately sized wheel motors that are available are for two-wheeled scooters and e-bikes, and they have through-axles that are meant to be supported from both sides of the wheel. My designs do not reflect this, although these motors could never achieve higher speeds anyway.  

I also have been troubled by my abandonment of a totally enclosed bogie. In a quest for high speed and smooth switching, I designed-in some very large diameter centering and steering guide wheels, leaving guide surfaces exposed on the bottom of the track and those guide wheels semi-exposed to the elements. That large diameter would be consistent with a softer, quieter ride via softer, quieter wheel materials, which, of course, wear more quickly - thus they are bigger for more wear surface. That diameter could be maintained, but with harder materials, for heavy vehicles like GRT. At least that was my rationale. Yet I have never been a fan of what this does to the track, not just for the reasons just mentioned, but also in regards to compatibility with vehicles that don't need such big guide wheels since they are for slower, urban use. Furthermore, the high speeds or heavy vehicles are likely to make the most noise where it doesn’t matter much, such as along freeways. And not fully enclosing the guide wheels inside the track makes them louder anyway.

I think, in retrospect, I designed for the exception rather than the rule, and it is time to see how a lighter, smaller system can be modified toward the larger and more powerful, instead of starting with the heavier system and trying to design lighter vehicles for it. At the very least, those reverse rotating centering wheels (golden-yellow, below) can to be reduced in diameter. 15" is just way too big to require (due to track proportions) of lighter PRT vehicles. The load on these wheels may be continuous, but it is not that great, except perhaps for GRT, which could even use steel wheels if wear is a problem. 

This illustration, (not to scale) shows the current track design. The bogie is highly abbreviated to more clearly show the guide wheel positions. The configuration shown is for straight travel, as even the raised steering guide wheel (left, light brown) is not quite touching. This is because the steering guide rails are discontinuous, (and therefore not shown) and only taper into contract in advance of a switch-point. It can be seen that the track (blue) is not wide enough to wrap the guide wheels in this design.

Also at issue are those multipurpose "hold-down" wheels. (maroon) These are a holdover from early designs that had no other options to deal with the tremendous twisting forces (red arrows) that could be exerted by a swinging passenger cabin. These also doubled as upper steering guide wheels, securely locking the bogie to one side or the other as the track splits into separate directions. As one such wheel would be in continuous rotation for long periods, these were also designed to be of a softer material, like rubber, and of large diameter. The problem is that this solution, which engages the top of track, means that a smaller, lighter bogie, which might optimally run in a smaller track, would have to be inconveniently tall to reach these “ceiling mounted” guideways. The key to solving this dilemma has been partially solved by current position of the large counter-rotating running guide wheels. (golden yellow) They are now positioned so as to directly absorb the brunt of any sideways forces, making continuously engaged upper guide wheels unnecessary. Any upper guide wheels would be for switching and extraordinary events, such as a sudden gale force wind gust or emergency stop. The position of those large counter-rotating guide wheels does, however, directly add to the height of the track, and competes for vertical space with the drive wheels. (Purple) These may have to be reduced from typical automotive size, even for heavy or fast systems.  By the way, if you are wondering about those things sticking out of the axles, they’re for climbing... Check out post 131 for details.

So anyway, I have concluded that my feast is not quite ready. I need to add two more ingredients... Bogies designed for drop-in motors that are available now, and a lighter, lower performance vehicle equally at home in the heavier track. What I am aiming for is a three tier system for vehicles - a “papa bear” (GRT) a “mama bear” (high speed, longer range PRT) and a “baby bear” (light-duty PRT for inner city and campuses.) Right now I see “mama bear” track as universal, being sharable with either the larger or the smaller, but not both at once. For example, track running along freeways wouldn’t allow any “baby bear” pods, and “papa bear” GRT vehicles would be only for connecting large stations that are far apart, while the mid-size, “mama bear” vehicles would be able to go anywhere. (Actually they are more like a compact car, very tight for 4 average adults.) That size, after all, can comply with US disability laws, whereas anything catering to individuals or pairs could not.

And speaking of the US,.. and catering,.. Tomorrow is Thanksgiving, a US holiday about giving thanks while eating ourselves into a coma. So happy Thanksgiving, everyone. If you need me, I’ll be in the kitchen. I’m preparing a feast!

162> Musical PRT

I think it is high time that I offer a primer on controlling rotary motor powered PRT, at least as I see it.

Let’s start at the very beginning. First of all, not all motors just start turning when you apply electricity. The ones that do generally have “brushes,” a kind of internal switch that turns off and on as the motor shaft rotates. Such internal, mechanical switching is inherently “dumb” and not really suited for PRT. We’ll concentrate on other types.  

Brushless DC motors, in particular, can have a number of different wires coming out of them, and power must be applied sequentially to these wires, in the right order, for rotation to occur. Reverse the sequence, and the motor generally turns backwards. Examples of such motors are the stepper motors in your inkjet printer that control the print head and the paper feed. They stop, go and reverse with great precision. Such motors require a controller, which dictates the speed, number of turns and direction, as well as a driver, which uses this information to switch and modulate the larger current loads required to power a motor.

This is distinctly different than another class of motor often used for similar robot-like functions, the servo motor, which has an on-board sensor that reports back to the controller on the motor’s revolutions. These are often a modified form of standard, old-school, free-running DC motors, whose speed is typically voltage dependent and can run backwards by reversing the single pair of power leads. (like your cordless drill) Such motors are generally fairly high speed and geared down greatly, resulting in high torque, quick speed changes, and good accuracy down-line. For example, a motor with a 60 to 1 gear reduction, if halted within a specific motor turn, would have the resulting (geared down) shaft showing a resolution of a sixtieth of a revolution, like minutes of a clock.     

I might add one more thing about AC and DC motors, which is that brushless DC motors, since they require fluctuating current to run, could also be called AC motors. After all, the drivers are basically causing current to alternate, even if it is not at all like what comes out of the wall. I have seen some electric car motors described as “AC” even though they clearly run on batteries. Alas, we live in complicated times! 

Both AC and DC motors have been standardized for years, having side or end-mount enclosures in many sizes with predictable bolting patterns. There is a vast business of accessories for these motors, especially gearboxes, since standard motors need to run at fairly high speeds to be efficient. The advent of cheap computing, however, has opened the door to many special-purpose designs, although these tend to be comparatively expensive. The most common trait of these hybrid newcomers is their ability to change direction and speed “on the fly,” so as to enable direct-drive devices that are unencumbered by bulky, complex and inefficient mechanical transmission hardware. A good example is the “torque motor” in which a ring rotates within a larger ring, or multi-pole designs, made to hold position as well as rotate, much like stepper motors.

One such hybrid is the hub motor I designed for myexperimental bogie.  (As mentioned when posted previously, go to minute 5.5 to skip the explanation and just see it work!)  As you can see, from the illustration below, I have a new driver, as per the discussion in the last blog. This will control one wheel. Another driver will hang below the crossbar, and that resulting pair will be mirrored on the right side as well. There will be a circuit board that bridges and connects all four drivers, which will be the controller. For what it is worth, I have an off-the-shelf, postage stamp sized driver that I have yet to get working. If I had known how many scrapped boards making my own would lead to, I think I would have redoubled those efforts!

 

A main point that I would like to make is that for PRT applications, the drive wheels can be made to turn a certain number of times, or even turn at exact fractions of a rotation, simply by entering a number into the controller. Using my little model as an example, it takes eighty pulses of electricity to make the wheels turn one revolution. One revolution moves the bogie one foot. Therefore, to move the bogie, for example, exactly 7 feet, I need to supply exactly 560 pulses. (7 x 80 =560) I will refer to such a motor system as digital, for lack of a better term.  

This illustration shows how I would program the controller to make my model bogie travel that seven ft. before stopping, and how I would make this occur in exactly eight seconds, with ramped acceleration and deceleration.  There are 16 lines, each taking a half of a second to complete. That’s where the 8 seconds comes from. The shortest wavelengths, (all of those in the middle) are 10 milliseconds each. Each time a wave crests, my little wheel turns 1/80^th of a turn, so you can see it holds top speed through the middle of this 8 second move.

Clearly this is a much different paradigm than with motors that “free-run.” Free-running systems (including the internal combustion engine) need to continually check their situation to know what to do. This illustrates the difficulty in adapting some existing hardware, such as golf cart or motorized scooter motors, to PRT use. These systems are designed for a human driver, who decides when and how to apply the accelerator or brakes until a destination has been reached. Emulating human senses and reasoning is an overly cumbersome basis for automating vehicles in the controlled environment of an enclosed track, although this approach has merit for emergency situations.  Even servo motors, without emulating human control, basically take analog data (rotational velocity and position) and digitize it, analyze it, then use that digital data to adjust the voltage. (back to analog) That is a lot to have going on, especially multiplied by all of the vehicles in a PRT system, yet even that is not my principle objection. I don’t like the fact that such systems are reactive by design. When you apply the brakes, it is a reaction to your vehicle going too fast. When you step on the gas, it is a reaction to your vehicle going too slow. Why not just do it exactly right in the first place? We want PRT to run like clockwork, and clocks are accurate because the various wheels inside are kept in check by the immutable meshing of gears, not because the second hand decides to apply the brakes because it is moving too fast for the minute hand! What kind of a clock would that be? Sure, these days we can check things a thousand times a second. But it is still reactive - adjusting for sub-optimal conditions. What is worse is that it suggests that were such a system to malfunction, a runaway or stall condition could occur, much like a human driver who is asleep at the wheel.

   

Of course even with a fully digital system, where every trip can be reduced to simply counting down a predetermined number of pulses, some feedback is still essential. Tire wear or under-inflation, for example, will reduce the diameter of a wheel, making it travel slightly less on the same number of pulses. Even in an enclosed track, the possibility of slipping should be considered. Clearly the system still needs to check and adjust the count periodically so as to prevent a vehicle from over or under-shooting its target. This process is very much like the servo motors mentioned above, except that a servo motor checks its rotational progress, whereas I would suggest checking linear progress against the track, which is, after all, what really counts.

One very important difference between this and free-running systems is the unbreakable relationship between time and distance from a control point of view. On a purely digital system, there is set number of pulses that must be sent to the motors for a given distance, and that never changes, no matter the speed. The vehicle can slow for switches and tight turns, speed up where possible, yet the number of pulses will remain the same, and adding up the time between wave crests always gives the exact arrival time. This is not just true to the destination, but to every turn, switch or marker along the way. This allows us to do away with the traditional notion of “line speed” - an outdated idea that means that the entire system can only run as fast as is practical on its slowest corner. With a digital system, there is no such thing as a runaway condition. All movement is the result of pulses that are counting to a finite number, and those pulses (and therefore the trip) will end at an exact time, down to the millisecond. All maneuvers are programmed in advance, so each trip can be optimized, turn by turn, for comfort and speed. Whether organized as whole trips or as trip segments, travel is reduced to “playing” a digital file in real-time, like listening to an MP3.    

This architecture creates a very simple basis for traffic management. Since each vehicle knows exactly how long it takes to arrive at each merge point on its journey and this information can be made available system-wide, vehicle itineraries can be synchronized to avoid conflicts.  For only a few hundred vehicles and a few dozen stations, merge-point collisions could be avoided with nothing more than a few seconds of departure delay. For larger systems, alternative versions for segments of the journey can be substituted, bumping the timing by a few seconds faster or slower. For the largest and busiest systems, of course, a high degree of coordination in real time may be required to manage heavy traffic. This architecture, I believe, has advantages for this as well, being highly compatible with autonomous and group decision-making as well as centralized or regional control. The ultimate control system would undoubtedly be some hierarchical combination of all four and could even include a fifth, that being mid-trip passenger input. (“That’s the place! Circle around to the station that we just passed!”)

In summary, there is a correspondence between distances traveled and wheel rotations and the progress of those rotations, in turn, is the result of a real-time streaming digital signal, similar to, say, playing a music file. Therefore any particular trip (or trip segment) that a PRT vehicle might take can be optimally executed just like playing a song that makes the motor run to its beat. Within that file are points in time/space where merges will occur, just like there are predicable points in a song where a particular instrument comes in. To propose to depart from a station at any given second is to propose to reserve those merge points at very specific moments in the future. Such a direct correspondence between execution of code and PRT vehicle position allows a huge amount of flexibility in terms of traffic management, wherein all kinds of innovative ways can be found, on the software level, to crowd more vehicles into an ever expanding system safely. The key is to abandon the free-running paradigm in favor of one where track position, time and wheel rotations are kept in tight sync with whatever “tune” (trip) the passenger chooses to play. Necessary variations are accomplished by substituting pre-written code snippets in what is essentially an editing program. Both number of waves (distance, position on track) and wavelength (speed) can be edited separately and executed on the fly, preferably by prescribed increments for simplicity’s sake, but few real-time calculations and minimal communications are required for good performance on systems that involve only a few hundred vehicles.    

Although this all may seem like a great leap, it should be noted that ALL motors already have an internal drumbeat that corresponds to the motor’s rotational position, since pulsing the motor’s windings is what makes that rotation advance. Therefore all vehicular movement, be it advancing by a car-length within a station or a 10 minute journey across town, is accomplished by providing this rhythm, even though that rhythm may have, in the past, been simply regarded as a byproduct, like the growl of a Harley winding out. The age of computers has merely provided us a way to count and control those pulses in the pursuit of perfectly replicable movement.  Play it again, Sam!