Hacker News Reader

Comment by DigitalJack | Hacker News Reader

That this is a problem is just ridiculous. It's on freaking rails! There is absolutely no excuse for this. GPS, Inertial Nav, simply integrating speed over time, it should be absolutely dead simple to calculate exactly where the train is at all times.

The article mentioned crap like differential GPS. Completely unnecessary. You don't need to be that accurate, I mean good grief, +/- 100 feet would be just fine for dealing with such gross overspeed detection.

I can't believe this is actually a problem. Pure politics/bureaucracy. It's certainly not a technical problem.

View on HN

You don't even need GPS, or an external signal at all. All you need is an odometer.

1) Engineer selects the train's starting position (the station and departure gate) and selects the route.

2) Train software presses the equivalent of a 'trip reset' button that our cars have had forever. Current Position = 0.0

3) The train and the engineer each program a maximum speed. The train determines the maximum speed by selecting the maxSpeed which has the highest Position less than currentPosition. The engineer determines the maximum speed as she normally would.

4) The train's speed must not exceed the lower of the two configured maximum speeds.

And you don’t even need mechanical connection. Just a simple over speed alarm would seem to help.

> simply integrating speed over time

This probably runs into issues with accumulated error, especially if the error in speed measurement has a serial correlation.

That’s what sensor fusion is for.

That said, inertial nav can take a plane across the country without correction and get within sight of the target.

I think integrating actual speed while on rails would be vastly more accurate.

And really, it just need to augment gps.

Sure, sensor fusion sounds reasonable. My mistake, I thought you were referring to GPS and speed integration as separate options.

Are you trying to reinvent already outdated ETCS level 2?

I'm not inventing anything.

And why would it be outdated if it works, and we (US) aren't using it.

> probably runs into issues with accumulated error

Typically there's no single nor double integration required for a wheeled ground vehicle; distance (revolutions times wheel circumference) is the primary measurement, with speed being trivially computed from that plus an accurate clock.

That assumes there's insignificant slippage between the wheel and ground. A reasonable assumption for a rubber tire on a concrete road, with a 20 sq. in. contact patch. Less reasonable for steel on steel with a 2 sq. in. contact patch.

I certainly agree that there are still errors, wheel slip being a major one. However, that does not cause an accumulating/ever-compounding error in speed nor distance travelled in the way that, say, a one-time error from an IMU's accelerometer does.

The lack-of-integration common in wheeled ground vehicles is highly beneficial to long-term speed & distance accuracy; it's a main reason why odometers were accurate for literally thousands of years prior to anyone knowing how to build an equally-accurate aircraft/spacecraft IMU. (The Romans were able to achieve <0.5% errors over hundreds of miles by the first century AD, something that no aircraft IMU was consistently able to achieve until after WWII).

Reply on news.ycombinator.com