The ride has temporal variance (ex. sometimes getting from A to B takes 300ms longer)
The carts are driven by a motor on certain parts of the ride (e.g. up a slope). The acceleration should be fairly stable during those parts. Any temporal variation, if not attributed to different acquisition timings, is probably because of aerodynamic factors. For a given ride, that could be temperature of the air (which affects density), number of passengers in the carts (body parts disturbing the flow of air) and direction of wind. With an average speed of 82 mph (~132kmh), the roller coaster advances $\frac{132000m}{3600000ms} \approx 0.03666m/ms$. Therefore, a 300ms variation accounts for a "position error" of $300ms \times 0.03666m/ms = 11m$. Depending on the actual length of the ride, this might be negligible.
In addition to this, you have some jitter on your sampling frequency because the phone's OS doesn't guarantee that it will sample at an absolutely strict frequency.
Phones may have different initial orientations
It doesn't matter, if you subtract the first measurement from subsequent measurements then you have a relative indication rather than an absolute. For example, assuming that the first few measurements of your bearing were [270, 265, 260, 255, . . .] then the series [0, -5, -10, -15, . . .] indicates relative turning.
Phones stay in the subjects' pockets, but jostle a bit
Similarly, compared to the G forces that characterise the turning points in the ride, jostling of a phone in someone's pocket might be negligible. Having your phone tucked snugly in a front pocket is one thing, securing it in a zip pocket of a jacket that might flail about during the ride is another.
Learn the "mean" rollercoaster ride
- as a time series
- as a sequence of significant rollercoaster events
The "mean" roller coaster ride is the average of all available recordings for a given ride, per sensor. There is nothing to "learn" there, the more recordings you have, the closer your average approximates the "average" experience on the ride because you get a number of different accelleration / rotation / bearing samples for each time instance on the ride.
A sequence of "significant roller coaster events" is easy to extract once you have a clear definition of what a "significant roller coaster event" is.
For example, a "significant roller coaster event" might be a sharp drop, or a tight turn. Both of these are characterised by rapid rates of change in the total accelleration of a body on the cart. Therefore, you can derive a total accelleration from your 3D accelerometer as $A_{total}(n) = \sqrt{x(n)^2 + y(n)^2 +z(n)^2}$ and then apply some "event theshold $T_e$ on your $A_{total}(n)$. The indicator function that results from this (some $Z_n = aT_n \ge T_e$) points to some "significant roller coaster event". In the above, $x,y,z$ are the individual components of the accelerometer's measurements. Obviously, it is also possible to combine more than one sensors to extract a "significant roller coaster event".
On a new ride, in real-time, robustly determine where the subject is along the path so we can align music to their experience \m/
Bonus: 3D model the rollercoaster path
You will not be able to extract an accurate 3D model of the roller coaster path from accelerations because it is impossible to do accurate integration of the phone's sensors to a proper 6 DOF inertial nav system. If you want an accurate model of the roller coaster path, simply record GPS coordinates and you have the shape of the ride in 3D in zero time and with minimal data processing.
Tracking where a user is on a given ride is trivial once you have that "average track" signal generated. With that available, tracking a user on the ride is translated to "given a user's "past history" of a few points, where are they likely to be along this specific one dimensional curve?".
So, given that a "random" phone's signals are expected to vary in approximately a given way (the ride's shape), all you have to do is check where they are. You can do this by establishing a Kalman Filter on "position" which monitors current total accelleration and rate of turn. The Kalman will constantly be making a guess of where it should be along the curve and also be correcting this guess with the actual signals it receives from the sensors. You can achieve the same with a particle filter too, arguably with less processing.
Obviously, you can then set markers on the one dimensional curve to trigger your music replay.
Hope this helps.
