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!