The tumbling behavior of an asymmetric rigid body when spun about its intermediate principal axis is well known, and we have examined this behavior on this site for a book tossed in the air and a T-handle aboard the International Space Station through simulation of their respective equations of motion. We can observe the same tumbling motion by tossing a smartphone in the air, but here we consider an interesting twist: using onboard kinematic measurements collected from the phone during the toss, we wish to reconstruct the motion the phone experienced. Our motion reconstruction analysis relies heavily on the principles of strapdown inertial navigation that we discussed previously.
Modern mobile devices (smartphones, tablets, etc.) are equipped with various sensors that are used in general operation of the devices and in applications such as navigation and gaming. Two very common sensors are the three-axis accelerometer and the three-axis rate gyroscope that comprise a device’s inertial measurement unit (IMU). These sensors provide measurements of specific force (i.e., the difference between the absolute acceleration of the IMU and gravitational acceleration) and angular velocity with respect to their mutually perpendicular axes that corotate with the mobile device. With data analysis in mind, a convenient method for accessing these sensors’ signals is to use MATLAB Mobile. Simply put, using the MATLAB Mobile app on an iOS or Android mobile device, we can set up the device to communicate with MATLAB running on, say, a laptop, which allows us to transmit and record real-time measurements from the device’s three-axis accelerometer and rate gyroscope. In our case, we collected specific force and angular velocity data for an iPhone SE that was tossed roughly vertically in such a way to make it tumble. Figure 1 contains a screenshot of the phone in the MATLAB Mobile app with instantaneous values of the accelerometer and rate gyroscope signals displayed. The data were captured at the highest allowable sampling rate of 100 Hz. For the details of setting up MATLAB Mobile for real-time data collection, we refer the interested reader to MathWorks’ documentation here.
Equations of motion
Referring to Figure 2, the iPhone’s three-axis accelerometer and rate gyroscope provide specific force measurements and angular velocity signals , respectively, with respect to phone-fixed axes aligned with the corotational basis . The illustrated corotational axes are consistent with those specified in MathWorks’ MATLAB Mobile documentation. We locate the position of the phone’s IMU relative to a fixed origin using a set of Cartesian coordinates, , where is the space-fixed basis. The bases and are related by a rotation, which we choose to parameterize using a 3-2-1 set of Euler angles: , , and . Consequently, the forthcoming procedure for reconstructing the phone’s motion from the collected kinematic data closely follows the developments in our previous discussion of strapdown inertial navigation.
We first compute how the phone’s orientation varies when tossed in the air by integrating the following system of differential equations that relate the corotational angular velocity measurements to the rates of change of the 3-2-1 Euler angles , , and :
Notice that system (1) is conveniently already in the first-order form suitable for numerical integration in MATLAB, where the state vector . Next, using the results for , , and from integrating (1), we transform the corotational specific force measurements into space-fixed components, . For a 3-2-1 set of Euler angles, this is accomplished as follows:
We then obtain the IMU’s absolute vertical acceleration by, in principle, subtracting away gravitational acceleration from the vertical specific force component . In practice, because of uncertainty in due to sensor noise, we extract by removing the mean of from the signal:
where the superposed bar denotes the mean value. The lateral specific force components and coincide with the IMU’s absolute lateral accelerations and , respectively. However, because of sensor bias, and might not have zero mean as expected; that is, the signals should closely fluctuate about zero when the phone is stationary, but these fluctuations might instead be offset from zero. Therefore, we take the accelerations to be the specific force signals corrected for sensor bias by subtracting away their respective mean values:
This process of removing the mean is often referred to as zero-centering. Lastly, we perform two successive integrations of each component of absolute acceleration, , to determine the displacement components of the phone’s IMU during the toss:
Simulation and animation
The phone is initially in an unrotated state, and we take the starting location of its IMU to be the origin: and . In addition, the phone is initially at rest before being tossed, and so . The specific force and angular velocity measurements were cropped so that processing of the data for motion reconstruction began just before the toss is initiated; removing the unnecessary measurements leading up to the toss helped alleviate the effect of integration drift. After obtaining the estimates of the phone’s orientation and displacement, we truncated the results to focus on the relevant motion between when the phone is tossed and when it is caught on the way down. The reconstructed motion of the tossed phone is animated in Figure 3.
Overall, the estimated behavior in Figure 3 is quite realistic, especially the tumbling itself, but we observe that the phone’s lateral displacement suffers from some integration drift, particularly in the coordinate. However, this result is far better than the motion we would obtain if we did not zero-center the absolute lateral acceleration components and as we did in (4). For our data, the absolute lateral specific force signal has a small offset of about −0.075 m/s2 that exacerbates the problem of integration drift, but not by much. On the other hand, the bias in is over 20 times larger in magnitude at approximately 1.56 m/s2, which, if not corrected for, results in a lateral motion that is so exaggerated and unrealistic that it is comical. Figure 4 demonstrates how the reconstructed motion is negatively affected when and are not zero-centered.
The animations in Figures 3 and 4 were generated using the MATLAB code provided below. Many thanks to Prithvi Akella for his assistance in developing this code and collecting data.