I would like to know if it works on the late evening F train. My understanding is when there is a worker on any track even if the workers are working on a track that is like three tracks away from you, you are still required to drive slowly like almost to a crawl like 10 miles per hour or something. I see in the photos that they’re testing in New York MTA but I am curious how well it works for ridiculously slow moving trains.
(I am not an MTA employee. This is just based on things I have heard and read but I remember something about there being some kind of checkpoints on routes and the MTA would check the speed of the train at the checkpoints to make sure the trains are not speeding or something so like something about trains will deliberately slow down when they approach these checkpoints? Maybe just rumors, I don’t remember the source. The point is the trains speed up and slow down more than I would think they would need to do given they are on a track and no traffic? Also like are the sensors on phones actually decent?)
I did a graduate thesis on accelerometers way back, they’re not very accurate. You can theoretically detect the constant 1g of gravity and thus get a vector normal to it, but if you just have one axis you’re literally lost after a few turns.
How far back? Accelerometers have gotten quite a bit more accurate in recent years, due to consumer applications. I suspect you could get pretty accurate results with multiple accelerometers and watching/recalibrating for drift.
With how accurate accelerometers are with state of the art AR/VR applications, this seems pretty doable. Opinions?
LOL this was decades ago, it was an experimental device that never got produced. The idea was to be able to, say, decline a call by turning the phone over. Ideally you’d be able to answer a call by detecting the move to your ear.
To clarify, what I meant to indicate was that the problem was eventually solved, so apparently the accelerometers are good enough nowadays, disputing the present-tense statement “they’re not very accurate”.
While it’s true it’s been a long time and I haven’t kept up with the tech, I think any improvements have been with software. The device itself was a MEMS device, essentially a tiny beam affected by forces where you measured the deflection. There are inherent physical limits to how accurate such a device can be. You can employ standard QA to find the really accurate parts, but that raises the cost substantially.
In other words, while it’s possible the company in question could have implemented their solution solely using accelerometers, that might have limited the target market to only the most expensive handsets on the market.
If you make a 5 degree error estimating how sharp a turn was, on a train moving 20m/s, you’re losing 100 meters of accuracy each minute.
Consider that the accelerometer moves in your pocket as you shift position; there’s constant small changes to the pitch/yaw.
Modern phones do this (and make it work) to reduce the use of battery-intensive GPS connections, but the errors can accumulate quickly, so they are designed to draw on multiple sources.
You get two things from the accelerometers: magnitude and direction relative to the phone. You can usually figure out that the one with a roughly constant 1g magnitude is down. But then how do you work out direction of travel? Normally you’d use the compass but that tends to give complete nonsense values when you’re inside a metal tube. This seems like a good application for ML, because you can record a bunch of samples of known movements and sensor readings with a bunch of errors and then you’re trying to map sensor readings with a bunch of errors to the closest approximation of one of their known results.
Cars are a lot easier because the size of the wheel is known and so is its angle for turns. You have a sensor that is directly in contact with the ground and which doesn’t slip more than a rounding error (if the car moves more than a metre or so without the wheels rolling, you’ve probably crashed).
I would like to know if it works on the late evening F train. My understanding is when there is a worker on any track even if the workers are working on a track that is like three tracks away from you, you are still required to drive slowly like almost to a crawl like 10 miles per hour or something. I see in the photos that they’re testing in New York MTA but I am curious how well it works for ridiculously slow moving trains.
(I am not an MTA employee. This is just based on things I have heard and read but I remember something about there being some kind of checkpoints on routes and the MTA would check the speed of the train at the checkpoints to make sure the trains are not speeding or something so like something about trains will deliberately slow down when they approach these checkpoints? Maybe just rumors, I don’t remember the source. The point is the trains speed up and slow down more than I would think they would need to do given they are on a track and no traffic? Also like are the sensors on phones actually decent?)
I read the same thing many years ago (2018) so I’m not sure if it’s still applicable but here’s my source. I really liked their visualizations.
https://www.nytimes.com/interactive/2018/05/09/nyregion/subway-crisis-mta-decisions-signals-rules.html
I’ve been wondering how this works! Awesome use of ML.
Wouldn’t it be simpler to “ask” the accelerometer for information? Or is that not reliable enough?
I did a graduate thesis on accelerometers way back, they’re not very accurate. You can theoretically detect the constant 1g of gravity and thus get a vector normal to it, but if you just have one axis you’re literally lost after a few turns.
How far back? Accelerometers have gotten quite a bit more accurate in recent years, due to consumer applications. I suspect you could get pretty accurate results with multiple accelerometers and watching/recalibrating for drift.
With how accurate accelerometers are with state of the art AR/VR applications, this seems pretty doable. Opinions?
LOL this was decades ago, it was an experimental device that never got produced. The idea was to be able to, say, decline a call by turning the phone over. Ideally you’d be able to answer a call by detecting the move to your ear.
IIRC the phone I got a decade ago had that feature, although I didn’t use it.
We’re talking mid to late 90s here. A visionary product, unfortunately never realized.
To clarify, what I meant to indicate was that the problem was eventually solved, so apparently the accelerometers are good enough nowadays, disputing the present-tense statement “they’re not very accurate”.
While it’s true it’s been a long time and I haven’t kept up with the tech, I think any improvements have been with software. The device itself was a MEMS device, essentially a tiny beam affected by forces where you measured the deflection. There are inherent physical limits to how accurate such a device can be. You can employ standard QA to find the really accurate parts, but that raises the cost substantially.
In other words, while it’s possible the company in question could have implemented their solution solely using accelerometers, that might have limited the target market to only the most expensive handsets on the market.
If you make a 5 degree error estimating how sharp a turn was, on a train moving 20m/s, you’re losing 100 meters of accuracy each minute.
Consider that the accelerometer moves in your pocket as you shift position; there’s constant small changes to the pitch/yaw.
Modern phones do this (and make it work) to reduce the use of battery-intensive GPS connections, but the errors can accumulate quickly, so they are designed to draw on multiple sources.
They say in the article that they are using accelerometer, am I missing something?
I was more so getting at multiplying the acceleration (with some rolling average smoothing) by time to get a distance, skipping the whole FFT/ML step.
I thought the same. Feels like using acceleration vectors directly should give you way more information than just detecting the fact on motion from an aggregate. People did that for cars before GPS: https://www.thedrive.com/news/34489/car-navigation-systems-before-gps-were-wonders-of-analog-technology
You get two things from the accelerometers: magnitude and direction relative to the phone. You can usually figure out that the one with a roughly constant 1g magnitude is down. But then how do you work out direction of travel? Normally you’d use the compass but that tends to give complete nonsense values when you’re inside a metal tube. This seems like a good application for ML, because you can record a bunch of samples of known movements and sensor readings with a bunch of errors and then you’re trying to map sensor readings with a bunch of errors to the closest approximation of one of their known results.
Cars are a lot easier because the size of the wheel is known and so is its angle for turns. You have a sensor that is directly in contact with the ground and which doesn’t slip more than a rounding error (if the car moves more than a metre or so without the wheels rolling, you’ve probably crashed).