4 ms·
Really glad I decided to have a look through my comment history. Not sure when you added the edit, just noticed it now. I forgot to ask - what are you actually
by exikyut 5y ago
Really glad I decided to have a look through my comment history. Not sure when you added the edit, just noticed it now.
I forgot to ask - what are you actually using this for? What's the actual use case? I'm guessing some kind of specific research situation, but I'm curious exactly what.
Thanks for the explanation. So much more goes into this kind of thing than intuition would suggest...
Thanks for having a look at the data too. I recorded some new 35 second samples (at 100Hz, since why not) into a new workspace - but then decided to make things interesting by recording both fast and slow taps :), I'm not sure if this was a bad idea lol
(By all means poke at these too)
If I'm honest (and I think that would probably be most useful here) it's difficult for me to say the model is reasonably more correct now. It still
- oscillates between tap side (and speed)
- doesn't correctly pick out which side a single tap was made on, or makes the correct prediction for 8.4 milliseconds and then rapidly follows it by all other possible predictions :)
- continues to flip through predictions after I stop tapping (possibly because the prediction system examines/averages the entire 5-second classification window?)
- placing my device on a flat surface apparently means "fast right", "left"
- holding my device mostly (say 95%) steady (ie, as little deliberate movement as possible) for several seconds apparently means "right", "left", "fast right", "right", "fast left", "right", "left", "right"... etc
There seem to be occasional spots of consistency, but I can't deny that's probably my brain wanting it to work :P
I'm still learning about sensor analysis and ML, and the above is what my gut instinct says might potentially be most useful to report.
While playing with the system again I had a thought - if you displayed toggle buttons (that showed as
buttons but functioned as radio selectors) for all sample labels during classification, and allowed the user to select which "actual" input they were providing in real time, then recorded the raw sensor data against the user label selection during classification, you could store this recording then repeatedly replay that training data into the model during development and eg show prediction vs user-specified actual input.
Given that model training only seems to take a few seconds (and can perhaps be run on higher-end equipment during development to make the process even faster), such a high-iterative workflow might viably be rerun on every source file save. (On Linux I personally use `inotifywait` for this; for a wall of text on how much I like inotifywait, see also https://news.ycombinator.com/item?id=26555366 https://news.ycombinator.com/item?id=26555366.)
--
On a completely unrelated note, I thought I'd ask: for a while I've wanted to measure my realtime speed on trips on the (...underground...) fastish metro/subway system that was installed a little while ago in NSW Australia. All conventional wisdom I can find universally suggests that using accelerometers is utterly useless for this type of task, but GPS generally needs to see the sky :). I was curious if there are any hacks/workarounds/cute tricks I might be able to use that might not be widely known.