summaryrefslogtreecommitdiff log msg author committer range
path: root/ImuCalcs.mdwn
blob: 4301db7be93fd440254108c057c72f5825df2a0e (plain)
 ```1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 ``` ``````## IMU Calculations Page ---- **General Outline:** We'd like to functionalize the IMU calculation code so that: - You don't have to worry about how we call the routine - You don't have to bother with the strange data flow in our system (CAN messages, etc.). - Your calculation routine is more modular and doesn't depend on the implementation of the IMU. This means we want to be able to call your routine like a function everytime we get an inertial data packet from the IMU. The call would look something like: (Xpos,Ypos,Zpos,Roll,Pitch,Yaw) = IMUCalc (Xacc,Yacc,Zacc,Rollrate,Pitchrate,Yawrate); Your routine - IMUCalc or whatever you'd like to call it - uses the inertial data to calculate position and attitude and then returns that data. Right this makes sense actually I've created a struct called INS\_Data\_Type: //INS Data Type struct INS_Data_Type{ double pos_X; double pos_Y; double pos_Z; double vel_X; double vel_Y; double vel_Z; double Roll; double Pitch; double Yaw; } INS_Data,Init_Data; _Excellent. We'll use that._ ---- **Calibration Issues:** For the September launch, our sensors will need to be slope and offset adjusted for each sample. For this I assume you mean normalized, i.e. corrected for misalignment? Misalignment errors are a factor, however are secondary to getting things working. Once the software runs, we can perform correction rotations to compensate for misalignment etc. _Sorry that wasn't clear. I meant calibrate the data coming in via scaling it and offsetting the raw sensor data. Don't worry about this - we're going to handle all of the "preprocessing" on the raw data so that all you get is the inertial data._ In the future, we'll have a routine where we use a local averaging method on a multi-megabyte calinration data set to get a best estimate of the actual inertial state... but that's _after_ the 9/29 launch, unfortunately. In order to keep the IMU calculations independent of the calibration/scaling/adjustment methods we use, I think we should keep those routines out of the inertial calculation and hand you a "cleaned-up" data set: This means giving you accelerometer values in g's and the gyro data in rad/sec. Either way works for me, just let me know. It may be easier for you to send me data in g's and in rad/s or deg/s (let me know rads or degs?) _Right now we're planning on giving you linear acceleration in m/s^2 and rotational velocity in rad/s._ I assume, until otherwise told, that we should be using double precision floating point numbers. yes double precision. That's what, 64-bits? that should be plenty, although a long double can be used if necesary (I doubt it). _I don't think 64bits is lowering our standards any ;)_ ---- **Sampling Rate Issues:** Our sampling rates are:
X,Y,Z Accelerometers 2.5Ksps
Roll, Pitch and Yaw rate gyros 833sps(2.5ksps/3)
Axis Direction
Positive Z Up, Perpendicular to the tangent plane of Earth's Surface and the point of launch
Positive X East, but along a plane tangent to Earth's Surface
Positive Y North, but along a plane tangent to Earth's Surface
** Body Frame ** This is a bit more flexible and dependant on your INS configuration and mounting
Positive Z Out of the nose cone
Positive X/Y Pick a side (doesn't matter at all)
Either way, I need to know how the group wants to define these in order to perform the appropriate rotations. _Whoops! I forgot to upload our coordinate system. It's very close to your's: essentiall the same for the rocket but a little different for our reference frame. Check out the [[InertialMeasurementUnit]] page for the coordinate system information._ [[coordinates.PDF]] (Rotation Matrices)
- [[INS.c]]: IMU Calculation C code - [[numerical.pdf]]: Numerical Methods ``````