I did some ‘passive’ test flights today going back to check the basics. Without the ESCs / motors powered up, I did a 12s pseudo-flight, where I picked Phoebe off the floor climbing to a meter in about 4 seconds; then I walked her forwards for 1m for about 4s again; finally I walked her left by about a meter again for 4s.
These are the three positive directions for the accelerometer so I should see positive spikes in acceleration at these points, a raised fixed velocity of each of the axes, and from the distance point of view 3, 1meter 4 second humps. So this came as a bit of a surprise:
Acceleration – WTF
Velocity – WTF
Distance – WTF
Velocity is the clearest – it should be 3 positive bumps – Z axis first for take-off, then X axis for forward movement, and then Y axis for leftwards movement; each bump should be about the same size / shape!
Accelerometer readings worry me most though as this is (almost) raw data from the sensors with little tinkering from me: there should be a positive spike, followed by a negative spike roughly four seconds later. The spikes should be roughly the same height for each axis, and (for example), the positive spike in X acceleration should happen at the same time as the negative spike in the Z acceleration.
Just in case Phoebe’s sensor was duff, I did the same with Chloe and got almost exactly the same results.
Something is seriously wrong with my accelerometer averaging! At least that explains why Phoebe keeps crashing into walls.
P.S. Sorry for the change in graph styles – the death of my home computer has forced me to produce the graphs on my work computer running Excel 2007 instead of 2003, and as with everything from Microsoft, there’s a real quality problem between sequential releases; in this case Excel 2007 has chosen to completely change the default colour tablet making it almost impossible to use the same colours as my 2003 graphs, and frankly I don’t want to waste any more of my time than is possible fighting Microsoft ‘enhancements’ to Excel 2007.
Currently, my accelerometer calibration of offset / gains against temperature requires two days of action, reading the sensors at various angles across a broad range of temperatures to put into Excel to produce trend lines allowing calculation of offset and gain at the current temperature for the X, Y and Z accelerometers. If you think that sounds difficult and tedious, multiply by two and you’re getting there. It works but I don’t like it for several reasons:
- off-the-shelf quad manufacturers / DIYers don’t do this
- it’s tuned to a specific sensor – replace a broken sensor with a new one and the calibration needs to be redone
- the calibration can only really be done on a sunny day in winter to be able to get termperature ranges from 10°C (Phoebe sleeps in the garage overnight) to 25°C (Phoebe moves indoors, and as her temperature rises, many samples are taken).
So I’ve been considering how to calibrate the accelerometer in flight. It goes a bit like this: Prior to take-off
- read the accelerometer many times and take the average while she sits quiet and stable in the ground – these readings are a gravity vector in the quadcopter’s frame (QFGV) and will be flawed due to offset and gain errors.
- Using the QFGV, calculate her angles wrt earth using Euler – again the angles will be incorrect, but testing shows the error isn’t far from the truth
- Use the quadcopter to Earth matrix to convert the QFGV to earth coordinates – the Earth frame gravity vector (EFGV) – in the perfect world, it should read 0, 0, 1 – the perfect world earth frame gravity vector (PWEFGV) but doesn’t in reality
- Subtract the PWEFGV from the EFGV to come up with earth-frame error vector (EFEV)
- Convert that EFEV back from the Earth frame to the quad frame to produce the quad-frame error vector (QFEV).
Now set Phoebe running:
- read the raw accelerometer values every loop, integrating them over the time between each read
- Periodically (roughly 40Hz compared to her spin rate of roughly 440Hz) process the readings by dividing by the elapsed time since last processing to come up with averaged accelerometer readings.
- Subtract the QFEV from the readings to produce a ‘better’ set of quad-frame averaged accelerometer results
- Use this better set of accelerometer results to come up with better angles via Euler
- Use the better angles to convert the original fixed QFGV to a new, more accurate EFGV
- Again subtract the perfect world PWEFGV from the new EFGV to come up with a new EFEV.
- Convert the EFEV back to a QFEV
- Repeat ad infinitum
This should produce an ever improving set of offsets by taking the initial fixed QFGV and constantly refining the quadcopter accelerometer readings with the QFEV. In doing so, there should be convergence on an accurate value for the QFEV – i.e. the accelerometer is calibrated on-the-fly. Initial testing suggests this might just work, but Phoebe is not getting her @R$£ off the ground fast enough, so tilting to stop drift is causing the props to clip the ground. More testing later with a more energetic take-off rate will hopefully be more conclusive.
P.S. All the above is based on the assumption that calculation of Euler angles from raw accelerometer readings is more accurate than the raw sensor readings themselves. Currently I’m working on gut-feel, but I need to spend the time producing a mathematical proof.
P.P.S. On the other hand, it’s easy to prove in real-world testing – if not true, then Phoebe will progressively go mad instead of settling into a stable state of affairs.
Have a look at PiStuffing/Quadcopter to see all the changes made relating to
- reference frames
- timing accuracy
- PID selection
- performance and averaging
I’ve also added a very early alpha draft of the PDF guide about quadcopters in general and Phoebe in particular.
Oh, and I forgot to mention that with the code changes for reference frames, timing, PIDs and averaging, she’s flying much better now – less drift, and much more stable. Not quite worthy of a video yet, but soon I hope.