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.
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/80th 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.
