Tuesday, December 25, 2012
Well, folks, I thought I would mark the season on a more personal note than usual. I wanted to share with you a small Christmas present I got for myself. This is the motor unit from the cheapest ceiling fan available from Home Depot… $25 USD. I bought this because I am toying with the idea of building a working scale model of the SMART PRT platform. This is something that has been in the back of my mind for a while, but I have always been thinking small – like 1/8th scale. That degree of miniaturization, however, gives little leeway, dimension-wise, and so requires a lot of specialty parts and machine shop work. As I was browsing the internet, looking for useful robot parts, I noticed that most of the affordable components were of a size more suitable for a quarter-scale model. It turns out that if you want to build something like this a good size is the dimensions of a battlebot. The downside is that any track layout won’t be something you can put in the spare bedroom! Nonetheless, I started looking for hub motors that would fit in a 6” wheel. Unfortunately even the ones for bicycle conversion seem to be too big, and not exactly what I would want anyway. I was, however, reminded of various Youtube videos which explain how to make little wind generators out of ceiling fan motors by placing rare earth magnets around the inside of the casing. This is, in essence, also a brushless DC hub motor, and if you rewire the coil leads, it could be given the characteristics of a multi-polar stepper or servo motor. This motor happens to be exactly one quarter scale, if you add a little rubber around the outside for traction.
Anyway, the idea appeals to me, and so I am exploring what it would take… even though the last thing I need is a new project. I have too many ongoing ones already! I must confess, though, that I have drawers full of electromechanical junk that I would like to find a use for and robotics has become an increasingly affordable hobby and one I have always wanted to dabble in. Also, maybe the robotics aspect of this project is something that would attract a whole new crowd. After all, the swing-arm aspect of the design is not all that different from the standard three-axis articulating arm that is standard on industrial robots. There are high school kids making these things nowadays. It can be even be done with Legos.
This is what the motor looks like inside, with the outer inductive ring removed. (The ring pulls the outer case around.) Actually there is quite a lot of space.
Well, I’m not going to rush out and buy the other three fans quite yet. With stuff like this I need to hold off a bit, dip my toes in, and make sure I’m really up for it, or it will just become more junk for my collection. But I really had to at least pop one of these things open to see for myself, and, after all, it IS Christmas… Happy holidays!
Wednesday, December 12, 2012
All PRT is not created equal. That fact benefits some systems (and proposed systems) and penalizes others. The system that has been evolving in this blog sufferers from this effect more than most because it offers a host of subtle benefits that other systems don’t. But it is also, in all fairness, probably the most expensive in terms of vehicle costs. I did not reject these extra expenses for three reasons. First, highly optimized designs can be scaled back to be more affordable, but designs in which affordability is “baked in” cannot generally be so easily supercharged after the fact. Second, manufactured items get cheaper with more volume and over time and a vehicle is such a manufactured item. Third, it is important to understand how system performance is compromised by various tradeoffs. How do you know if dumbing down a system was worth it unless you know what you would have gotten and what it would have cost if you hadn’t?
I could spend the rest of this post extolling the virtues of a multi-axis system but since that is not what this post is about, I will leave it at this: A faster system that can perform tight radius and 3D maneuvers is a system that can be adapted to any city’s landscape much more easily. It provides the absolute minimal amount of track per covered area, maximum flexibility in station design and routing, and the fastest trip time for the passengers. (maximum throughput and highest revenue per vehicle/hour.) Thus what is difficult and expensive from a system development point of view translates into unprecedented advantages from a deployment point of view. It puts the customer, (local city and transit entities) the affected third parties (along the routes) and the passengers first.
I have previously written about the desirability of having standards for PRT. Proprietary track, in particular, seems worrisome because it would permanently lock cities into a relationship with a particular PRT company. I can also see why many people would be very wary of standards, since they are frequently used to gain a competitive advantage (Blu-ray vs. HD DVD) or result in locked-in incompatibilities. (electrical plugs that don’t fit in the sockets in a different country) Isn’t it WAY too early to start thinking about standards? Yes and no. It really depends on what you mean by “standards.”
When a standard becomes legally codified by an organization, given an ISO number etc., that is the last step of a long process. First, there must be some kind of common language – some kind of definition. Whether it is a description of a physical thing or a process, long before it can be defined legally it must be developed into something that can, at least, be discussed coherently.
This point was brought home by a recent discussion on the PRT innovators site. The subject was a project underway using the Vectus system, which is, by any measure, “standard” PRT. But it was revealed that the track configuration was a simple loop, and so it was questioned whether this is a PRT project at all, since “standard” PRT utilizes a network of off-line stations. Is a PRT vehicle, running on PRT track but only in a loop really PRT? Does an offline maintenance building count? Or is it, perhaps, simply unfinished, since PRT is inherently expandable? Another example is ULTra, where the traditionally assumed PRT model of a vehicle on a guiding track has been replaced by a robocar that could presumably free-roam on any paved surface. Is it PRT just because other vehicles and pedestrians are kept off the guideway? PRT as a definable concept is becoming more and more vague. If I say “PRT” and I am thinking of one thing, and you are hearing me and picturing something completely different, we have a problem. Once upon a time, PRT only meant one thing to everybody but the formal definition has become increasingly irrelevant as additional contrasting PRT-like offshoots are added to the picture. At a certain point the discussion needs to shift from the more inclusive “PRT” to those subsets, which themselves need to be better defined. Let’s use the analogy of dogs. Once upon a time, there was only a single general type of dog in a given region of the world and so the word “dog” was sufficient. Over time though, the addition of different breeds added increasing imprecision to the word. Toy Poodles and St. Bernards may both be dogs but making blanket statements about dogs with either as your example is confusing at best. At some point you need to call the breed by name or you are not speaking with clarity. Such informal “standardization” always precedes any type of legally binding definition.
Recently it was suggested that, since PRT has not gotten very far in decades, it is human nature to interpret this as proof that the PRT concept is somehow inherently flawed, so perhaps the name should be abandoned in favor of something new. The term “ATN” (Automated Transit Network) was suggested. Whereas I think the term has merit, I have to point out that it is just as imprecise as “PRT.” It is unfortunate that “PRT,” “Podcar,” “PAT,”“ATN” or even “APM” (Automated People Mover) are such obscure terms. When talking to a layman, first one needs to explain the genus, then one needs to explain the species.
A while back, (post 61) I suggested a shorthand system for classifying PRT. With such a system one could better weigh the pros and cons of the various systems generically. Of course there is no governing body to adopt such a system, and it would only be good for academic discussions between people who had already learned it. But there is a problem, it seems to me, when there is confusion between what is an inherent quality of some whole branch of PRT and what is decided upon by the designers of a specific system. Many people around Heathrow Airport, for example, no doubt believe that PRT is a system of battery powered vehicles. More troublesome is the growing army of people who now believe that PRT systems require winter snow removal. Maybe a downloadable branching -tree type diagram would be a more useful way to start.
The “breed” I personally advocate is a high-speed Suspended, Multi-axis, Automated Rail Transport network. We can shorten that to a SMART network. (or “HS SMART” network?) This clearly is a very specific subgroup of PRT, and establishing definitions and standards for such specific systems is much easier. Hey, I’m doing my part…it has a generic name! Now, how steep (in degrees) do we need to go to be considered “multi-axis?” Some particularly alert readers are already wondering, “Would systems like MISTER or FlyWay considered “SMART?” Whereas Mister could probably be adapted for completely 3D movement, Flyway has another take, which is a scissoring lift. This means the track doesn’t have to follow 3D routing for the actual passenger compartment to do so. The plot thickens!
Unfortunately, “SMART” only goes so far… It does not, for example, describe the power source, switching, or other important considerations. Can this “standardization” make the leap from simple classification to defining certain interfaces, such as between the track and the vehicle, so that they may be described in precise enough language that vehicle makers and track makers don’t need to negotiate each and every detail before they can get on with their respective jobs? With all of the options that have been explored in this blog I am gaining confidence that there is some foundation for developing such standardized interfaces, not as SMART per se, but as some version-numbered subspecies. The trick is not to stifle creativity, innovation, or profitability in third party implementations while also ensuring that the project can’t be easily coopted into a fully proprietary system monopolized by a single company. There is considerable precedent for such “open source” standards in the software field.
As for PRT generally, though, I fear ever more confusion as spin-off and hybrid systems continue to blur the lines. Making the case for PRT has always required a patient audience because it is a synergetic combination of ideas that, if taken separately, are not particularly revolutionary. Unfortunately, limited startup capital forces equally limited implementations of PRT, redefining the technology downward in a quest for affordability. In a perverse reversal of the “divide and conquer” strategy, we divide PRT into so many flavors that it is no longer distinguishable, even to ourselves. Alas, here we stand, like the confused architects of Babel, wondering how to advance, when we cannot understand each other, let alone pass along our vision. Classification, definition, and yes, standardization. It’s all about communication. And so is persuasion. We really need to sit down and assess, in this day and age, what it will take to put our collective best foot forward.
I wish I had the answers. Not only does the quest for affordability put practical PRT designs into a race to the bottom, capability-wise, but the PRT community is very forgiving. After all, this is a needed technology that must be encouraged, right? The problem with this approach is that it doesn’t separate conceptual pipe dreams or inherently handicapped designs from those that are more capable, practical or whose engineering is farther along.
Maybe it’s like politics. Lesser candidates can’t get too deep into specifics or their flawed platform will be revealed, while the better platform, if revealed in too much detail, will only confuse the voters and invite FUD. (Intentionally spread Fear, Uncertainty, Doubt) Better, perhaps, that we do what politicians do, which is hone a simple, more thematic message. We can describe the results, rather than the means, at least when explaining PRT to a newbie. Keep it “back-of-a-business-card” simple. But meanwhile we need to have real answers on the tips of our tongues for those who want detail. We need to be able to recite the generic pros and cons of suspended vs. supported, track based vs. free-roaming, etc. Without some standardized definitions, the weak will continue to pull down the strong, and policy makers will continue to throw up their hands in confusion.
Posted by Dan at 9:12 PM
Saturday, November 24, 2012
I was thinking, the other day, about this blog and how badly it needs a facelift, and I had a realization. The original purpose of the site has essentially been realized. No, I did not succeed in getting a cadre of engineers to anoint and consecrate a set of standardized dimensions under the alter of “open source.” Nonetheless these last few posts represent what is pretty much the closing of a chapter, design-wise. After a rather exhaustive assessment of a variety of issues, it can be said, in most instances, that there is a clear, best way to accomplish a system with the kind of capabilities I have been advocating. I had originally hoped to create some standards for PRT, so that the business would not require a single company to be the expert in vehicle making, station building, track building, route planning , system maintenance, traffic management software, etc., etc. What we have, actually, is a pretty good start in that direction, at least for this one type of PRT. In my last post I outlined a bunch of “pearls of wisdom” that, if followed, outline how the capabilities of a suspended PRT system may be greatly extended.
These principles guide track design and therefore bogie design. Since there is nobody else really trying to push the performance envelope for suspended systems, I guess I’m sort of creating the basis for such standards as I go. What I am advocating is an open standards approach to what I call a “SMART” network. (Suspended Multi-axis Automated Rail Transport) My vision is to create the cheapest, fastest, least intrusive, most versatile, method for “air-lifting” a load from any point A to any point B without actually flying.
At some time in the near future, this site will no longer be about getting recruits to design a better PRT system, but rather about refining and promoting those design decisions that resulted from the work already posted. It took a very long time to do, and there are still plenty of details to nail down, but longtime readers of this site have seen the other parts of this system and know that the current work on the bogie is akin to shaping a keystone – the final piece that must fit in an arrangement of pieces that have been fashioned just for it. Once the essential geometry is set, and the capabilities and limitations are known, it’s detail time… time to design a prototype in earnest. Once again, my apologies to anyone who has just found this site. I’m sure this bogie (which doesn’t even show hardware for hanging a vehicle) must be mystifying. I will soon put the pieces together into a unified system. I promise!
Not that there isn’t a LOT more work to be done here, on this model. Each piece needs to be examined for redundancies, interferences, extra weight and manufacturability. This will take days or weeks, not hours. Still, I think the general design demonstrates that, with the right geometry, extraordinary capabilities can be achieved with a modicum of inexpensive parts. I have had to sacrifice almost nothing in terms of speed, turning radius or climbing, which are over 100 mph, under six feet, and any angle up to 90 degrees, (straight up) respectively.
One thing that is lacking in many PRT and dual mode proposals is a practical way forward. Often concepts are presented that are so early in the research and development stage that only a physicist can tell if they are even feasible, let alone lucrative. Although parts of any complex machine become more specialized over time, presenting it with too many of these one-of-a-kind components too early tends to condemn an otherwise good concept to a life on the drawing board. Since business realities demand that commercial incentive surpasses developmental risk, a budget oriented “proof of concept” design is an invaluable first step.
With this in mind, this bogie design (which is a more evolved embodiment of the ideas expressed in the last post) uses “off-the-shelf” components where possible. The motors for this model are dimensioned from the 7000 watt hub motors from Kelly Controls. Using four adds up to a bit over 39 hp. The upper steering guide wheels are hub motor driven scooter wheels and tires. (13”hubs, from the same source, with Pirelli Diablo tires) The steering guide wheel is designed for continuous contact and the hub motor can be sized up to 6kw, for an additional 8hp. Although this would compare favorably with other systems out there, it would still be a bit underpowered for commuting. Luckily, the main drive wheels are standard low profile automobile hubs and tires (215/35-18) and so the motors can be readily swapped with higher power ones, even up to the monster (80hp per wheel) Protean motors, which would enable performance that would put most sports cars to shame. For climbing standard sprockets are used, drilled for lug nut extensions. The design features truck style emergency air brakes that clamp the track. There are dual (self-diagnostic enabled) steering guide servos that work together but can work singly as long as there is power from either the track or the onboard battery.
In this design the steering guide wheels are not on rocker arms, like in the earlier design. Although the rocker design does seem to offer smoother engagement, this supposed advantage assumes a continuous rail to engage upon. If the steering guide wheels are positioned first, with the contact rails being tapered to make contact after that, this is smoother still.
About the upper steering guide wheels: First, the matter of wear. After all, they are soft rubber, relatively small, constantly engaged, and contacting at an angle. I would first note that tires for scooters and other two wheeled vehicles have heavy sidewalls so that riders can lean into turns, which is an extreme torture test compared to pushing into the smooth steel of the “diamond” guides. With the new (counter-rotating) lower guide wheel geometry and wider drive wheels the forces exerted on the upper wheels is minimal. Also, engagement between the wheel and guides need not be continuous, or at least not under significant pressure. I envision the contact being primarily on the crown of the tire most of time but, unlike scooter use, there is no driver, second rider, or vehicle weight on them. A good finished design will enable the whole wheel to be swapped so that the tires can be changed on a bench instead of on the vehicle. Lastly, the tires are relatively cheap and specialized wheels will eventually evolve. These should be good for well over ten thousand miles as they are. All tires should probably have ribbed or foam reinforcement inserts, giving them the ability to run properly even if deflated. After all, tires are hollow primarily as a cushion against uneven road surfaces, which, of course, does not apply here.
About the emergency brakes – This aspect has had the least amount of thought at this point, but I wanted to explore where the hardware would fit, so I put a crude system in place. The idea is that the lower brake shoes engage first, pulling the bogie into the track and compressing the tires a bit before the upper shoes make contact. We don’t want to have the brakes make the tires lose traction. The brakes are spring activated, and disengaged by compressed air. Another concern is clamping only on one or the other side of the track on switches. As it stands, such a one-sided drag might tend to pull the bogie off course. I am still mulling that one over. The geometry enables some kind of bumper activated system and/or a passenger activated one well.
I know it is very difficult to understand a system from a few pictures, but there is only so much that is worthwhile to show at this point. An exploded view would be helpful, but most of the parts will still be evolving for a while yet. Another issue to consider is that the ordinary way such parts are made on an industrial scale is by punching and stamping. These processes are used to cut out a shape from metal sheet and form it into a 3D shape, which stiffens it in the prescribed manner. This requires huge machines and matching heavy steel male and female surfaces to squeeze the plate between, often at high temperatures. Such a process is impractical for small scale production, so we are left with making everything out of plate and profiled stock, such as tubing or angle steel. This compromises proportions and weight tremendously, and is one reason why I think that such manufacturing should be separate from the PRT business per se. In any case, any designs herein will be constrained by processes that can be done on a small scale, often by hand, but hopefully with shapes also suitable for mass production. I can say from experience that, at a certain point, it is better to simply start making the thing, because the prints inevitably prove themselves short-sighted, and every change creates a ripple effect.
Well, that’s it for now, but for this closing thought. On Thanksgiving morning, on I-10, (the principle southern road across the US) there was a massive pile-up due to fog. Over a hundred cars and trucks were involved, scores were injured and two died. The highway was closed for nine hours. This is a system that seems unworthy of the times, if you ask me. We live in a world awash in cheap sensors and amazing computing power. Yet all of that heavy machinery was being controlled by people blinded by fog and in too much of a hurry to slow down. This is a systemic problem that needs a systemic solution. We need an app for that!