Although I’m still not entirely happy with my solution for the sensor fusion, I need to move on and if it creates a problem later on I’ll come back to it.
Just a note on the sensor fusion: I’ve discovered that it actually seems quite complicated to work out change in altitude from change in air pressure, and because I don’t really need this unless I have altitude hold, which I’m not going to implement for now, I’ve dropped any mention of pressure, temperature or altitude and am not using the barometer on board (for now at least).
This opens up possibilities of an open casing (or transparent) as the barometer is, as far as I know, the only light/wind-sensitive component, however I still plan to stick to a closed casing for the time being.
So now I have a function in my sketch, `refreshPosition(int frequency)`, which sets global variable `currentPosition` to the most recent X, Y and Z Euler angles, I can move on to what I actually do with these.
Firstly, there’s the issue of in what position the IMU actually reads out 0 in all three axes, and which direction of turning (for each axis) yields positive or negative angles. In the definitions file for the RTIMULib library, I can choose one of 24 possible virtual orientations for the X, Y and Z axes, but the default is the expected X North, Y East and Z Down.
However, the natural way to mount it, because of where the text is, and the way I’ve mounted it, means that the components are on the bottom and the silkscreen on the top, and hence in its normal position the X angle is about 180 degrees, not 0.
This raises the perhaps more important question of the exact alignment of the board. Now of course the board functions (primarily) by measuring the direction of gravity, and so it will always know which way ‘absolute down’ is, and hence exactly what attitude it is in.
The compass works in a similar way, treating magnetic north as an absolute reference.
However, the board will almost certainly not be mounted perfectly flat in the actual quadcopter, because (as in the image above) it is only supported on one end by the pins that attach it to a breadboard/PCB. So we have two options to get an accurate ‘down’ estimate in relation to the quadcopter:
- Mount the IMU perfectly flat to the quadcopter. This could be done by flipping it over and resoldering the pins to the board the other way up, and attaching it flush to the breadboard/PCB.
The problem with this method is that it very likely wouldn’t be in exactly the same plane as the frame of the quad, and because the quad functions entirely by knowing its exact attitude, this wouldn’t be good.
- ‘Zero’ the values when we know that the quad is perfectly level, then use the delta values. This seems like a better option: I mount it however I want, and then calibrate the program when the quadcopter is level so that it knows exactly how much to offset the sensor readings by.
The board would still have to be mounted securely so that it doesn’t bend out of alignment mid-flight.
- Do both
I know I said there’d be two options, but the third really does seem the best: I find a secure way to mount the IMU, and then run a program to zero all the values for the best effect.
Ok, so the mounting is a construction problem that I’ll come on to later. For now I need to find a way to convert the read orientation to a usable attitude in relation to what down is, going through a calibration program.
Edit: Right now I’m going to leave it, assuming central values are 0; this is a problem I can come back to but I need to move on for now.