After a long period of bad, rainy & windy weather, we finally had a perfect weekend. Sunny and only 1-2 BF wind. Perfect for testing my autopilot.
After some first tests on Saturday, I discovered my EB-85 GPS was also suffering from a known firmware problem. After a minute of flight, the data coming from my GPS module was useless, and my plane kept flying North instead of circling around the home waypoint. Damn you, E-Tek!
Anyhow, as a quick hack to make things work a bit more reliably, I hot-restart the GPS unit every 50 seconds. Also, I set the maximum roll angle the autopilot will use to 17 degrees. These gentle movements will less likely confuse the GPS unit.
And it worked! The easystar circled nicely around it’s one waypoint (being the take-off position). For 25 minutes, my transmitter was laying on the ground while I was just watching the plane. Must have been a weird sight for the people passing by for a walk on this beautiful day :-)
These are some other things I’m having in mind for my autopilot:
- Programmable waypoints
- Improve attitude stabilization on fast unstable planes
- A downlink with some kind of groundstation software
- Document the code better
- Create a new PCB with static and maybe a dynamic pressure sensor… + using a dsPIC with more flash ram.
I only I had more time :-)
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 :-)
I just finished another prototype for my autopilot module. The biggest changes are:
- SMD components!
- Runs on 3.3V: more sensor stability.
- Possibility to use an external crystal instead of the internal oscillator.
The software is finished for about 80-90%. For the moment it looks promising. At only 8MHz (that only 2MIPS!), the module does the following, 50 times per second:
- Decode (and glitch filter) PPM pulse train from RC-receiver.
- Send PWM signals to the servos.
- Sampling of the sensor values and filtering them with a 4th order runge-kutta filter.
- Decode GPS input at 2Hz.
- Kalman filtering pitch and roll.
- A simple PID algorithm for stabilization.
Looks nearly finished… however, testing in a real MAV and finetuning everything will take a lot of time!
A lot of people saw I purchased a 5DOF module from SparkFun and even made a test-PCB for it. Obviously, they asked me if I was willing to share my code. Well alright, here you have it.
A simple embedded kalman filter, nicely documented. Also featuring, for the interested:
- Using the ADC hardware module in a dsPIC30
- Using the UART module in a dsPIC
- Using the timer module in a dsPIC
- How to organize your code! I’ve seen some hideous projects on the web.
The code is written using Microchip’s C30 compiler . The non-optimizing version is free!
I wrote a small app to visualize the output better:
And last but not least: downloads!
- Eagle schematics: 5DOF_Tester_v0.2.zip
- MPLab project files and c-code for the C30 compiler: KalmanTestBoardV1.zip
There is a bug in Microchip’s latest libs. You need to add: #define UART_ALTRX_ALTTX 0xFFE7 /*Communication through ALT pins*/
to uart.h or to the code that references it.
A lot of people think they need great electronics skills, a lot of time, and embedded programming skills to experiment with Kalman filtering of IMU-data. Think again! The key to all your success stories is simulation!
One of the easiest tools that can help you with those simulations, is a great flight sim called Flight gear. It uses advanced aerodynamics simulation libraries, among which some were created by the NASA. Good enough for our purposes! On top of that, you can easily configure Flightgear to log all the data you need. I updated my config file to log the following variables:
- Acceleration along the 3 axis
- Gyro reading along the 3 axis
All the available fields can be found in FlightGear\docs\README.properties
I added the following lines to the configuration xml:
<logging> <log n="0"> <enabled>true</enabled> <interval-ms>100</interval-ms> <filename>fg_log.csv</filename> <delimiter>,</delimiter> <entry n="0"> <enabled>true</enabled> <title>AccX</title> <property>/accelerations/pilot/x-accel-fps_sec</property> </entry> <entry n="1"> <enabled>true</enabled> <title>AccY</title> <property>/accelerations/pilot/y-accel-fps_sec</property> </entry> <entry n="2"> <enabled>true</enabled> <title>AccZ</title> <property>/accelerations/pilot/z-accel-fps_sec</property> </entry> <entry n="3"> <enabled>true</enabled> <title>DRoll</title> <property>/orientation/roll-rate-degps</property> </entry> <entry n="4"> <enabled>true</enabled> <title>DPitch</title> <property>/orientation/pitch-rate-degps</property> </entry> <entry n="5"> <enabled>true</enabled> <title>Roll</title> <property>/orientation/roll-deg</property> </entry> <entry n="6"> <enabled>true</enabled> <title>Pitch</title> <property>/orientation/pitch-deg</property> </entry> <entry n="7"> <enabled>true</enabled> <title>Heading</title> <property>/orientation/heading-deg</property> </entry> <entry n="8"> <enabled>true</enabled> <title>airspeed</title> <property>/velocities/airspeed-kt</property> </entry> </log> </logging>
Then I created a small VB tool (Yeah, kalman filters in VB ;-) ) to filter the data. This is the result:
One thing you can see, is that if I calculate the centripetal acceleration, and substract it from my y and z acceleration, the resulting roll angle has a standard deviation of only 2 degrees. Not bad!
Files for you download pleasures:
After my experiments with the thermophile sensors, I decided to give Sparkfun ‘s 5DOF a try. Thermophile sensors worked well, but you need 6 sensors to be able to make nice turns. Then it becomes annoying and a lot heavier than this 5DOF module. It’s not that much cheaper eather (10$ per thermophile sensor, 110$ for the 5DOF).
Anyhow, after some troubles with the creation of the test board, it is finally done:
I also needed a new programmer to program the dsPic I’m planning to use. Ebay pointed me to a chinese ICD2 clone. Not bad :-)
Now the electronics side of the tests is finished, I can move on to the software side (Kalman filter!) which is more my cup of tea.
I’m lucky enough to have the opportunity to “play” a bit with the Micropilot autopilot module and software that comes with it. While going through all the steps before we have our MAV in the air, I’ll do my best to post some of my experiences on my weblog. Part one! A first glimpse at the autopilot.
The module itself looks very professional: All paths are in an inner layer, so none is visible. On top of that, a special coating layer is covering the PCB.
Some chips on the module caught my attention:
- Sipex UART to RS232 on-board : Isn’t it odd that they use RS232 on the module and not just TTL to communicate with the modem (which also contains a RS232 to TTL chip) and PC?
- MAX660 Switched Capacitor Voltage Converter I have no idea what they use that for
- Cirrus Logic AD convertor This is just a normal AD-convertor
- LCX14 Standard hex invertor
- A 49.1uH inductor . I suppose that is for filtering? I’m not familiar with other uses of an inductor…
- 3 gyroscopes and 2 accelerometers. The Analog Devices ones you find in most IMU’s.
- One static and one dynamic pressure sensor. Also looks very standard.
- XC9536XL High Performance CPLD This is a Xilinx FPGA. High performance, low power.
- M410000025: This is RAM. I have on idea how much…
- The main processor is a FreeScale one. I didn’t rip off the sticker on it to see which one :-)
- Commonly used TIM GPS module from u-blox.
- The servo board contains the 17HCT237 to demultiplex a 3-bit data input to 8 data output (to the servos)
Most of these components are pretty standard, but it is clear that this module has quiet some processing power!
The weight of the module is only 28 grams. Unfortunately, the standard GPS antenna that comes with it is 38 grams! The interconnecting cables that come with it aren’t made for weight-saving either. So if we want a really low weight, we’ll have to come up with some ideas ourselves. The manual refers us to the website for solutions for these kind of issues, but I haven’t gotten my Support ID yet to log in.
Speaking of the manual: it looks very complete (160+ pages) and there is even an instruction video explaining the basic setup procedures. Compared to some other autopilot modules i’ve seen, it all looks very complete and professional.
Every parameter of the numerous PID loops it contains is configurable, including min and max settings, which PID loop to use at what speed and some others I never even thought of myself (and still need to find the use of it ;-) ). For automatic take-off, there are also a lot of options.
The back of the module, with the servo board next to it:
The front of the module, with a small part of the cables mess to interconnect everything:
More to come! If you’d like me to cover a certain topic of the micropilot, let me know!