Wednesday, June 25, 2014
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.
Wednesday, April 23, 2014
First of all, thanks for the support in regards to my last post. With everybody seemingly stable, I decided to let my sister “take the wheel” for a couple of weeks so I can unpack my New Hampshire cabin for the summer construction projects, and see how it has fared through the worst winter in recent memory. Unfortunately, I arrived to find snow drifts of up to 4 ft., with 12 hours of shoveling just to get my car to the road. The picture above is my “runabout” Toyota, which I only use on the land, down by my cabin. (Boards on roof with tarp over that, if you are wondering what you are looking at) And that was is April 13th! Then, on April 15th, we got 3 more inches! Now it seems my dad has had another stroke so I am going back to Houston tomorrow. Not that I am getting much done here, although the snow is only patchy now…
This really shows how different this bogie design is than one where wheel-wear is not considered as a primary consideration, usually because of slow anticipated speeds and/or more limited trip distances. Here the diameters/widths are all proportional to service demands. It is not easy to see, but there are four black wheels, in two counter-rotating pairs. The small bottom wheels only engage during switching.
I mention this because this is NOT how to make a small model for running around a track to demonstrate PRT. Designs adapted to the bench top would be much easier, and would look a lot more logical. This is true “to scale”, where the full sized wheel-motors would be about the same size as the wheels of a compact car. Our personal vehicles, I would point out, are real work-horses, when you think about it. Would you want any less for a commercial system? You re-invent the wheel at your own peril!
There is, at least, some upside to such failures. Your attempts get better and better. Along those lines, I thought I might share one other reject that I must say I’m rather proud of.
I’ve been looking around online for the latest techniques for making circuit boards at home. I used to photo-etch, sensitizing my own boards, but my chemicals went bad and are now illegal, leaving me with a lifetime supply of double-sided copper-clad board and no way to sensitize it. Luckily, I stumbled across the “Laser printer iron-on transfer method,” which various people have demonstrated on YouTube, Instructables, etc. Unfortunately my printer is a real cheapo, and the faint, line-ridden output isn’t what these online instructors had in mind, even for the (generally) large, crude boards that they show. One of these days I’ll have to reveal my secret techniques for getting such fine detail! In any case, it shows that all of that time wasn’t completely wasted. Learn by doing!
By the way, since an effective PRT demonstration should have more than one vehicle, I am keeping an eye on ways to mass produce these components. Circuit boards are fairly cheap to have made in quantity, once you know, for sure, that the circuit paths are what you really want. You could waste a whole lot of time and money in the meantime, though, discovering what is wrong with your designs! They still need to be prototyped in the finished form and scale to make them “plug & play.”
So here is where I stand, after all of my misguided efforts. I have now, reluctantly, decided to use 5 Arduino microprocessors per vehicle; one per wheel with a fifth as a controller/clock. In theory I could run all four wheels with a single microprocessor and still have a couple of IO pins to spare, but that limits improvements to the motor drivers, along with other issues. The circuit board above was to run two wheels with one microprocessor, (for 2 or maybe 3 microprocessors per vehicle) since wheels always work in pairs anyway. But the whole left side of the board is for two buffer chips that would have directed that output, and they take as much space as the microprocessor board they would replace. So in the end I am lavishing the system with microprocessors galore. This goes against my grain, as I am sort of fanatical about keeping designs concise. This will, however, do more than ensure that we have plenty of spare IO pins. It will give us four identical driver boards, and a separate microprocessor only for functions like routing and sensing. It is a more physically logical and symmetrical architecture, and it neatly separates the software code into higher and lower functions. Below is the artwork, almost complete, for such a driver, shrunk as small as I can make it. Never mind the “floating”” components… It’s just a screen-shot… This is what I have been working on at night by the wood stove!
Unfortunately, wrapping this iteration up is showing me that there are a number of connection pins that simply won’t fit where I want them. Period. The board cannot be made any bigger and still fit, and the density of the circuit traces is as tight as I can go. So, believe it or not, it’s back to the drawing board yet again! I need to explore modifying this design into a piggy-back design, since I do have room if I build upward. Well, I said this would take a long time, didn’t I?
Posted by Dan at 11:08 PM