PSAS/ ImuCalcs

IMU Calculations Page

General Outline:

We'd like to functionalize the IMU calculation code so that:

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)

That means for every 1 gyro data packet we'll receive 3 accelerometer data packets. What I suggest we do is to "zero order hold" the gyro data - basically, we'll just copy the gyro data twice more so that your routine gets all 6 sensors at 2.5ksps... it's just that the gyro data will only change every third sample.

Does this make sense, given your routine? Or what would be better?

The easiest thing here is for you to call my routine once you have six samples for each of the sensors. The numerical methods I have developed are based on a 5th order polynomial approximation, therefore six samples. Your current sampling rate is just astronomical as compared to our processing power.

Actually, we may have way to much processing power on board - See the processor specs below. Hmmm. I don't understand what you're fitting, but I'll bug you about detauls of your routine later.

I reccommend taking every nth sample (until you have six for each sensor), where n is some value that gives a sampling rate that can be processed. Once the "buffer" of six samples for each sensors is full with new data, you call one "round" of my INS calc program. This will update the flight data and reset the buffer.

Ok, you got it. We'll collect 6 "samples" of the inertial data and pass it to your routine. I use quotes because we'll average the incoming raw data samples to get down to a reasonable update rate - see below.

LPFing the Input Data or Undersampling the Output Data:

We don't need a fast rate on the position data. We're thinking that 2Hz would be ok, 10Hz would be great, and 100Hz would rock but 2.5kHz is way overboard and will swamp the processor. So how should we handle this? Two immediate options are:

What works better for you?

The first method is best because it allows you to change your update rate and really makes my routines just a workhorse. Again, I think the "buffer" method, where you fill a buffer (at whatever rate you want) and then call my routine when the buffer is full. Keep in mind also that the numerical methods here assume that samples are evenly spaced. Of course methods do exist for unevenly spaced samples, but are better suited for approximating a known function, rather than what we are doing here (at least this is my opinion).

We sample the accelerometers at 2.5KHz (400us) and the gyros at 1/3 that rate at 833Hz (1.2ms). In order to get a reasonable update rate, we're going to average the incoming accelerometer data in clumps of 3 points, which means we'll have raw data packets at 833Hz (1.2ms) at that point. We'll then calibrate them and collect 6 of these packets and pass them to your routine, thus calling your routine at 2.5KHz/3/6 = 138.89Hz (7.2ms). We'll try this rate first, and futz with it when as we have to.

If you want to take the approach of separating the attitude calculation from the position/velocity calculation that's fine; I'll just give you two separate routines to call. This would yield DIFFERENT resolutions for the two. In my work I kept their resolutions the same. I.e. each "round" I updated the attitude and position/velocity.

Let's keep the inertial calcs as one routine; we'll pass you both types of data at once.

As an aside, and without knowing how much else you're actually running on this processor, I don't think it will be difficult to achieve 100 Hz. I got about 94 Hz out of my 40MHz (8-bit, fixed point!) PIC18.

-What are the processor specs?

We're using an 133MHz AMD 586 processor (w/FPU) with 64MB SDRAM and a 128MB FLASH disk - it should give us at least 10MFlops. It's called the "Elan" microcontroller and it's basically a PC on a chip. Checkout the FlightComputer page for more information. We're using Debian Linux, with a real time kernel patch called "RTLinux" for the real time stuff. I think we're going to have plenty of processing power, but we'll see: being conservative about processing power is always a good thing.

Libraries, Code, etc.:

Write everything in ANSI C and try and use only standard libraries like stdio.h and math.h. Since you're only doing the calcs, you won't need all of the strange and twisted (sorry Jamey ;) interprocess communication calls - hopefully this will make it very easy and very fast to code.

Coordinate Frames How do you want to define the Body and Reference/Navigation frames? For now, and for simplicity, I suggest the following:

*Reference Frame *

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)