I embrace the “in vehicle” switching philosophy, which is found in designs by J. Edward Anderson and others. I can see little logic for moving the track, as is the case for ordinary trains. This design, however, has generally involved a “bi-stable” guide wheel positioner, wherein one steering guide wheel always remains engaged. This prevents a situation where the vehicle is neither directed left nor right, and so crashes into the middle of splitting tracks. The problem, however, is that if the vehicle is going at high speed, maybe with no turns in sight, the small steering guide wheels end up racing for no reason. An obvious remedy for this is to have the engaging “fin” within the track be discontinuous. That way, one wheel set will still be in the engaged position, for safety, but it will not have any running surface to engage to with, at least when on the straightaway. There is no needless spinning.
In the picture above the running surfaces for the steering guide wheels are shown in blue. Because of expansion and noise, the running surfaces should be finger-jointed and rubber mounted, so making them discontinuous and tapering them into and out of contact position is not a problem. (This detail is not shown)
This results in a different problem, however, also exacerbated by higher speeds. The steering wheels, if not engaged, cease spinning. Then, upon re-engagement, they would have to go from zero to thousands of RPMs in an instant, which would tend to tear them up. They must, therefore, be caused to spin prior to engagement with the running surface, and preferably at exactly the correct speed.
There may be some motor and controller out there what would work, but my guess is that it would be very, very expensive, and way over-built. These wheels need only spin. They don’t actually need to drive anything, even thought the monster shaft size would be consistent with delivering the power of a midsize motorcycle. I say make our own.
The “motor” shown above is a simplification. Additional electromagnets can be added. Now I don’t know a whole lot about digital electronics but I have bread-boarded some simple circuits and I know that if there is a source of pulses (such as the encoders I discuss in post 20) the frequency can be easily manipulated by simple means such as a J-K flip-flop, (a basic building block chip, available on Ebay, for example, for about 20 cents) This output can trigger a $5. solid-state relay and Voila! A simple motor. Again, I am sure someone else could come up with a much more refined design but I think the principle is sound. Maybe I should market this idea to Boeing or Airbus. Ever see how those landing wheels smoke when they hit ground?
15 comments:
Very nice solution. I don't have much to add.
I'm still wondering, though, why angled wheels are better. Maybe I just need to read your last post again.
Nice. I was looking forward to your descriptions of the angled-wheeled bogie, because the first time I saw such a thing (the Bishop Austrans design), I wondered if the design made switching difficult.
It may be too late to market your guide-wheel motor design to Boeing, since you've published it now, unless you've applied for a patent.
Dan The Blogger Responds-
Sorry folks, I got real busy. I try to get a post out every week but sometimes work gets in the way. When it does, hopefully I’ll have a little something that was done earlier. The self-spinning guide wheel pics were drawn months ago, before I even thought of tilting the wheels, the result of practicing the SketchUp (3D modeling) program. Since I had shown this detail in the tilted wheel drawing I decided to make the post about them. The whole tilted wheel concept is pretty involved, especially in regards to tight turns, switching and strong sideways forces. I didn’t have time to figure out how to break it all down. I’ll have more on it next week though.
did you draw the coils using the "follow me" tool?
you'd use Hall sensors?
anderson hasn't gone into detail on this in any publicly-available paper; "Dynamic Analysis of the Switch-Rail Entry Flare." The following papers, developed in 2006, relate to development of PRT and will be made available under contract.
off-topic: something that caught my attention, on page 4 of anderson's safe design paper:
A central computer provides optimum rerouting of empty vehicles, adjusts the line speed for
weather conditions, monitors the flow into stations and at merge points to either delay passengers in origin
stations or reroute traffic as needed, computes system dependability [Anderson, 1992], and gathers data on
system operations.
Current software ecosystems are pretty different from what the early PRT planners had available, or known to them.
One interesting project I've followed is ZeroMQ, which has the nice slogan "Fastest. Messaging. Ever." It's an open source message passing library coming from the banking world. They've originally used it for stock exchange events. Will suit perfectly to PRT, me thinks.
Of course, the idea of delaying passengers at the place of origin is a bad idea. It feels nicer to be on the way, and traffic patterns can change (at least if rerouting during travel is allowed). Also boarding and unboarding times are statistically random - there's only so much a "central" computer can plan for a ride.
What is nice is that we can today build simulations in ways that get very close to the actual needs of a running service. In other words, software implementation can go long before actual hardware is available. Mobile devices are built this way constantly. Applies to PRT as well (on the network level).
No, cmfseattle, actually I downloaded a spring from Google’s 3D warehouse. I think it was made from stacked groups of (4) tilted quarter turns. Those, though, were probably made with the follow-me tool.
Hall sensors are one option. One could pull a signal from the motor controllers, the motor itself, the wheels or the track. That frequency is so important that it would probably be pulled from several places and authenticated against itself for safety reasons. Optical is another option, as long as it is normally on, so it only counts breaks in the beam. It would be cheaper to add millions of beam breaking projections to the track than magnets, for example.
I agree with you, Akuappi. I specifically disagree with the role of a central computer to plan routes or set speeds. I think a central computer should inform but not decide. It is almost a philosophical argument. I like the robustness a parallel computing but with autonomous decision-making. If one part breaks the system just works around the broken part. I like the idea of giving the pods some AI based behaviors as well as a good dose of ESP. The alternative is reliance on very multifaceted software that would get a more complex mission with each additional vehicle.
I really think that it is worth noting where this is all coming from. After all, early iterations began with complete central control. Linear motors were the rage and made it all possible, even with completely dumb vehicles. They would all go at the same speed except to merge. That Aerospace design is almost exactly what Dr. Anderson has been promoting all these years, save for the switching. It is understandable, considering his enormous investment in time and resources, that he would not want to throw out a perfectly good, saleable system without reason, especially to go back to square one.
Just remember, though, what Jeff Goldblum did to the entire alien fleet with an infectious little head code. (Independence Day) You want that happening to 5000 pods?
Dan,
To be fair, computer science has come a long way since 1992. I'm not sure distributed computing and decision-making was as obvious then. It is almost inconceivable these days not to use primarily distributed decision making, at least from a safety and robustness perspective.
Hall sensors, so that the steering guide wheel can be started spinning in the correct direction. if it isn't already spinning, you'll need to know which coil should be energized.
wrt in-vehicle software, anderson's method deliberately limits the amount of info that needs to be passed across the comm line, which in turn keeps the software code simple. even nowadays, small changes to code can entail long (expensive) testing and debugging sessions.
how would the central computer get a more-complex mission with every vehicle? the design approach is similar to that of the guideway: the worst-case scenario (vehicles nose-to-tail) is already known. there is a finite, upper limit to the number of vehicles in any control zone. therefore, it's possible to know how complex the central computer's task will be beforehand.
try designing a flow chart for a program that decides routing and speed; how much info would the program evaluate? how would the info be delivered to the vehicle's computer?
allowing the vehicles to be autonomous would mean that before each diverge point, a given vehicle's computer would re-calculate the optimum route and then inform the zone-control computer which way it'll be going (so that the downstream zone controller can be notified). some zones would be rather short; could the re-calculation be done in time?
I think you are right cmf,.. This IS off-topic, and I really don’t think I could (without hours of searching) lay my hands on the docs describing Anderson’s control architecture even if I did choose to debate the issue just now, though perhaps some other reader might. If you have the link on hand, you might want to post it. This will be a topic of a future post but not for a while. I must say, though, that your arguments seem to generally presuppose that a great deal of Anderson’s control architecture would stay, such as the zone controllers and the notion that speed and routing are calculated from outside and delivered as instructions to the vehicle. Autonomous control means that the vehicles would space themselves, route themselves, and control their own speeds individually (or cooperatively, when in close proximity). There must be real time information sharing but I question the need for external control. I submit that the normal chaos associated with ordinary auto traffic actually would produce a very good result if good drivers simply knew the drive times of the various alternative routes based on real time data. I guess I question the need for a zone controller, but like I said, I don’t even have a definition of it on hand.
Oh, about the wheel revolving in the correct direction- Good call! I once made a homemade stepper-motor controller that would go backwards 20% of the time, much to my dismay. The issue raises some interesting points. Would we ever want it to go backwards? FAST? After all, it is only for preventing wear in high-speed engagement. There is also the issue of ramping up speed. In any case, this is the kind of stuff I’m hoping someone else (who actually knows electronics) will want to run with.
line speed affects control system requirements.
i've been watching old vids from when swedish, french and german high-speed trains were being tested by amtrak. high-speed trains are pretty popular, but their costs are not. so PRT designs capable of energy-hungry (>35mph) speeds could be helpful.
inductrak, using NdFeB magnets, claims a 50:1 lift-to-weight (of the magnets) ratio.
http://www.skytran.net/press/sciam03.htm
maybe use 6-inch steering guidewheels for lower speeds, and fit either the diverge rail or the switch with NdFeB magnets? only high-rpm diverges need the extra cost; the guidewheels could double as a "fail soft"-type backup.
---
Chapter 4, Control Alternatives
Fundamentals of PRT Appendices (p.15)
Control Systems for PRT
A Course of Study in the Simulation and Control of PRT Systems
i'd look carefully at vehicle-guideway comm methods (bandwidth, materials costs).
Thanks for the links,cmf. Once I saw the word "fundamentals" I found my copy right away... This will make for a good post at some point. .
As for the Inductrack, I don't think I would be qualified to even judge it. Until they try it with the laminated aluminum no one can even come close to figuring the cost. I do believe expensive track will kill any large scale adoption of PRT. What I like is it's potential as a magnetic bearing. It would be great for verticle axis wind generators for example. (or the world's most efficient merry-go-round) :o)
In response to aircraft wheels spinning up to speed upon landing, this could be solved simpler by putting a vane on the side of the wheel so the air rushing past spins it up to speed, but since there's strict regulations regarding how often these wheels have to be replaced anyway I'm not sure if it would actually save any money or not =S
That's a very interesting idea, chronokun. I like it a lot. Simple is almost always better. What I particularly like is that all that is required is an aerodynamic fender on one side of the wheel, and the tendency to self-spin is proportional to the speed, and therefore proportional to the need. I will certainly keep this concept in mind in future iterations!
Post a Comment