Well, it is “back to the drawing board.” In the course of the continuing debate about dual mode I have started to lean more and more toward the idea that the shape and functionality of the vehicle is secondary to bogie function and design. If the control system is shifted to the bogies, then the vehicles can almost be viewed as simple containers. As such, the main concern is how much they weigh and little else.
Of course there must be some degree of control from the passenger compartment. An emergency “abort trip” command comes to mind. It wasn’t previously so clear to me, though, where the computers and communications equipment would primarily reside and why. In post 56 I raised the possibility of autonomous “engines” that could live within the track and be called upon to boost the speeds of otherwise slower PRT vehicles. Clearly this would require command and control that is sometimes free from the vehicle below. Now I am contemplating taking this idea to its logical conclusion, which is to have a mobile, standardized “skyhook” that can latch onto a passenger compartment. Primary communications and driving functions would be from the bogie, which is only networked to the cab. (Please bear with the simplistic nature of the “hook,” as shown in the illustration. There is a lot to consider design-wise, and I haven’t gotten very far.)
The approach enables multiple, concurrent business models. For example, privately owned vehicles could “hitch a ride” right along with public PRT vehicles. Freight vehicles could be little more than containers with an RFID tag. It also enables some promising schemes that can only be accomplished via privately owned, dual mode vehicles. Since one or two seat vehicles could be robust enough for some general road use without being overly heavy, they could play an important role in a transportation mix. Such small vehicles would not pass ADA compliance rules for public transportation, yet clearly should be encouraged for environmental and energy efficiency reasons. With this scheme they could be developed and sold by vehicle makers directly to individuals.
In another model there could be multiple taxi or limousine fleets. I particularly like the idea of separate business entities competing for the most comfortable fleet of vehicles. “Fit and finish” issues have always been a weakness in public transportation, since there is little competition in the field. By putting the brains into the bogies we simplify the challenge of creating a great, aesthetically pleasing and ergonomic passenger vehicle. This is no simple matter. Modern cars employ assembly lines many miles long to assemble tens of thousands of parts. Since there is so much to it, why not ensure that this part of the project is completely within the core competency of a wide and competitive field of companies?
I do not mean to totally confuse the PRT world with endless choices. But the “last mile” problem is real and not going away, and I doubt the notions of dual mode or private ownership will either. From a design point of view it is a question of “Why not?”
Ultimately, the obvious business model is one of collecting a fee for using the track and the auto-navigating bogies within it. The “chicken and egg” problem would seem to mean that the service would start out as purely public transit, meaning the cabs are “rented” as well. The company responsible for this service would have to keep vehicles clean and in good working order. I would think the cab interior, save the seat cushions, would be bare-bones, of hard, scrubbable materials. A taxi or limousine company, on the other hand, would pay for bogies only, at a discount, and then charge passengers a premium price for riding in cabs fitted for more comfort. Rigorous passenger screening or even memberships would minimize vandalism of the amenities required for a truly luxurious ride.
Privately owned vehicles can be introduced even if they are not dual mode. “Pods” could be centrally garaged, for a fee, and made to arrive at any station upon request. (Failure of the owner himself to arrive on time would have to result in a penalty charge.) Eventually privately owned and garaged dual mode vehicles might appear, but I question how they would compare with regular cars, which themselves might be automated at that point. After all, if that is the case they could simply drop you at a station and go back home. An automated taxi could be waiting for you at your destination. (No, robocars alone CANNOT replace PRT, which is specifically designed for 3D, non-stop travel. Robocars will never be able to get across a city as fast unless they sprout wings!)
But back to the sky hook. A quick look at the illustration above makes another point about the design we have been developing. That is that the swing-arm itself is a fairly complex gizmo, which is a bit troublesome. Seeing it without the vehicle, though, gives a clue about who might want to make it. Below is a gantry robot. I am very glad these things are getting much cheaper, although they are not exactly following Moore’s Law.
In fact, here is a clip of the machine in action. Doesn’t it seem like this system would be a lot more useful if it were untethered? Such an arm connected to a bogie would clearly need to clamp the track for precision positioning, but other than that..
Finally, when I say back to the drawing board, I mean it. Below is an example of how the three-wheel design from the last post might play out. Such a design can “land” on a flat surface like an airplane. The back wheel can be jacked up to pivot the front down creating a front-loading boarding ramp. The wheel size would be dependent on the anticipated use. Were it to remain permanently attached to the bogey, they would be very small. For dual mode they would be replaced with larger, motorized ones, and the maximum passenger weight would have to be restricted accordingly. I figure I might as well share it, because I plan to shift my focus back to the bogey for a while. Chances are it will end up buried deep in the dustbin that is my hard drive, at least in its current form.
6 comments:
The skyhook in the first picture has a long arm. That makes the passenger compartment and cargo container design simple. Alternatively the connecting point between the bogie and the container could be above the current arm. That would allow larger size containers. The point is that some applications might benefit of the free space between the container/compartment and the track (large light weight cargo, standing space for the passengers). There could be also another optional standard interface for connecting the container to the bogie (or the arm to the bogie) above the current arm.
I guess the bogie is able to travel also alone. That would make it possible to request a rented bogie to carry my private vehicle.
The tracks could become comparable to the current road system. In that case maybe there would be no fee for using the track. Maybe one would pay only for the electric power.
Also parking could be pretty much as today, including some parking lots free of charge.
Another approach to the penalty charge in the case that the client fails to enter the vehicle is to simply charge for all traffic. Driving one's own vehicle would cost (about) the same with or without load. At the public stations the vehicle could move back to some available garage again (or move back to the end of the queue, or go back home) after waiting for a while or when the station needs the space for other vehicles. The behaviour of the vehicle could be freely programmable by the user (maybe to optimize garage costs, waiting time), within the rules/limits set by the system/track/stations.
This free programmability also in some sense defines the border line between the software of the bogie and the vehicle. The vehicle may ask for anything, but the bogie only does what is allowed under the rules given by the system. The bogie is also responsible for security. The bogie software has to be correct and verified. The bogie could get its "orders" from the vehicle/driver or alternatively remotely from some external controller (e.g. when the container is just a stupid box with no electronics or when the bogie travels alone).
re: putting most of the control system in the bogie
I guess I just assumed that's what you had in mind all along. As you said, you implied it in your "booster bogie" concept, as well as a few other places.
(My wife would be making ironic comments about now, were she still here to look over my shoulder. She was fond of that old saw, "When you assume, you make"--well, you know the rest.)
About the only additional comment I might make right now would be to suggest you not throw away ALL your design work to date. Moving the controls up to the bogie won't change much about your pod design, after all. And there's a lot to be said for keeping things simple when you can.
The complex "robot-arm" bogie would be more trouble and expense than it was worth for a lot of applications. The public transit contractors, for instance, would have no use for it--they wouldn't be picking up and dropping pods anyway. A lot of your "premium pod clubs" might feel the same way.
In a fully developed system, I think we might have three basic ways of attaching a pod to a bogie:
--something simple, like you have now, for many (perhaps most) applications. Public pods, some premium pods, freight pods that will be unloaded by hand or forklift, and so on.
--something like your preliminary design here, for dual-mode vehicles, properly sized shipping containers, and other applications where quick hookup is worth the extra cost.
--something in between. Say, removable in five to fifteen minutes with proper tools or a properly equipped shop. For premium pod shops that want to quickly swap pods for maintenance or upgrade, for instance, without having to pay for the "super-bogies." Or shipping companies who think manually coupling/uncoupling is less expensive than super-bogie rent.
The bogie itself could be identical for all three types of pod. The only thing different would be the interface--a mechanical connection and a simple electrical hookup for lighting, heating/cooling, battery charging (optional, for electric dualmode vehicles or the like), etc. The controls in the pod could be entirely wireless--you might get away with something not much more complicated than an RFID tag, as you suggested. At most, something like a really secure Bluetooth connection. Maybe a wi-fi router as an amenity for the passengers.
Hope I'm not covering too much of the obvious--I've already assumed too much once...
I think we should be able to agree, though, that even if DM is permitted, dedicated PRT pods ought to be what is used primarily. Accomodating DM shouldn't compromise the effectiveness of the PRT solution, as that is where the major value-added is for PRT.
For instance, most PRT stations won't be able to accommodate DM vehicles unless they fit within the dimensions of pods (including their doors, etc.). I don't think we should compromise on our goals of having flexible stations (ie, fit between floors of a building) to accommodate DM.
Andrew,
Certainly not. Dualmode is primarily a way of letting people access the system before the network reaches them.
The DM vehicles would have to fit in the standard pod's envelope, of course. And they would presumably join the system at a station set up to accomodate them. Dan's system is especcially well set up for that--his ultra-simple ground-level stations are perfect for this sort of thing, for example.
Presumably, you'd drive your "pod-cart" to such a station, pull into a DM lane, and wait for your skyhook. Once it hooks up, you tell it where you want to go. It takes you to the DM-compatible station nearest there. You unhook, park your cart, and--if necessary--stroll back to catch a standard pod to your final destination.
If you were going downtown, or to a really large mall or office complex, you'd probably face at least that much inconvenience finding a parking space and walking to the front door. In a sufficiently crowded urban area you still have a "last quarter-mile problem" anyway.
Standard PRT would be the basis of the system. Dualmode might be good, I think, because would let people start using that system without demanding saturation-level networks everywhere while trying to put the network together in the first place. And let the service providers and the users work out the proper balance.
Options are often a good thing.
Dan the Blogger Responds-
You know, no sooner do you solve one problem than you create another one. If we go for front loading, we need large spaces between waiting pods. Some of the robotic complexity that I have included in the swingarm is the ability to rotate a pod, which enables true (elevator-like) vertical travel capabilities. It also solves that front spacing problem by allowing the pods to angle sideways for boarding, as shown in some earlier drawings of station design. But of course that adds the complexity and cost of one robotic axis with absolutely no use in most other situations. Further complicating the issue is the bogie-to-bogie bumpers I have advocated. I’m not sure how close the cabs can or should get. I guess the bumpers should retract… More complexity!
If you go back to side loading, most door and roof configurations make passengers risk hitting their heads crossing over to the other side, unless the whole front opens up and the floor is supported from the back only. You still have to figure out how to have a ramp or something unless you have a recessed floor section for docking. All in all, I think the front loading, 3 wheel configuration is probably best for our general design. It could have very thin, unpowered wheels, and they must take up the slack in the track to floor (or ground) dimension. It could then “land” and board anywhere.
As for Juho’s point about swingarm length… I would add that we also have to consider that to many people’s sensibilities, the cabs should be “walk-in” with high ceilings. If you have smaller cities where you can cross town in just a couple of minutes at 30 mph, a lot of this extra hardware doesn’t make sense – especially if there is room for gradual sloping track for ground level stations. I have purposely dimensioned the swingarm so that it can be eliminated for such taller vehicles. (that, and considerations of track height based on headroom and fitting between floors of buildings) So clearly the swingarm should be replaceable with alternatives. By the way, were the swingarm a bit longer, I would agree with Rick’s assertion (Jan 20 post, as yet unnumbered) that the servos in the swingarm are unnecessary; Gravity and shocks would do the trick. But then it wouldn’t fit in buildings. So we have complexity.
Dan the Blogger has more!
I agree that the system should not be designed around dual mode. The “chicken and the egg” problem means that this is a lousy way to start, not to mention weight/track cost issues. Dual mode capability, however, is something every station design will or won’t have, so that is something that would need very careful local consideration. I wouldn’t want to bet against dual mode in the long term, though, so I would caution against designing it out. Also, VERY limited dual mode, (like less than a mile and less than 15 mph) could enable door to door service to countless suburban neighborhoods with very little added weight. I don’t know about other parts of the world, but in the US we have lots of subdivisions with limited or no “through” traffic, leaving the streets almost empty. Such vehicles would be essentially unchanged from regular PRT except for detachablity and two small motors. The vehicles need not be privately owned. That being said, I truly believe that much of the advantage to PRT is in being off of the ground, where you can go non-stop. Dual-mode and robocar advocates seem to miss that point. Get too deep into dual mode and next thing you know everyone’s concentrating on street routing. After all, that’s what these transportation guys know!
About the vehicle drawing. One motivation is that the vehicle shape I have been using is a real mess, in terms of mathematical modeling. It must consist of 800 triangles and 500 redundant lines. One thing that we need is to do, to push this thing forward, is realistically show vehicles in action, and there is a great free tool for this in a program called Blender, and I have found out how to import my (easy to create) Sketchup files. The Blender program can smooth shapes and then render and animate them with photographic realism, so I don’t want or need to use a basic model that starts with a million little facets and hidden goofs. Rendering even one picture can take hours, so keeping stuff simple is important. So that, besides the doors and wheels issues, is why I am, behind the scenes, starting from scratch. By the way, don’t expect anything soon. The program is much harder to learn than most and I am lacking both the youth and the free time needed for speedy mastery of it. In fact I haven’t touched it in weeks. Check out “blender animations” in YouTube… Pretty neat stuff!
Post a Comment