- Joined
- Jan 23, 2009
- Messages
- 5,989
- Reaction score
- 4,097
- but all the integrating is being done onboard by the IMU itself. (Thx Jeff Rowberg!)
Sent from my LGL44VL using Tapatalk
Where's the fun in that?
- but all the integrating is being done onboard by the IMU itself. (Thx Jeff Rowberg!)
Sent from my LGL44VL using Tapatalk
The fun is that I've left the IMU on a table for an hour and got sub-degree drift...
Sent from my LGL44VL using Tapatalk
Turn off the accelerometer drift compensation (which you can't use in a rocket) and see what drift you get.
Think about it - if your drift is a few degrees per hour, or even per minute, then the gyro will still be very accurate within the few seconds between liftoff and 2nd stage ignition. Anything beyond that and all you're doing is figuring out the orientation at apogee - much less useful.
The gyros have unknown cross axis and acceleration sensitivity. How big of a problem is that? Unknown pretty much covers it. Although Jim Jarvis had trouble which pushed him to a spinning fin can.
Drift is the least of your problems.
Great points and well taken. I've looked into the cross-axis / acceleration sensitivity over the past 2 years and decided its not that bad. I have only used the L3GD20H so I can't say anything about other units.
I'm considering just using the difference between the angle at burnout and the angle at liftoff detection as my tilt lockout standard. I'd just store non-rotated orientations and let the secondary data-processing figure out the rest for post-flight analysis. It depends exactly how it's calculated, but I'm guessing that gravity based corrections won't be an option- however, if the IMU only corrects when close to 1G for awhile then it might work. I'll have to research that.
Create several 512 byte arrays. Store your data there and call the SD library to write the data when you have a full 512 byte buffer.Adding to the SD card debate, the Arduino SD library unfortunately doesn't support plain old ints & floats. It does allow byte arrays though, and I should (hopefully) be able to write up a basic function to "split" an int, float, etc. into its constituent bytes. Seems like kind of a pain though... Ah well, 'tis the price you pay for decent write times.
char *bufp;
int data;
*((int *)bufp) = data;
bufp += sizeof(int);
I am using the L3GD20H and I find it excellent. I tried to determine acceleration sensitivity but putting it on shaker table and reading the output and it appears relatively insensitive. My next step is to spin one about an axis and see what the magnitude of cross-axis sensitivity is. I want to do that wirelessly somehow so I don't have to figure out how to wind up the wires.
The 2D-DCM only requires 6 floating point operations, is an order of magnitude faster (maybe two), and can easily be implemented on a ATMega328P. Quaternions are much more computationally intense and require lots of floating point math.
Curious how are you using just a 2D - DCM? Are you ignoring the roll (spin) axis?
I am using quaternions because it has fewer computations and faster than a 3D DCM. However I implementing that on a ARM in integer math.
Thats awesome - I'd love to figure out how to quaternions with integer math.
As for 2D-DCM, I completely stumbled onto it and I'm not totally sure why it works. Here's what I'm doing each cycle, where Z is the vertical axis, and X & Y are parallel to the deck:
Roll += gyroZ * dt
Pitch += gyroY * dt * cos(Roll) + gyroX * dt * sin(Roll)
Yaw += gyroY * dt * sin(Roll) - gyroX * dt * cos(Roll)
Veryi interesting. I wonder if you have tested that with a rocket that has a high roll rate while it has a high yaw and pitch rate?
If the roll rate is low then the small angle assumptions reduces your equations to:
Roll = gz*dt
Pitch = gy*dt
Yaw = gx*dt
which is simply integrating the Euler angles for each time step.
Yes, you are correct that if there's no roll, then my equations break down to what you have above. I look at that too, and call it "naive yaw" and "naive pitch" in my graphs.
Here's one with a high roll rate that still accurately captures the off-vertical at apogee. You'll have to take my word for it because I haven't posted the onboard video.
I do notice more error on the higher roll flights, but its not consistent. Some flights are dead-on, some 30 degrees off at apogee. In either case, its still useful for 2-stage tilt-lockout. In my 50+ flights, it always captures large moves away from vertical. I set my lockout threshold to 35 degrees and have had no trouble.
So I got the prototype altimeter assembled over the last few days. Came out pretty nice:
View attachment 336702View attachment 336703
I first built it without breakout boards and tested it, then added the boards afterward, just in case I needed to fix something.
My comments:
- Several footprints were mis-sized, most significantly the SD breakout. I can work around it but it's annoying enough that I'm going to want new footprints for the first beta run.
- The polarity on the LEDs was very hard to see. I was using Sparkfun's library for these- I'll switch to the Adafruit footprint, which is much clearer, in the future.
- Most of the info text on the back was practically invisible. Easy fix.
- The programming header was set up backwards. I can work around it by just flipping the programmer, it's just not ideal.
- I'm planning on running the entire board at 3.3V with internal clock on the next iteration. I found a high-efficiency version of the 1117 that can run 3.3V off of as little as a 2.5V input, so I can run 1S LiPos- I have quite a few lying around.
- I'm also planning on moving the SD card from a breakout board to a standalone holder. I just need to find one that's reasonable to solder...
- Several bugs in the Arduino library have been worked out- mostly related to the annoying way C handles floats- float x = 1/2 will give zero because the 1/2 part is reading as an int. float x = 1.0/2 fixes it. Still have a lot more to go there.
Two quick polls-
How much interest is there in a beta run once all of these issues are taken care of? OSH Park sells boards by 3's so I'm planning on getting 6- one for myself and if that goes well 5 beta kits. Beta kit price would probably be around $30-40, and gain you my undying gratitude, your name/handle on the production board, and first pick at debugging help and/or code customization, plus maybe more stuff.
For datalogging, which would be more useful by default- CSV or TSV? I can make it configurable, I'd just be interested to know what people prefer.
Thanks for all the interest!
Ok, i don't want to hijack this thread. If you want we can continue in another thread or not if you are happy. I am just trying to understand for myself why an approach that shouldn't work on paper is working for you..
pitch += gy * dT;
yaw += gz * dT;
pitch += yaw * gx * dT;
yaw -= pitch * gx * dT;
If you also choose a sample rate that is a power of two then you can change the "* dT" to a shift for even more speed. This is difficult since most of the sensors cannot provide suitable sample rates.
I compared this code:
Code:pitch += gy * dT; yaw += gz * dT; pitch += yaw * gx * dT; yaw -= pitch * gx * dT;
Yep. Need to stop the roll first. Otherwise it ends up like the rotor dynamics of a helicopter. The rotation of the main rotor causes a shift in the phase of the applied moment from the fins. Helicopters can be almost 90deg out of phase with the position of the blades relative to the required force moment. For example, you need to apply the required AoA to the blade when it is almost across the flight path to provide fore and aft pitching moments (I seem to remember 86deg phase lead being required in one piece of reading). Likewise, the roll axis is similarly out of phase on the rotorcraft.
So priority one is to stop the roll, otherwise you can induce dutch roll (pitch-roll coupling) or maybe even the equivalent of PIO (pilot induced oscillations).
PS There are some seriously weird aerodynamics on helicopters. There is even one part of the blade cycle where the air flows from the trailing edge to the leading edge of the blade! Seriously peculiar
Interesting. It looks very similar to what I came up with, but I can't get it to work.
Makes me think that cross-axis sensitivity is the likely culprit for the oscillation seen in the first one - it spun like a top on the way up.
What units did you use?
Enter your email address to join: