Here you can see the reflected square as captured by the camera. I have made it off-center to simulate an approaching curve in the track downward and to the left. Because of curves in the track the camera will not always be aimed directly at the leading vehicle. There can even be blind turns, an issue I’ll avoid for now.
In the example above, the pixels 52-55, 62, 65, 72, 75, and 82-85 are activated. It would be a simple matter for the computer to recognize the patterns, since the horizontal lines are characterized by consecutive numbers and the vertical lines are characterized by incrementing by tens. In either case, (up & down or across) the count is four.
In the second picture the longest string of numbers (consecutive or by tens) is three digits, not four. The box is smaller, as it would appear if the lead vehicle were further away.
Here is a nearly blind turn. In this case the only information that the computer can use is that the pixels 30, 40, 50, 60, and 70 are red. The computer would rightly interpret this as a five. Now it is apparent why a chose a hollow square reflector. As long as there is at least one straight line with a beginning and an end, the distance to the lead vehicle can be determined.
The example above is a very primitive, I know, but it would work about the same with a higher resolution system. For example, the lowest resolution “webcam” that I found online was 640 by 480 pixels, about a third of a megapixel. I found a “two-pack” of 1-megapixel cameras for $33. (U.S.)
Consider how such resolution would apply to distance determination. Assuming a bit of edge-blur from the optics of, say, 3 pixels, that would still differentiate over two hundred different sizes/distances. Again, this is with the very least available resolution.
Video is commonly captured at 30 frames per second, so this gives you an idea of the sampling speed. Were a vehicle to be stalled, for example, such sampling would establish a possible problem by the second frame, confirm it by the third, and double check the results by the fourth, activating a braking routine. I would assume that such cameras would also be able to receive track location information as well, perhaps by simple shape or pattern recognition, like a bar code.
13 comments:
So it seems to me that vehicles would have to travel slowly enough through curves that if there is a dead vehicle just out of view in a curve, there remains enough space to safely brake. Since the guideway is fairly narrow, I don't think that translates to much distance (and therefore permissible speed) at all.
So, if this isn't useful for detecting dead vehicles, then I guess it is helpful for maintaining headways on straight portions of track. I suspect that for safety, we'll still need some kind of LIDAR system. The trouble is knowing where to look (when the detector should be looking to the left or the right along a curve and when it should ignore the on-coming vehicle on the parallel guideway).
But you'll be happy to hear that computer vision can do way fancier things than this. Sony has a camera that will capture an image once it's satisfied that the subject(s) of the photo are smiling.
I won't pretend that this stuff isn't the more challenging aspect of PRT. This needs to work really well and not have disastrous failure modes (like a pileup). I'm convinced it's possible, and will certainly be so far before we unleash robocars on our streets.
I agree with what Andrew said, essentially every corner is a 'blind corner' if imaged from inside the track which limits the use measuring following distances (except I think LIDAR would have the same problems), it could still be used for reading barcodes or something but I think a laser barcode reader or some kind of electric or magnetic encoder system would probably be better.
Imo, an accurate track position is all the sensory input that's really neccesary and this could be accomplished for very cheap with a few hall effect sensors and a strip of magnetic grey-codes on the track?
Dan the Blogger responds…
Thanks for your comments, guys. First of all, I’ve got to quit calling it LADAR. It’s just a bad habit. LIDAR! Thanks for correcting me. Anyway…
I envision a primary system that is basically ad hoc roaming wireless LAN networks, with all relevant vehicles constantly reporting their positions and velocities, not only for the benefit of the vehicles directly around them, but also to create an ever-changing network snapshot that is passed along to other sectors of the network as well. Therefore everybody knows what everybody is doing all of the time, although on a far-flung network not all of the information would arrive at each vehicle unsolicited. It would make little sense, for example, to keep updating a vehicle about network details for sectors that the vehicle is moving away from.
The vision system I described is a backup/safety/close-range system. If there is a software glitch or something, we don’t want the whole system to immediately shut down, but rather we want the effected vehicles to get safely to a station. Moreover, even if the system seems to be working, we want to have at least one independent verification means.
The problem of a vehicle being completely dead on the track on a blind corner is one that will certainly require multiple safety systems to resolve. Track-based sensors might be one such system. Also, having a vehicle suddenly “go dark” should not go unnoticed by any following vehicles anyway. They should all immediately slow way down.
There are multiple advantages to having control and communications use ordinary protocols and equipment, but a lot of this stuff has glitches once in a while. Rather than one “can’t fail” system, I would favor layers of 99.5% reliable systems that must agree before allowing full speed. My assumption is that these systems would reach higher reliability in the future.
I think camera based optical recognition may be more straightforward, more reliable and cheaper than LIDAR and bar code readers. The reasons for these technologies being laser based don’t apply to the inside of the track. Also they are generally tweaked for their application. For example, bar code readers often require more than one pass to work but the tags are very small or at an angle. We could use tags as big as dinner plates with simpler code, but cannot accept not getting a reading reliably. LIDAR is good for picking one object out from a group and finding its range. We can use colors, luminosity, shape. I’m not saying these technologies can’t be tweaked for our purposes, but I think it might be easier to address these issues on the software level only. Also, I didn’t mention Ultrasonic, which is really pretty well suited. Many laser rangefinders and are actually ultrasonic with a laser-aiming device. I believe that these, in combination with optical, would be adequate to allow coupling of bogies into “trains” (see pic in post 56) as well as handle last second emergency (imminent collision) protocols. As for longer headways for higher speeds that’s pretty tricky. Most of this stuff is discussed in posts 75-77.
While I appreciate the creativity here, my feeling is that off the shelf components like LIDAR will be more reliable without adding significantly to cost.
I suspect if you look into it further there are options for LIDAR that involve the use of "helper" panels to boost reliability above that of random object detection.
Not being a LIDAR engineer, I'll still indulge my own creativity here and suggest that if you continue on that rather than a square you use a checkerboard pattern.. like a 3D barcode. A square has the unfortunate side effect of being a not so uncommon shape.. at least in the world of manufactured items and as such the probability of mistaken identity is higher.. which I think is what you're trying to avoid by having a special shape.
A more non-standard pattern is no more difficult for a computer to recognize and size than the square, but will be significantly more unique.
I think the leaky cable and track sensors are still the best primary communication and location sensing systems available. Leaky cables are harder to disrupt via EM jamming, which I consider a greater risk than physically breaking the cable in the track. Track sensors are cheap, reliable and accurate.
Layering however is a fine and excellent idea, especially when the additional layers are low cost. For example adding wireless communications does then require an attacker to do both EM jamming and physically attack the track cable.
I see some wisdom in putting this detector inside the track to seal it in from the elements, but it seems to me there's downsides there that mean you need an out-of-track detector to deal with line of sight.
Dan,
I was reading Anderson's control and safety paper last night, and I have to agree with the design he chose, with segment and intersection controllers sending signals to vehicles through leaky cable. You need a basic level of fault tolerance to reduce the possibility of accidents occuring due to communication interuption or mechanical failure.
Now, we can always layer a more sophisticated control system on top of this, using wireless communication, etc. allowing more sophisticated routing, platooning, etc. than Anderson suggests with his basic asynchronous control. But this control layer should never violate the underlying control system to ensure safety and fault tolerance. This would involve negotiations between segment controllers, vehicles and an overarching network controller on routing, speed, etc. You could likely add safety by informing vehicles at merge points about other vehicles in its vicinity and their planned routes/speed, but this shouldn't be necessary for acceptably safe operation.
In other words, if the more sophisticated, less reliable control system fails, the less sophisticated, more reliable control system can ensure continued safe operation, though perhaps at reduced capacity, speed, etc.
For detecting dead vehicles, what about using beam detectors, track-side, that would detect bogeys. I'm assuming you'd need the receiver to generate a false negative (reports seeing the beam when it does not) for this to be a safety failure. You can check for false negatives by periodically shutting off the emitter. Placing these one per meter should allow for enough redundancy. Unfortunately, this violates the goal of keeping the guideway as simple as possible. I'm also not sure how reliable a beam detector is and how much of a maintenance problem they would pose.
One thing that struck me by the Anderson paper was about the importance of confidence in traction. How did you suggest to guarantee traction in emergency stops? I seem to recall it involved clamping to the guideway with some sort of brake pad. I guess we'd need some sort of position detector to determine whether normal braking friction will be adequate for the stop or whether the emergency brake should be applied.
i think it's important not to make "fail-safe" the goal, but rather "fail-soft." maybe there's a less costly way of achieving this than leaky cables and zone marshals.
there is nothing in Anderson's design that precludes more sophisticated maneuvers than basic slot advance/slip, etc. so it's a good starting point.
Anderson knew that PRT would have to be better and safer than other modes in order to compete.
Dan The Blogger Responds with an epic, multi-part comment...
Hi, Ryan. I, personally, do not favor ANY optical systems out in the weather and visual clutter, LIDAR or otherwise. Here is what the system I outlined might do well. 1. Monitor otherwise known headway distances on straight track. 2. Provide precise spacing information in close quarters, such as in line at a station. 3. Provide precise close quarters spacing feedback for coupling bogies into trains. 4. Give readings from position markers inside the track. 5. Read “traffic signs” inside the track (exit 100 meters, sharp turn 50 meters, etc.) 6. Act as a black box in case of the need for forensics, or “eyes” to inspect the track for breaches. 7. Activate emergency braking and other procedures in the last seconds before an impact.
I see wave-guide based communication as the best backup tool for headway maintenance. For example, here is a possible failsafe for dead vehicles. There is an onboard electromagnetic relay (spring loaded) which vehicle power keeps activated. If the vehicle power stops, the spring returns the relay to a position that activates an “alarm” which runs off of a completely different battery. This alarm is low wattage, and can be kept up for days, but can be “heard” by oncoming vehicles via leaky cable or wave guides.
Also, Perhaps position sensing and reporting should be continuous or nearly so. If vehicles update their position to the following vehicle every car-length that pretty much eliminates the blind corner problem right there. Thanks for challenging my thinking, Ryan. You’ve prompted some very productive contemplation!
Andrew, as cmfseattle knows all too well, I am not a big fan of zone controllers or other wayside methods of traffic control. (A lot of this stuff is debated in posts 75-78) It makes perfect sense in an integrated, holistic sense, and it makes many problems easy to resolve. If I were designing a system that I was going to market and service from top to bottom as Anderson was, I would do the same thing. But that’s like GM also being in charge of proprietary roads, fuels, tires and traffic signals. Sure, it’s better if everything is fine-tuned together in theory. But will anybody buy it? Is it good practice in the big picture? The problem, imho, is that nobody wants a new form of transit provided by a new, untested company. I am, therefore, endeavoring to break the problem up into simpler pieces organizationally. A key to that is keeping the track and stations simple, and to build and maintain them with local contractors. The vehicles, if you ask me, should be a stand-alone business. So who deals with stuff like zone controllers? If there is a problem, say, twenty years into operation, how do you know you have it and who is qualified to fix it? If these things need to exist at all, they need to be simple, modular, replaceable items that someone would want to manufacture and service as a business. Perhaps the payment kiosk people would be interested. Anyway, what we DON’T want is a system that takes a room full of engineers to operate and troubleshoot, with aspects of control overlapping and spread all over the place.
About leaky cable, it’s just a linear antenna. Metal tubing can be sized for radio frequency transmission and slotted to “leak” signals in and out as well. And then there are optical and even acoustic equivalents. It is all pretty cheap stuff and easy to install. We could have all three if we wanted. About the traction issue. Anderson’s design could not completely keep out the weather even though the track is very sheltered. Therefore an occasional ice patch could not be ruled out. With a hanging design we CAN guarantee dry track, as well as even, secure contact because of that fifth hold-down wheel. (I would note that even with braking via linear motor, there is still skidding. It’s just magnetic slipping instead of loss of “stiction”.) Clamping the track is for emergencies only, (I believe Anderson’s design also had this provision) With the cab’s ability to swing forward so passengers are pressed into their seats instead of being thrown out of them, we can clamp very tightly. Also, I favor having a means to have bogie-to-bogie rather than cab-to-cab impact.
One thing I’ve learned about Dr. Anderson’s scholarly papers… All roads lead back to his exact design/product. Like any other engineered system, he starts with a foundation of preferences and priorities and builds from there. Once you accept his foundation, then he will skillfully show you why you have to accept his whole system down to every nut and bolt through flawless logic. I respect his priorities and preferences and the system that it has spawned, and really, really wish some city would give it a try. But I do not fully share them. (those foundational priorities and preferences) After all, he is trying to build a business that provides a product and service (and profit) first. Solving traffic and other world problems can come later, after he gets a foothold within his ideal market niche. I, on the other hand, am interested in a more universally extensible design and business architecture first, so everything that follows is naturally different.
Cmfseattle, I agree. I would add, though, that the leaky cable itself seems (to me) to be great stuff. I see it, or something like it, as possibly the best answer to the getting away from (or at least simplifying) those “zone marshals”. You know, after the last comment to Andrew, I have to wonder just how simple and modular this wayside stuff could be made. I reflexively don’t like it, even though I have not really tried to fix what I don’t like about it. I mean, I could see a simple little box hanging off the track or support post, especially with generic hardware inside. I do not like the specter of a single computer glitch affecting all passing vehicles, however.
About the merging… One thought is to simply have each vehicle calculate its ETA at the merge point way in advance and make a “reservation” for that EXACT time. Once all reservations are known, then all empty time slots are too, so conflict resolution can begin, either slot-by-slot or with larger, group movements. I confess to real worries about rogue vehicles in merges however. If there is one strong case for actual external control of vehicles, merging is it. One collision avoidance maneuver and everyone following must instantly adjust.
I don't see any reason why zone controllers couldn't be mass produced, fairly simple pieces or hardware. Beyond the redundancy aspect, these things ought to be simpler than children's toys.
I definitely agree that proprietary infrastructure makes PRT riskier and less appealing to potential customers. I don't agree that zone controllers, etc. need necessarily be highly proprietary. A simple royalty scheme where the designer received $100 a box wouldn't make much difference in system cost.
Dan said: Solving traffic and other world problems can come later, after he gets a foothold within his ideal market niche. I, on the other hand, am interested in a more universally extensible design and business architecture first, so everything that follows is naturally different.
sounds like a good argument for sticking with roads... but i do agree with your reasoning for distributing PRT work to multiple, independent vendors.
I do not like the specter of a single computer glitch affecting all passing vehicles, however.
a consequence of having a single traffic lane is that a failure should affect all vehicles (up to the previous diverge point).
I also can't think of any reason why zone controllers etc need be highly proprietary or even proprietary at all, they're just a basic computer that does a simple task, they could be fully open-source, infact the whole system could, maybe there's advantages to having proprietary vehicles and perhaps load balancing/route planning but I certainly can't see any advantage in the track design having any form of vendor imposed restrictions.
I also like the leaky cable idea. Does anyone have more exact information of how it works? I know that cell phone networks in tunnels use them, but it would be nice to know how the transfer characteristics in and out are.
Cabinentaxi used some kind of clever leaky antenna approach to keep distances. I don't exactly know how, but it depends on a known damping in dB/m.
Post a Comment