20> Podcar Control and Encoders

I’ve been wanting to start a conversation about PRT control for some time, so I thought I would start with this primer on motor control.

I don’t know a whole lot about brushless motors, other than that brushes are the means regular motors use to time the advance the magnetic fields ahead of the advancing rotor. With modern electronics, however, motors do not require mechanical means to achieve this timing. Triggering the magnets electronically offers great precision. Instead of “full-on, full-off”, magnetic forces can be ramped up or down; the motor’s rotation can be advanced or reversed, even held frozen.

Whereas in theory one could always know just where the shaft is, rotation-wise, under load the actual rotations or speed could differ from what is expected. One answer is the optical encoder.

My thanks to ikalogic.com for the logic diagram and shaft encoder pic. I just glanced at the site, but it looks educational. Sorry about the resolution. Click on the image to enlarge it.

The key is the C shaped “electric-eye”. (optocoupler) As holes in the disk align with the beam, a logic pulse is created. In the third picture, I depict how the same principle could be used to inform a PRT system on a pod-car’s position (and speed) along the track.

Some thoughts:
1. The track can be fitted with the PRT equivalent to traffic signs. Unlike drivers, PRT vehicles will follow their instructions to the letter. “Signs” in the track can trigger precise deceleration rates for upcoming turns, acceleration rates for merging, etc.
2. These “traffic signs” can be dynamic, reflecting real-time data.
3. The track itself should also receive data from the PRT vehicles. Track segments can “know” their traffic counts, for example, to upgrade or downgrade their availability factor, for routing decisions. It would seem that the process of merging would be the result of direct cross talk between cars and track.

There’s a lot more to be said about the division of control responsibilities, so I’ll save that for a separate post.

18> PRT Motor-in-the-Wheel Design

This illustration shows how a motor can be mounted inside of a PRT “Pod-Car” wheel.
I was first inspired by a design from an electric “concept car” where the wheels were actually motors. The idea is simple. If you plug in a motor but hold the shaft, it will spin, (winding up the cord until it unplugs itself). So why not feed the cord through the shaft somehow? That way the motor itself would be a wheel, instead of mounting a wheel on the shaft? (Or more likely, a sprocket, gear or pulley) It turns out this idea is actually widely used. A Google search revealed that the concept is commonly employed to move conveyor belts, (drum motors) and to electrify bicycles in China (hub motors) and in fans, especially computer and ceiling fans.

Despite the obvious simplicity (and efficiency) of the idea, apparently the motors don’t perform well in terms of torque, as compared with a much higher speed motor fitted with a reduction gear. Also they are not exactly cheap or easy to find, so I bit the bullet and researched some more conventional motors.

My switching design calls for hard wheels, so I put in a bunch of them to have the traction to climb steep smooth slopes. I don’t really know how many is really optimum, at this point, but I checked out some “NEMA” standard sized brushless motors, and found that the NEMA 42 standard comes with sufficient torque that if each or the wheels had a motor within they could pull (together) with between 300 and 800 lbs. of forward power, while having a top speed of 60 mph. (Sorry, younger and euro readers, I am not natively metric and feeling lazy) Obviously, reducing the top speed increases torque proportionately, but it also worthy to note just how much of a trade-off is required between the weight, the steepness of the climbs and the top speed. There is no free lunch. For example a combined vehicle/payload weight of 1600 lbs. will probably not make a 45-degree climb.

It is also worth noting that the separate motors solve the fact that my system has no differential gears. For those who do not know what a differential gear is, here is a brief explanation – On car, when turning a corner, the outside wheels have further to travel than the inside wheels. Therefore they have to revolve faster, making more revolutions than the inside wheels. The differential gear accommodates this, preventing one or both wheels from slipping on the pavement, which would create wear and partial loss of control. Even though the right and left wheels in my PRT design are fairly close together, the same phenomena would apply to a lesser extent. With separate right and left motors, however, the RPMs of the wheels can be precisely controlled to actually create the appropriate steering forces.