Rocket IMU thoughts....

[Pbreed]

I've been following the IMU discussions with much interest.
The DCM imu work is very interesting, but it is fairly specific
to aircraft. Even then the GPS assumptions as applied to aircraft have significant faults,
Small UAV's will easily fly as speeds slow enough that the angle between ground tract (Measured by GPS) and actual heading can be significant I would expect the current GPS based DCM system to show weird behaviors when going into the wind with strong winds. A monetary gust could easily make for a 180 reversal in GPS direction with no actual heading change.

The 9dof IMU using magnetic sensors and the Freespace IMU published in Circuit cellar seem to resolve some of these issues by using a magnetic sensor..

My personal interest is in rockets, and while I've had success with Hovering rockets, I want to do some more dynamic stuff wher the "DC" acceleration will be significant.
Toward that End I think the proper no compromises IMU ->AHRS with drift correction scheme is shown below.

This would be the ideal system as it would take into account the turning acceleration that turning planes see and actually do proper correction, so no matter how long you stayed in the turn the roll would not level out. Note that as you turn the E-W N-S portion of velocity is increasing decreasing continuously as you go around the turn. This can be measured by differentiating the GPS velocity, this provides the reference for the increased turn acceleration and the fact that when combined with gravity the effective acceleration is not vertical. Its well determined, but not vertical.

From reviewing the various discussions and code examples on DIYDrones etc...I think I have a pretty good idea how to everything with the exception of the Combine Mag and Acceleration vectors to create reference box.  I took Linear Algebra in 1982 and have not touched it since then. 

Anyone interested in discussing this in detail?
Some General questions/comments:

It looks like both the Freespace and 9DOF IMU code sets basically toss out the vertical component
of the magnetic vector, why? It seems that tossing information is not helpful?

My guess is that there is some delay in the GPS differentiated acceleration, so one should probably delay the accelerometers, and mag sensors reading and current state by a similar amount before doing the corrections. thoughts?

There is no preferred orientation for a rotation vector or quaternion ,yet both code sets seem to assume a specific up down right left iorientaion with respect to the magnetic sensor.
If you are going to use this for a tail sitter that starts out vertical then transitions to horizontal flight
making these assumptions could be disruptive. The IMU I used for my hovering helicopter and rocket, the Microstrain unit allowed on to mount it in any orientation then apply a rotation to the outputs to get the current state.  Can't this be done in the completely general sense so it works for aerobatic
and other needs?

In the next two weeks I'm going to fly a rocket experiment  with
 Spark Fun 9DOF IMU sensor.
 Analog Devices ADIS16400 9DOF sensor.
 Sparkfun new 10Hz GPS module based on Venus 6 Chip set.
 Novatel OEM Star 10Hz receiver. (Or possibly an eclipse 10Hz Crescent I have both)

Depending on how the sensors work under acceleration I will then build some hardware with
the 9DOF sensors on a small board with a 80Mhz Freescale MCF5213 and would be glad to share Netburner Dev tools and a copy of my IMU hardware with anyone with the skills to help work on this.











.

[Tj Bordelon]

"t looks like both the Freespace and 9DOF IMU code sets basically toss out the vertical component
of the magnetic vector, why?"


I recall using Z for a few weeks and tossed it for a few reasons. Firstly, it is hard to get a 100% accurate mag with large magnetic fields nearby, so I don't want to trust it except for yaw. Secondly, because the accels are better at eliminating drift in pitch/roll. I don't want the magnetometer affecting pitch/roll at all. The Freespace algo will do what you are saying if you take out one line "Z=0".

There is no preferred orientation for a rotation vector or quaternion ,yet both code sets seem to assume a specific up down right left iorientaion with respect to the magnetic sensor.

In the article I try and explain this. It's merely the rotation to take vectors in aircraft space into world space. I have not had any issue with this approach.

[Tom Yochum]

Just so you know, the "10 Hz" GPS modules don't actually make 10 measurements each second. They take 2-4 measurements a second and extrapolate the data in between. I doubt differentiating this extrapolated data will give you any meaningful acceleration data.

What you really need is a tightly-coupled GPS/INS system.

[Pbreed]

The low cost 10Hz units from spark fun may not that is why we test,
I have novatel OEMSTAR , Hemisphere crescent, and Trimble BD960 units that do true 10Hz or better..
Take a look at the BD970 from Trimble does 50Hz with 20msec latency.
BD970 Data Sheet
(I have a pair of bd 960 that cost more than 10K)

[Carlito Oliveira]

There is no preferred orientation for a rotation vector or quaternion ,yet both code sets seem to assume a specific up down right left iorientaion with respect to the magnetic sensor.
If you are going to use this for a tail sitter that starts out vertical then transitions to horizontal flight
making these assumptions could be disruptive. The IMU I used for my hovering helicopter and rocket, the Microstrain unit allowed on to mount it in any orientation then apply a rotation to the outputs to get the current state. Can't this be done in the completely general sense so it works for aerobatic
and other needs?

In ideal conditions and for a short period of time the magnetic sensor gives you one static axis relative to the earth, but you need at least 3 points to define a plane and that's why you need to define a mobile coordinate system and a relation with the fixed coordinate system(Earth).

Even thought there's no prefered orientation for the algorithm, the plane or the rocket have one or two(in 3D planes) orientations to provide lift. So you need to specify your set point orientation so that your plane can provide lift.

The drift correction algorithm needs 3 acceletation axis to provide 2 axis correction gains, so if your plane generates lift on the gravity direction suppose Z, you will be able to correct only X and Y rotations but for Z you'll need another sensor (GPS or mag).

Tell us more about the IMU algorithm that you use and please correct me if I'm wrong in something.

Thanks.

[Pbreed]

Clearly you need two non-parallel vectors to specify a reference orientation.
The gravity vector is a pretty good one.
the other can be either GPS heading or Compass heading.

If you look at the free space IMU code you will see that he transforms the 3D magnetic vector into
world space before "killing" the z component. So that is valid in all orientiaons. In the SF9d0f code
They just throw away the z component of the sensor, so if you use it in a device like a tail sitter VTOL
vehicle that then transforms to horizontal flight it will not work.

[Carlito Oliveira]

That's true.

You could even implement a state machine for different flight modes for 3D airplanes and switch the correction axis for each mode.

In my plane I made a initialization routine that uses the only gravity vector to define the planes orientation, once I mounted the board leveled with the wings and parallel to the motor thrust vector.