**Orientation & Position** |[home](index.md.html)|[syllabus](syllabus.md.html)|[assignments](assignments.md.html)|[labs](labs.md.html)|[final project](finalproject.md.html)|[flight data](FlightData.md.html)|[getting certified](RocketryCertification.md.html)| # General Principles See Sections 1 & 2 of [An Introduction to Inertial Navigation][IN] for an overview. The most important concepts are: - There are two principal coordinate systems with which to be concerned. - The _global frame_ which is attached to the Earth. It is considered to be stationary over the time frame of a rocket flight, so we don't have to account for the earth's rotation, Coriolis forces, or the like. - The _body_ or _local frame_ which is attached to the rocket. We assume that this frame is going to be translated and rotated with respect to the global frame. - Our instrumentation is a _strapdown system_ which is rigidly attached to the rocket. - Keeping track of the orientation and position of the rocket in the global frame requires the following steps (see Figure 4 in [Inertial Navigation][IN]): 1. Integrate the rate gyros strapped to the rocket to keep track of the orientation of the rocket in the global frame. 2. Rotate the locally measured acceleration vector from the body frame to the global frame. 3. Correct the acceleration vector for the effects of gravity. 4. Integrate the acceleration vector once to obtain the velocity vector in the global frame. 5. Integrate the velocity vector to obtain the position vector. - Because the inertial sensors have random (and possibly systematic) errors, the integration steps mentioned above result in potentially large errors that grow with time. We need methods to correct or minimize these errors. These techniques are generally known as _sensor fusion_. See Section 8 in [Inertial Navigation][IN] for more information. # Orientation There are two choices for the global coordinate reference frames, NED and ENU, discussed below. Our preferred choice is ENU, but you need to be able to switch back and forth between them. There are four choices for representation of the orientation of one coordinate system with respect to another. They are _Euler angles_, _direction cosines_, _axis-angle_, and _quaternions_. Our preferred choice is quaternions, but you need to be comfortable switching back and forth among them. For reference, Wikipedia has an article summarizing the [four methods](https://en.wikipedia.org/wiki/Rotation_formalisms_in_three_dimensions). ## Global coordinate choices There are two principal choices for the orientation of the global coordinates with respect to the earth's surface. [They are](https://en.wikipedia.org/wiki/Axes_conventions): ### North-East-Down (NED) NED is a right-handed coordinate system where the _x_-axis is North, the _y_-axis is East, and the _z_-axis is down. The advantage of this coordinate system is that the compass headings correspond to a positive rotation about the _z_-axis from the _x_-axis. Most references use compass headings when indicating orientation on the earth's surface. The major disadvantage for rockets is that the launch direction is in the negative _z_-direction. Also altimeters and GPS normally report altitudes above the ground, so they have to be corrected when using NED.The earth's magnetic field vector is normally given in NED. Note, that for an AIM XTRA with local and global _x_-directions aligned in NED, local _y_ is negative global _y_, and local _z_ is negative global _z_. ### East-North-Up (ENU) ENU is a right-handed coordinate system where the _x_-axis is East, the _y_-axis is North, and the _z_-axis is up. The major advantage of ENU is that the hope-for direction of flight for the rocket is in the positive _z_-direction. Also, altimeters and GPS report the correct sign for _z_-axis coordinates. The major disadvantages are that you have to correct any reference that uses compass heading, and the earth's magnetic vector components have to be corrected as well. Note, that for an AIM XTRA with local and global _x_-directions aligned in ENU, local _y_ is positive global _y_, and local _z_ is positive global _z_. To the extent possible, we will use ENU in E178. ## Initial Alignment It's important to get the initial alignment of the rocket on the launch pad correct when using inertial navigation. You want to know how the body-frame is oriented with regard to the global frame. A long-accepted method in the satellite world is the [TRIAD method][TR]. To use it, you need two independent vectors, each measured (or specified) in each of the local and global frames. In our case, the gravity vector and the earth's magnetic vector are the vectors to use. ## Euler Angles Wikipedia has a good discussion of [Euler angles](https://en.wikipedia.org/wiki/Euler_angles). The ones we are principally interested in are the [Tait-Bryan angles](https://en.wikipedia.org/wiki/Euler_angles#Tait-Bryan_angles) in the roll-pitch-yaw (z-x'-y'') (also known as RPY) sequence. In this case, _z_, _x_, and _y_ would correspond to the _z_, _x_, and _y_ of the AIM XTRA. It's worth comparing with the RPY specifications in Open Rocket. See Figure 3.1 (c) of the [Open Rocket technical documentation][OR]. They differ from those on fixed-wing aircraft. Pitch and yaw are virtually interchangeable on a rocket but differ greatly on an airplane. While the Euler angles are traditional in aircraft, they suffer from a problem known as [_gimbal lock_](https://en.wikipedia.org/wiki/Gimbal_lock) and are not suitable for keeping track of the orientation of the rocket. ## Rotation Matrix or Direction Cosines Again, Wikipedia has a reasonably good introduction to [rotation matrices](https://en.wikipedia.org/wiki/Rotation_matrix#In_three_dimensions). Basically, the rotation matrix consists of the direction cosines of each of the principal axes of the one coordinate system expressed in the other coordinate system. Rotation matrices do not suffer from gimbal lock and are suitable for keeping track of the orientation of a rocket. However, there is another method that is computationally more efficient. But first, the axis-angle method. ## Axis-Angle Any rotational transformation from one right-handed orthogonal coordinate system to another right-handed orthogonal coordinate system can be represented as a rotation about a specific vector by a specific angle. Again, Wikipedia has a good [description of it](https://en.wikipedia.org/wiki/Axis–angle_representation). You specify the transform by specifying the direction cosines of the vector and the angle of rotation. For our purposes, it's mainly a stepping stone to quaternions. ## Quaternions There are many ways to envision quaternions. one is as a generalization of complex numbers. You have often used the polar or magnitude-angle representation of a complex number. If you limit yourself to complex numbers of magnitude 1, then the real part is cos $\theta$ and the imaginary part is sin $\theta$. To represent a rotation in 3-space you would need both an axis for the rotation, and an angle of rotation. Let's call the angle $\theta$, and the unit vector of the rotation axis $\vec{u} = u_x\mathbf{i}+u_y\mathbf{j}+u_z\mathbf{k}$. Then we can represent the angle and axis as $$\mathbf{q} = \cos \frac{\theta}{2} + \sin \frac{\theta}{2}(u_x\mathbf{i}+u_y\mathbf{j}+u_z\mathbf{k})$$ where $\mathbf{q}$ is a unit quaternion. The Wikipedia article contains additional information on how to use quaternions to represent coordinate transformations and how to rotate vectors from one coordinate system to another. When implemented properly, quaternions are the most efficient way to transform from the local to the global coordinate system for a rocket. The following paper on [Aircraft Quaternions][AQ] has some practical hints on implementing quaternions. In particular, you'll want to integrate your rate-gyro data using Equation 31, where _p_ is the roll rate, _q_ is the pitch rate, and _r_ is the yaw rate from the rate gyros as far as the paper is concerned. You may want to relabel things, since in a fixed-wing aircraft, the roll axis is the _x_-axis, the _y_-axis is the pitch axis, and the _z_-axis is the yaw axis, whereas we specified the RPY axes as _z_, _x_, _y_ above. When processing your data, you probably want to renormalize your unit quaternions fairly often. While you can use the definition, Equation 93, it is faster to use Equation 97. A useful fact/property of a normalized quaternion is that its inverse is its complement: $$\mathbf{q}^{-1} = \mathbf{q}^* = q_0-(q_x\mathbf{i}+q_y\mathbf{j}+q_z\mathbf{j}) = (q_0, -q_x, -q_y, -q_z)$$. ## Magnetometer Specifying the coordinates of a vector in two different coordinate systems does not provide enough information to uniquely determine the transformation from one to the other (Having the coordinates of _two_ vectors does, see the TRIAD method). However, during ascent, we can usually make some assumptions and work out some calculations. If the rocket remains roughly vertical then you can determine the roll angle (about the AIM _z_-axis) by treating the _x_- and _y_-magentometer signals in quadrature, e.g., $\theta =$ atan2[_y_, _x_]. Then the tilt of the _z_-axis can be calculated as $\phi = \arccos\frac{m_z}{m_{z0}}$. !!! Warning The [Earth's Magnetic Field Calculator](https://www.ngdc.noaa.gov/geomag-web/#igrfwmm) returns the magnetic vector in NED. You'll have to adjust it to ENU. ## Summary of Procedure To determine the orientation of your rocket from liftoff to ejection: 1. Orient your rocket on the pad by using the TRIAD method. 2. Integrate your rate gyro data using Equation 31 in [Aircraft Quaternions][AQ]. 3. Convert your integrated steps to whatever representation is most useful for the rest of the process. 4. Calculate your azimuthal, $\theta$, and elevation $\phi$ angles from the normalized magnetometer data. ## Summary of Ways to Mess Up !!! ERROR: DON'T DO THESE - Mix up NED and ENU. - Use unnormalized/uncalibrated data. - Forget to determine the initial relationship between local and global coordinates. - Mix up the rotation sense of the axes, e.g., is positive rotation clockwise or counterclockwise? - Mix up or be inconsistent on roll, pitch, and yaw. Is roll about _x_ or _z_, etc.? # Acceleration, Velocity, and Position You have three sensors that are useful for determining acceleration, velocity, and position. They are the accelerometers, the pressure altimeter, and the GPS. ## Accelerometers Section 6.2 in [Inertial Navigation][IN] explains things rather well. In short, to process the calibrated acceleration data once you have the processed orientation data: 1. Rotate the locally measured acceleration vector from the body frame to the global frame. 2. Correct the acceleration vector for the effects of gravity. 3. Integrate the acceleration vector once to obtain the velocity vector in the global frame. 4. Integrate the velocity vector to obtain the position vector. The discussion from Module 2 applies here. You have both error propagation from the orientation and from the double integration. The rotation in Step 1 is described in Equations 40, 41, and 42 of [Aircraft Quaternions][AQ]. I have prepared a Mathematica notebook that I actually used in implementing the rotations in MATLAB. The notebook is (here)(MathematicaModels/QuatRotVecAndBack.nb). The MATLAB function is [here](MATLABModels/rotVecToGlob.m). The procedure is to express the body-coordinate acceleration vector (or any vector you want to rotate) as a quaternion with a zero real part, i.e., express the vector, $\vec{a_b} = a_{xb}\mathbf{i_b} + a_{yb}\mathbf{j_b} + a_{zb}\mathbf{k_b}$ as: $$\mathbf{q_{a_b}} = 0 + a_{xb}\mathbf{i_b} + a_{yb}\mathbf{j_b} + a_{zb}\mathbf{k_b} = (0, a_{xb}, a_{yb}, a_{zb}) $$, and then pre-multiply by the rotation quaternion, $\mathbf{q}$ and post-multiply by the conjugate (or inverse) of the rotation quaternion, $\mathbf{q}^*$ $$\mathbf{q_{a_{global}}} = \mathbf{q}\otimes\mathbf{q_{a_b}}\otimes\mathbf{q}^*$$, where $\otimes$ indicates quaternion multiplication. Again, the term-by-term process is in Equations 41 & 42 of [Aircraft Quaternions][AQ], and the Mathematica notebook is [here](MathematicaModels/QuatRotVecAndBack.nb). The MATLAB function is [here](MATLABModels/rotVecToLoc.m). To go back from the body frame to the local frame (for example so you can calculate drag forces from the velocity vector), the order of the quaternion and conjugate are reversed: $$\mathbf{q_{v_b}} = \mathbf{q}^*\otimes\mathbf{q_{v_{global}}}\otimes\mathbf{q}$$, Remember that quaternion multiplication is order specific: $\mathbf{q_1}\otimes\mathbf{q_2}\neq\mathbf{q_2}\otimes\mathbf{q_1}$. The computational advantage of Equations 41 & 42 over rotation matrices is that the quaternion method requires only 24 muliplications and 17 additions, whereas the rotation-matrix method requires 39 multiplications and 21 additions. ## Pressure altimeters The pressure altimeters use the Standard Atmospheric Model to calculate altitude. It assumes that the temperature varies linearly from 0 m MSL to 11,000 m MSL, and that the pressure and density follow a well-known curve. Some worthwhile resources are NASA's [Earth Atmosphere Model](https://www.grc.nasa.gov/www/k-12/airplane/atmosmet.html) and the [Guide to Reference and Standard Atmosphere Models](http://www.spacewx.com/Docs/AIAA_G-003B-2004.pdf) For our purposes, the [model given in the rocket version of E80][SA] is sufficient: $$h = 44,330.770\textrm{ m}\left[1-\left(\frac{P}{101,325\textrm{ Pa}}\right)^{0.19026324}\right]$$ The three things that make the model inaccurate are: 1. The standard lapse rate often isn't the actual lapse rate, and the ground temperature at sea level isn't 288.15K. 2. The atmospheric pressure isn't at the average value. There is either a high pressure region or a low pressure region that causes the recorded pressure to be either higher or lower than expected. 3. The relative or absolute humidity isn't exactly 0. The more humid the air, the less dense. Commercial rocket altimeters usually compensate by calculating the change in altitude, assuming the standard model is correct and just reporting altitude AGL. This reported altitude can have major errors in it. It would be really useful to have an independent measure of altitude (see GPS). A fourth factor that can really mess up an altimeter is compressible flow. If the rocket is doing above Mach 0.5, the pressure measured inside the rocket via the pressure taps can be quite different from the expected pressure. There is a large spike in pressure approaching Mach 1 and then a sudden decrease in pressure at velocities higher than Mach 1. All commercial rocket flight computers have means of detecting the drop passing through Mach and ignoring it. Otherwise, the altimeter would detect apogee at Mach 1. The parachute would eject and be torn to shreds, and possible the rocket as well. You can make corrections for the compressible effects if you have knowledge of the temperature and velocity ## GPS The accuracy of GPS positioning is a complex topic. At one time the government deliberately made civilian GPS less accurate than military GPS. Since May 2000, there has been no difference in the potential accuracy of civilian and military GPS systems. The results today are largely dependent on how much you're willing to spend on your GPS and how clear a view you have of the sky. At both the ROC and FAR launch sites, you have about as clear a view of the sky as you can get. The government commits to broadcasting GPS with a user range error (URE) of $\le7.8\textrm{ m}$ 95% of the time. They usually achieve URE $\le1.0\textrm{ m}$ 95% of the time. See for more details. The more satellites that the GPS can track, the more accurate the position. Normally, if you are tracking 8 or more satellites, your position and altitude should be within about a meter of your true position. So why don't we just use GPS and ignore accelerometers? Well, the government has decreed that GPS units moving faster than 1000 knots and/or above 18,000 m shall cease reporting their location until back under these limits. Search for "COCOM Limits" if you want further details. The practical result is that rocket-borne GPS units lose lock during most of the boost phase, and only reacquire lock near apogee. In addition, it sometimes takes a while until they've acquired enough satellites to provide reliable position information. So we still need the accelerometers and IMU data during boost. However, the GPS can be used to correct the error in the pressure altimeter. The three errors mentioned above, usually provide a linear shift to the _P_ vs. altitude curve. A best-fit line of the pressure altitude versus GPS altitude during descent once the GPS has acquired enough satellites can be used to correct the pressure altitude. It will not affect or correct compressible effects, however. For position changes on the ground from GPS, the following formulas provide reasonable accuracy. Greater accuracy requires an ellipsoidal model of the earth. $$\Delta\mathrm{East} = 110320\mathrm{m}\cdot (°\mathrm{lat}-°\mathrm{lat}_0)\cdot\cos(°\mathrm{lon}_{avg})$$ $$\Delta\mathrm{North} = 110574\mathrm{m}\cdot (°\mathrm{lon}-°\mathrm{lon}_0)$$ # Sensor Fusion Section 8 in [Inertial Navigation][IN] gives a good introduction to sensor fusion. The basic goal is to combine data from different types of sensors to correct for the errors in each one. ## Orientation Rate gyros are very good at giving rotation rates. However, integrating the rate-gyro data always shows random-walk errors and may show bias errors. These errors grow with time, and at sufficiently long times, they completely dominate the signal. Properly calibrated 3-axis magnetometers in the absence of interfering magnetic fields will give very good information about the orientation of the earth's magnetic vector in the body coordinate system, but without further assumptions, they can't be used to determine the transformation between the body and global coordinate systems. Video cameras can be used to make frame-by-frame calculations of the transformation from body to global coordinates, but they require landmarks to be within view of the camera. The trick then, is to use the rate-gyro integration for short times and correct the integration with the magnetometer and video data. ## Acceleration, Velocity, & Position As with the rate gyros, integration of accelerometer data always shows random-walk errors and may show bias errors as well. The integrations are very accurate for short times, but become increasingly inaccurate with time. Altimeters only give information in the vertical direction, and may have errors due to atmospheric conditions and/or velocity. GPS has reasonably good accuracy but usually loses lock during the ascent phase of the flight. Pitot-static tubes can be used to measure forward airspeed. The equations for trans- and supersonic Pitot-static tubes are well known and give reliable results, but only for the forward airspeed. Best would be the ability to use accelerometer data to interpolate between GPS, corrected altimeter, and Pitot-static measurements. ## Methods for Fusing Sensor data In most aerospace applications, the desire is to know the real-time or near-real-time orientation, acceleration, velocity, and position, so a method is needed to provide continuous updates and corrections. By far, the most popular method is the Kalman filter. In our case, we typically post-process the data and use the processed data to determine things such as the C_D versus velocity and the motor thrust curve. The post-processing opens up more processing methods. ### Kalman Filter Kalman filters are state-space based. The typical states are the the orientation (the three independent quaternion components, or the axis and angle components, or the independent rotation matrix components, or the Euler angles), the velocity vector components, and the position vector components. A prediction of the next state is made from a model of the motion that includes estimates of the random variations in the motion. A set of noisy measurements (all measurements are noisy) is made at the next time step, and the prediction and measurement are averaged with a weighting determined by the relative noise levels in each. The weighting is called the Kalman gain. If the model is linear in the states, then linear algebra, or matrix math is used for all of the steps and the processis called a Kalman filter. If the model is non-linear in the states, then the model is locally linearized and the Jacobian is used to calculate the next model step. This version is called an extended Kalman filter. Almost all discussions of Kalman filters are incredibly dense, involving lots of linear algebra. The [Wikipedia article](https://en.wikipedia.org/wiki/Kalman_filter#Overview_of_the_calculation) gives you a general feeling for what level of math density you are facing. [AQ]: PDF/AircraftQuaternions.pdf [IN]: PDF/IntroToInertialNavigation.pdf [TR]: https://en.wikipedia.org/wiki/Triad_method [OR]: https://github.com/openrocket/openrocket/releases/download/OpenRocket_technical_documentation-v13.05/OpenRocket_technical_documentation-v13.05.pdf [SA]: PDF/StandardAtmosphere.pdf