First flight with my autopilot
Two weeks ago, I crashed my micropilot plane. Repearable, but I thought it might be a better idea to use an “easy” plane for the first tests with my autopilot. Also, the limited space available in my delta plane was an issue. And so I bought an easystar. The space under the canopy is very generous, which makes it easy for testing. I installed ailerons on it to make sure it would respond swiftly to my input on its roll-axis.
The first two flights were quiet a disappointment. Flying level posed no problem at all, but making coordinated turns was not as good as expected. Suddenly, I realised I was flying the easystar in 20km/h winds, while the plane only flies at – like 30km/h? Obviously, the pitching behaviour of the eastar when flying upwind or downwind is completely different. I suppose it was just a bad idea to try it in such high winds… Also, the autostabilizing behaviour of the easystar makes it a bad choice as a roll-stabilized plane.
In the late afternoon, when the wind fell between 5 and 10km/h, I did another test. And it was a success! The easystar flew nicely, no weird pitch behaviour anymore, and coordinated turns (and coming out of) were a success! Yiha!
Right now, I just updated my PID code. Now it is much more general. However, this “clean” approach made the update rate drop from 50 updates per second to 41 updates per second. So I was wondering: If you had an autopilot system, would you mind sacrificing performance for clean, readable code? And what about using integer math instead of floating point math (and thus losing the correct “scientific” units)?
No need to worry just yet: my dsPic runs at 7.8MHz, and its capable of 80MHz :-)
|
Maybe you should think about fixed-point arithmetics? I don’t know your code, but shouldn’t the DSP part of the pic work great at various filters (FIR, IIR, Kalman, ...) when using integers?
— ComSubVie, 9 January 2008, 21:47 | #
Hi Tom , Congratulations!!!, Can see the source code autopilot?
— Michele, 10 January 2008, 12:35 | #
@ComSubVie
Yes the DSP part is great for filters, but for the moment I’m trying to write clear code, portable, possible to cross-compile (eg. for simulation). So for the moment using the DSP is not an option. But if it would become a big avantage for the code (eliminate bottlenecks) i would use it for sure.
@Michele
Some patience :-)
I’m not planning to release anything before I have a baseline for both software and hardware.
— Tom, 10 January 2008, 21:29 | #
Can I ask you something?
Do you calibrate the gyros and accelerometers? Is this dynamic or did you do this per hardware?
The accelerometer is pretty simple to calibrate if you can do this “offline” (just align each axis with the earth gravity), but is there any simple solution which does not require this?
Do you have any idea who the gyros can be calibrated?
I’m currently working on an IMU unit (based on a BlackFin BF537 controller which uses the ADXL340 (now named AD22340, but still not officially released) as 3-Axis-Accelerometer and an ADIS16100 (Z-Axis-Gyro) in combination with the IDG-300 (X- and Y-Axis Gyro, for which the ADIS16100 works as ADC).
However I didn’t find any proper solution to calibrate the gyros (except mounting the board on a turnable plate which turns with a specified speed) – but this is no practicable solution once the IMU is installed somewhere.
In response to your last answer: since I’m no PIC user, I have no idea how much performance the DSP would bring. I’m also not very sure if the kalman filter is easily implementable on DSP. Since you are able to run 50 cycles per second performance doesn’t seem to be a bottleneck for you [at the moment].
best regards from Austria
— ComSubVie, 17 January 2008, 14:35 | #
@ComSubVie:
The accelerometers: i hard coded the neutral values in my code
The gyros: They are supposed to be calibrated by th kalman filter!
— Tom, 24 January 2008, 13:32 | #
The gyro itself – the IDG-300 – drifts a lot with temperature so the bias tracking will need to be dynamic.
On another note – I see that you mentioned having a problem with coordinated turns. My observation has been that for coordinated turns, the filter tends to follow the accelerometer inputs more than the gyros. The performance is best for small banks. For any kind of major turn, you will see tracking errors. Perhaps there is a need to change the weightage.
— Daniel Wee, 6 June 2008, 18:26 | #
Hello Daniel,
Coordinated turns are no problem anymore. First I modeled them (well, the centripetal acceleration that comes with it) myself, but it didn’t work 100% perfectly. Now I found a similar approach, but is more robust to noise. This works fine now, even with 30 degrees bank angles.
Another option would be to include the rate of turn (or something similar) in your kalman model. But this is computationally more expensive and more difficult to fine tune. So that will be for a later version :-)
Now I’m building a new one with a pressure sensor and a magnetometer! Yes, it will also be usable in quadrocopters :-)
Tom
— Tom, 7 June 2008, 10:59 | #
Hi Tom, Thank you very much for your work helping us. I’m working on an amateur aerial photography proyect. I would like to know how to extract centripetal acceleration from 5DOF system. (with or without GPS). Thanks again
— Víctor M. Vega, 25 November 2008, 19:26 | #
I designed a mav airplane and I want have a autopilot flight,please help me
yours
— ehsan, 19 January 2009, 12:56 | #