SparkFun Forums

[ghint]

This stuff is going to be hard to test since it'll always have to be done on the hardware. It would be *really* nice to have sets of test data that also included physical measurements of the angles so we could analyze how much error we're getting. Something tells me I'm going to spend a few hours driving figure eights in empty parking lots trying to get some tricky data...

Actually there's a pretty straightforward way of checking errors without precise measurements from an unbiased industrial strength IMU. I do it visually.

I coded an artificial horizon in OpenGL with is overlayed over an video feed from a wireless camera. The camera is oriented at zero roll & pitch relative to the imu (like an aircraft nosecam).

So if you point the camera to an object with a known orientation (imagine a house window frame) and jig it around you can verify how close the OpenGL horizon line is to the real frame. If you're saving the movie, you can even review frame by frame and manually calculate real tilt (my doing some hand trigonometry calculations on the border image) and compare it to the imu data (used to draw the OpenGL overlay).

Now would be a good time to mention you'll never be able to fine tune the filter to track the frame accurately. Lens have slight distortion, and the bias is not 100% trackable in ANY existing filter. But it does provide a nice reference for improvements.

Works kind of like the old gunsight alignment method of pointing to any part of a target, firing, and then aligning the scope to place the X over the bullet hole

Comments?

[Bergamot]

This stuff is going to be hard to test since it'll always have to be done on the hardware. It would be *really* nice to have sets of test data that also included physical measurements of the angles so we could analyze how much error we're getting. Something tells me I'm going to spend a few hours driving figure eights in empty parking lots trying to get some tricky data...

Actually there's a pretty straightforward way of checking errors without precise measurements from an unbiased industrial strength IMU. I do it visually.

I coded an artificial horizon in OpenGL with is overlayed over an video feed from a wireless camera. The camera is oriented at zero roll & pitch relative to the imu (like an aircraft nosecam).

So if you point the camera to an object with a known orientation (imagine a house window frame) and jig it around you can verify how close the OpenGL horizon line is to the real frame. If you're saving the movie, you can even review frame by frame and manually calculate real tilt (my doing some hand trigonometry calculations on the border image) and compare it to the imu data (used to draw the OpenGL overlay).

Now would be a good time to mention you'll never be able to fine tune the filter to track the frame accurately. Lens have slight distortion, and the bias is not 100% trackable in ANY existing filter. But it does provide a nice reference for improvements.

Works kind of like the old gunsight alignment method of pointing to any part of a target, firing, and then aligning the scope to place the X over the bullet hole

Comments?

Well, my method would produce numerical values that could be graphed. It's really difficult to look at a delay in a video and tell if it is significant; it's much easier to look at a chart graphed out over time.

It's a cool idea, though, and would certainly be useful for some things.

[ghint]

Well, my method would produce numerical values that could be graphed. It's really difficult to look at a delay in a video and tell if it is significant; it's much easier to look at a chart graphed out over time.

It's a cool idea, though, and would certainly be useful for some things.

My point exactly. That method is the only scientific method of benchmarking a filter performance. The trouble is getting accurate test data.

i was being kind of ironic on the previous post. i do use the process but only to estimate how resistant to linear accelerations i can get the filter to perform. not to estimate how close the estimate is to the real thing that would be kind of cracknutty

[emf]

Actually there's a pretty straightforward way of checking errors without precise measurements from an unbiased industrial strength IMU. I do it visually.

I think there's a lot of merit to that approach. I spent the weekend hooking up bluetooth to my IMU and writing a little artificial horizon display for my ipaq so I could do some visual verification. Yours setup looks a few orders of magnitude better than mine, but it lets me see what's going on in real-world terms.

[I know you realize this, but I've had a little too much coffee so you're gonna hear about it anyway ]

But... I'm sticking with what I said before -- it's going to be hard to test. When I first saw the video you put up of the filter in action it looked great, but twisting the IMU around in your hands has very little in common with strapping it to a plane and sending it off into the wild blue yonder. Likewise with the demo video on the paparazzi site.

Both your blog and this thread are two good reminders of that. It sounds like you discovered that your filter was pretty much throwing out the gyro data, but everything still looked good on the bench tests because the accelerometer was operating in an environment where it can mostly be trusted. (Sounds like a nasty bug to track down... I'm curious what made you realize something was wrong). On this thread, we had the axes backwards, mixing the pitch gyro into the roll accelerometer & vice versa, but the output still looked pretty good for reasons unknown. It was probably doing something similar and giving very little weight to the gyro readings.

The kind of tests I'm thinking of (after I get something working well on the bench) are: suspending the IMU on a string from my rear view mirror and driving in a circle (or maybe tying it to my ceiling fan?). The IMU will be tilted, but the accelerometer will claim that it's upright. How long will the filter last before "erecting". Or tape it flat on the dash so the accelerometer is reading a bank angle but the gyros are claiming that it's in a skidding turn.

Ok, enough for this rant. See you in the 6DOF thread in a few minutes.

[thanutz]

Hi there,

Apologies for the thread hijack, I have read the whole discussion alongside studying the code, the rotomotion code and the MAV/UAV Blog.

My needs are far less complex than those discussed, i'm purely intrested in obtaining just the roll angle of a moving object. The gyroscope i am using is an ADXRS300 and the accelermoter is an ADXL203. These are going to be plugged into the ADC (12bit) of a dsPIC6014.

I have a few questions but would be grateful for any advice that you guys could give as i noticed that emf programmed his on a dsPic.

1) As im only intrestead in roll, i believe i require only one gyro and a dual axis accelerometer? Am i correct? If so the gyro will be obtaining the roll rate, the accelerometer will be calculating the angle for filtering the gyro drift (bias). . Would i be correct in saying that the gyro will be measuring the z axis rate as shown in the diagram and the accelerometer will be measuring the x and y forces and calculating the angle??

2) is it possible to this is on the dsPic? Ive managed to get the adc working and sampling all my 3 input datas so am now at the filter stage.

3) has any1 ever used the gyro and accelermoter i am goign to be using? If so do you have the noise and trust values (sz_00, sw_00, sw_11).

Many many thanks for any advice/help

Kind Regards
Anil

[emf]

Would i be correct in saying that the gyro will be measuring the z axis rate as shown in the diagram and the accelerometer will be measuring the x and y forces and calculating the angle?

This all sounds correct to me.

2) is it possible to this is on the dsPic? Ive managed to get the adc working and sampling all my 3 input datas so am now at the filter stage.

Should be a piece of cake. I was running my 30F3014 at 14 MIPS. The code I hacked together from the two-axis filter in this thread was running at 10Hz with no problems. I think I first tried it at 20Hz and it couldn't keep up, so I backed it off to 10Hz. Running one axis, you should easily get 20Hz. I also implemented everything in the most bone-headed fashion, blocking during ADC conversions and while sending output to the UART (the UART bit is the biggest time hog by far).

[thanutz]

Uart? is that for output info on the rs232...i dont actually need it to output anything at this stage...im using the MpLab IDE software to watch the values at this stage....

Would you mind emailing me your code if possible emf...i would be extremly grateful...

Regards
Anil

[thanutz]

my email is: ag3418 at bris.ac.uk

Regards
Anil

[emf]

Uart? is that for output info on the rs232...i dont actually need it to output anything at this stage...im using the MpLab IDE software to watch the values at this stage....

Yeah, I was dumping the roll & pitch over rs232 for debugging or driving a display on my ipaq. It should be easy to disable.

I'll send you a copy this evening.

[thanutz]

Uart? is that for output info on the rs232...i dont actually need it to output anything at this stage...im using the MpLab IDE software to watch the values at this stage....

Yeah, I was dumping the roll & pitch over rs232 for debugging or driving a display on my ipaq. It should be easy to disable.

I'll send you a copy this evening.

Thank you so so so much...im really intrested in your specific settings for the ADC such as how the data comes in signed and unsigned, how uve dealt with ref voltage...etc

Kind Regards
Anil

[emf]

im really intrested in your specific settings for the ADC such as how the data comes in signed and unsigned, how uve dealt with ref voltage...etc

I didn't do anything interesting... Both the pic and sensors are powered at 3.3V, and I use Vdd and Vss as the voltage references. I ignore the voltage reference coming from the gyro. I don't bother with setting up conversion sequences. I just have it return a value from 0 to 4095 because that was the easiest thing to integrate into the atmega-based code. I'm sure I'll end up making the code a lot more efficient, but this was just a quick hack to get it running.

[thanutz]

ahh ok...well please still email me ure code as it will be of great help.

Regards
Anil

[thanutz]

think I first tried it at 20Hz and it couldn't keep up, so I backed it off to 10Hz. Running one axis, you should easily get 20Hz. I also implemented everything in the most bone-headed fashion, blocking during ADC conversions and while sending output to the UART (the UART bit is the biggest time hog by far).

Right, I have looked at all the code and it has been of great help. Thanks EMF and MThompson.

EMF, i suspect im having major problems with the accelerometer due to the adc sampling too often. At present i am letting the pic autosample and convert all the channels. It then does an arctan2 function on the accelerometer data and then clears the interupt (to repeat the whole process). I want to ensure at this stage of testing that i get the right angle with my data. However i suspect it is way off, and when leaving it at 0 angle the ADC sampled values arent stable and are constantly changing.

Do u think its cos im sampling too often? If so should i use manual sampling like u have in ure code and place some delay?

Kind Regards
Anil

[emf]

However i suspect it is way off, and when leaving it at 0 angle the ADC sampled values arent stable and are constantly changing.

How much are they changing? Mine wobble around a bit, but not wildly. I just took a look at an old data file I made of the IMU at rest. The accelerometer readings had a mean value of (z: 2472.41, y: 2086.47, x: 2087.79) and standard deviation of (z: 7.64, y: 3.69, x: 3.98 ). This was calculated over a 50 second sample at 50Hz. I think that should cause the readings to fluctuate about 1.5 degrees either way. Is that similar to the instability you're seeing?

How is your accelerometer connected to the ADC? If you don't have any sort of buffering and you're sampling at a fast rate, you could easily be getting a lot of garbage in your readings.

For what it's worth, my readings were taken in the (admittedly sub-optimal) setting, all on a solderless breadboard:
ADXL330 -> 50Hz LPF (.1uF cap built into IMU) -> LM324 op amp as voltage follower -> dsPIC analog in

[thanutz]

Firstly many thanks for all your help

Its much more than 1.5 degree im getting im afraid to say. i suspect its just from auto sampling - my code is here: MChip Forum

No buffering in the connection. The acclerometer is on an evaluation board with a 100nF cap diung the LPF to 50hz. Its just a wire as it stands into my pic devopment board, but when i make my final thing it will be soldered on a PCB.

What does you Op Amp do?

Emf if you take a look at the code linked here i would be very grateful:MChip Forum

Also when the zeroing occurs in the code for the accelrometer, does the Y value take gravity into account so i.e. Y and X have different values subtracted so at rest (when gravity is fully active) they are both set to 0. Looks a bit clearer in my code (look at X and Y values).

Many many thanks
Anil