Roller Coaster Acceleration
Project Background
My family used to take yearly trips to Cedar Point, Ohio, which hosts one of the tallest and fastest roller coasters in the world. The Top Thrill Dragster is a 20-second-long ride that launches riders 420 feet into the air, taking between 3 and 4 seconds to accelerate the train from 0 to its maximum speed of 120 miles per hour right after it starts. The last time that I went there, in 2018, a few of my engineering and physics-oriented friends accompanied me, and we talked a lot about physics-related topics during the trip, including the kinematic effects experienced on roller coasters.
I had the idea at some point to download a 3D accelerometer app to my phone and try to record the acceleration data through the duration of the ride. The app allowed me to export the data as a CSV or “comma separated value” file which I later imported into Excel and performed some smoothing operations on the data to adjust for the sensor noise and jitter caused by the ride to allow me to visualize its acceleration-curve. I created velocity and position curves based on the acceleration data and used boundary conditions to systematically correct the acceleration data as best I could to end up with 0 velocity and acceleration in X, Y and Z directions at the beginning and end of the ride.
I was surprised and excited to find that, using the data I had collected, I could predict a velocity at the end of the initial ramp of the ride, the section during which the car accelerates, to be 120.8742 miles per hour, which has only a 0.73% error from the official value of 120 miles per hour given by Cedar Point. The idea of recording such data in real-life situations intrigued me, and I enjoyed the challenge of manipulating and interpreting it, as well as the apparent accuracy of the results.
Detailed Description
The problem with the data that I realized later while examining it is that the rotation of the phone during the ride made the sensors’ frame of reference fixed relative to me and my orientation rather than to the earth. This makes the graphs produced from the data counter-intuitive for a person examining and trying to understand them. One would expect that the x-direction remains the same cartesian direction relative to the ride through the duration of the recorded data, and the same with y and z directions. However, since the phone, which recorded the data, was experiencing changes in all 6 degrees of freedom in x, y and z translation as well as pitch, yaw and roll, the translation data would need to consider those rotations when they occurred to adjust the acceleration data into a fixed plane of reference relative to the ride and earth.
I have no such rotation data, so if I wished to modify the values used in the graph, I would have to make assumptions about each point in the ride that a major rotational event occurred, its geometry and its duration, then apply a function to adjust the data accordingly. It seems to me that this option would take up a lot of my time but wouldn’t end up producing accurate results, so I decided against it, in favor of trying to simply imagine the accuracy of the data based on the graphs available. For a person who hasn’t experienced the ride themselves it would be difficult to visualize the acceleration and velocity curves of my graphs at the times that they occurred. I have included a video of one of my experiences on the ride which should help with that somewhat.
Acceleration data in the graphs is correct, but a result of the lack of rotation consideration makes the velocity data all highly incorrect. The velocity graphs report that the maximum velocity experienced by the phone was 164.6 miles per hour. Based on the mechanics of the ride, the maximum velocity should occur right as the drive-cable stops pulling the car, which occurs at the end of its 4-second travel up the initial small-incline ramp. This brings the car to 120 miles per hour. After this point it begins its turn to point upwards, causing the phone to record an intense centripetal acceleration peaking at 6.65 Gs, pointing at the center of the arc through which the car is traveling. Note that this centripetal acceleration after the data has been smoothed out only peaks at a more realistic 4.3 Gs.
The centripetal acceleration and any other acceleration normal to the screen of the phone is in the Z direction and is recorded in blue in my graphs. During this curve, the changing cartesian orientation of the phone causes it to actually experience a moderate 1G acceleration in the direction of car travel, the y direction, which is modeled in red on my graphs. One would expect that there would be a negative acceleration in the direction of car travel during this curve because as it rises it trades kinetic energy for gravitational potential energy, and to energy lost as heat due to friction, thus the car slows its speed magnitude. However, I believe that the phone may have been oriented slightly tilted with the earpiece lower to the floor during the ride so that any force experienced normal to the car was recorded mostly by the Z-direction accelerometer, and partially by the Y-direction accelerometer. This most likely came about because the phone was tethered to my non-rigid body at my leg which introduced error in the orientation of the phone relative to the car itself.
Independent of that error, the net acceleration and thus net velocity can still be calculated, but after the curve begins, my velocity graph is no longer accurate with respect to earth because of the phone’s orientation change. A good comparison to make would be one between the car and the extreme case of a satellite in orbit, which experiences a constant acceleration towards earth’s mass center. An accelerometer would read this as a constant normal acceleration downward, even though the satellite’s radial velocity magnitude relative to earth is unchanging due to its orbit. Downward velocity is always 0 (in circular orbit), yet the only acceleration that the satellite observes is downward. If this were interpreted as though the satellite were not in orbit, the downward velocity derived from the acceleration curve would increase indefinitely, which Is not true in reality.
In the case of the coaster, the car’s acceleration during its turn is similar to one of orbit. Although it accelerates only towards the center of the arc, interpreting the phone ‘s Z accelerometer data as if the system were fixed would and did result in a rapid increase in Z velocity that it didn’t really experience. This false change in velocity effectively reports that the maximum velocity of the car is 166 miles per hour, which happens to occur on the graphs directly after the moment when the curve ends, without any additional energy being added to the system after the cable pull.
The takeaway is that the velocity graph may look cool, but it doesn’t actually represent true relative-to-earth velocity, or even the speed of the car, since velocity is relative, and a vector, and would need to consider rotational changes of the car to be correct. The changing frame of reference during and after the first upward curve means that the only accurate part of the velocity graph lies before that event. Luckily, since that data is good, it means the calculation of the maximum speed after accelerating the car is still correct at 120.8742 miles per hour and is still extremely close to the officially released maximum speed of the ride.
After the car curves upward, it begins to slow down as it rises linearly up the vertical hill of the ride, and essentially mirrors this action as it falls down the other side of the hill. This mirrored motion can be fairly clearly seen in the graphs, which is exciting to find as well. I would love to find an app that tracks all three cartesian accelerations as well as rotation, so that I can attempt this experiment again in the future to acquire real velocity and position graphs.
Ride Timeline
