3 ms·
> The cars have to receive power from someplace. Wherever they are being energized, there is by definition a complete circuit to all cars being powered on that
by inferiorhuman 8y ago
> The cars have to receive power from someplace. Wherever they are being energized, there is by definition a complete circuit to all cars being powered on that line.
Most, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail.
> Likewise, wherever the cars are, there is going to be a large and reasonably well-defined impedance discontinuity on the power rail.
Nope. See Bill Wattenburg's demonstration with BART.
> Wind a few turns of wire around the cable that feeds the third rail, inject a pulse train with Gold codes or something similar that lends itself to autocorrelation methods, and listen for echoes.
What if you're not using a third rail?
Basically you seem to have solved the problem under ideal circumstances but not accounted for the myriad of failure modes one will encounter in the real world.
Edit: the other part you're missing is that the first C in CBTC is communication. Locating trains has been fairly well solved (inductive loops, axle counters, etc), communication as well is pretty well solved (802.11 in some cases). The secret sauce is in making everything reliable (think about it, the difference between 3 and 5 nines is a ton of pissed off commutere) AND in making sure everything behaves safely and in a predictable manner.
In more traditional automatic train control setups you divide the track into fixed segments (blocks). One train can occupy a block at a time. Depending on the size of the blocks you may have to keep a block or two of separation between trains. CBTC typically implies what's called moving block. Basically the train is the block. So now you've gotta keep track of all the trains, how fast they're going, how fast they're capable of braking, etc, etc. in order to determine safe spacing and speed limits. It's a bit like automated driving. The algorithms are the secret sauce, and bugs can be fatal. SF's Muni famously had some trains go down the wrong track in the wrong direction during first stages of their CBTC deployment.
- CamperBob2 8y agoMost, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail. In which case you can assume the cars on those segments are pretty much right where you left them, no? I'm assuming the name of the game is to optimize speed and spacing of cars on active segments. Or do you mean the cars are basically coasting between segments under flywheel or battery power? Seems like dead reckoning is all that's needed to fill in those gaps. Maybe with a basic anticollision radar as a failsafe. :) Nope. See Bill Wattenburg's demonstration with BART I'm not familiar with him, and Google isn't helping much. Any good references? It's a bit like automated driving. Except there's no steering wheel, no pedestrians or cyclists, no weather or visibility problems, no uncontrolled vehicle traffic, and every bit of infrastructure is under your control at all times. Hence my use of 'trivial' to describe the problem. Compared to what the folks at Waymo or Cruise have to deal with, the MTA and its contractors have no excuses whatsoever.
- inferiorhuman 8y ago> Or do you mean the cars are basically coasting between segments under flywheel or battery power? Seems like dead reckoning is all that's needed to fill in those gaps. Maybe with a basic anticollision radar as a failsafe. :) Assuming that the train hasn't failed, sped up, derailed, or found another reason to go into an emergency stop. You could make all sorts of assumptions but people typically like their train control systems to fail safe. > I'm not familiar with him, and Google isn't helping much. Any good references? Literally the first thing that comes up for "bill wattenburg bart" sums up the experiment pretty well. > Except there's no steering wheel True. > no pedestrians or cyclists On a subway? Jumpers or aggressors. On at-grade systems? Cars, bicyclists, pedestrians, wildlife, you name it you'll see it on the tracks. > no weather or visibility problems Weather is a huge issue for BART even underground, and I'd assume that goes more for the New York MTA. Weather is less of an issue now for Muni, but some of the equipment used to mitigate the weather routinely damages the train control equipment. If you're expanding your scope to longer distance rail traffic, look up what British Rail called "the wrong kind of snow". > no uncontrolled vehicle traffic You'd be surprised what a drunk driver is capable of. > and every bit of infrastructure is under your control at all times. Ideally. New York is an interesting mishmash of territorial pissing though. See also: Penn Station.
- CamperBob2 8y agoTo be clear, the scope of my comment is the problem described in the video. I literally know nothing about the details. I didn't understand the problem statement to encompass the incursion of snow, drunk drivers, or cyclists into the subway system, and I don't have any specific ideas on implementing a PTC-like system on a wide-area rail network. BART has a lot of surface coverage, so yes, I agree that many of those issues can't be hand-waved away in that case. But a municipal subway is, well, a municipal subway. The problem being discussed here is scheduling and tracking, not collision avoidance, obstacle sensing, or any of that other stuff. They are complaining that they can't implement rolling block scheduling because they don't know where their cars are or how fast they're going, and they're saying they need to spend an absurd amount of money to remedy that situation, and that's what I'm objecting to.