My virtual playground. Meer info

New autopilot hardware

I needed more RAM, more flash to store my autopilot code on. Unfortunately, 44 pins PICs don’t have such big amounts of memory. So I had no other option than to design a PCB for a 64 pins SMD chip. But I quickly admitted that my PCB fabrication skills (and tools) are not good enough to make such fine pitch prints. Luckily, there are some great cheap PCB fab companies. I decided to use Olimex. Four PCB’s arrived on my doorstep 15 days later: two for the Pic32, and two for the dsPic33 (I still haven’t decided which Pic to use in the future…).

Main features:

  • Choice between PPM in or PWM in
  • 5 Servo outs. Software and a “daughter board” could always add additional servo outputs.
  • 2 axis-compass module (3 axis in the future) using I²C
  • digital barometer using SPI
  • the 5DOF, analog input

dsPIC33 version:

  • Powered using the BEC
  • Atmel flash chip for data logging

PIC32 version:

  • Switched power supply
  • Micro-SD socket for data logging

Because everbody loves pictures (dsPic33 version):

Populated with the sensors:

28 November 2008, 00:32 | Link | Comments [8]

Autopilot software architecture

I’m used to working with big bloated enterprise architectures. However this is not what I wanted for my autopilot’s architecture.
The main requirents are:
1. Low computational overhead.
2. Easy to understand for the “average hobbyist”.
3. Can be relatively easy adapated for different hardware platforms.
4. Clean.

So I came up with this straightforward 2-layer architecture:

I didn’t use a middle layer to decouple the hardware layer even further from the logic layer. The main reasons for this are requirement 1 and 2, but also because I believe it is hard to predict how different hardware would be used (eg. with or without interrupts).

Open for comments!

29 February 2008, 12:03 | Link | Comments [6]

Progress on the autopilot

I didn’t do this incredible much on the autopilot since the last post. Flight tests and other work took most of my time. On the code, most of the work went into:

  • Documentation. I used doxygen for the code documentation. Maybe the generated documentation won’t be used a lot, but at least a code documentation standard is set with this decision.
  • Waypoint navigation. I added basic waypoint navigation. Right now the waypoints are still defined in the code, but I plan to store them in the Pic’s EEPROM. This would allow about 30 waypoints. Enough to start with!
  • Refactoring. The code was already nicely structured, but I refactored some parts to make it more readable.

I’m still undecided whether configuration should be saved in EEPROM (and thus changeable at run time), or at compile time (as the paparazzi folks do). On the long term, I guess it’d better be changable at run time…

Flight tests were promising. Sunday I flew my easystar in winds with about the same speed as the easystar at 3/4ths throttle. Stabilization was no problem. However I needed to fly the easystar at full throttle most of the time, which indicated that an altitude hold-feature would be very usefull :-) I’m just afraid that the GPS altitude will never be accurate enough…

Before making any part of the code public, Mariano will help me in further testing and improving the autopilot. I think one of his main interests are the development of a CAN bus architecture for adding other modules to the autopilot. Obviously his tests will probably reveal a lot of bugs/improvements due to his other setup (eg. negative shift for PPM?).

For the moment, I can’t tell when it will be released in public. One of the main reasons for this is that I would like another iteration of the hardware design ànd I would like to offer the hardware in a webshop because I believe that the hardware availability is one of the major setbacks of the current open source autopilots.

27 February 2008, 20:31 | Link | Comments [1]

First successful autopilot flight

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 :-)

13 February 2008, 09:42 | Link | Comments [6]

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 :-)

9 January 2008, 20:37 | Link | Comments [9]

Autopilot module - revision 2

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!

28 December 2007, 14:54 | Link | Comments [12]

Testing Kalman filters

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:

  • Roll
  • Pitch
  • Acceleration along the 3 axis
  • Gyro reading along the 3 axis
  • Heading
  • Airspeed
  • ...

All the available fields can be found in FlightGear\docs\README.properties
I added the following lines to the configuration xml:

  <log n="0">
   <entry n="0">
   <entry n="1">
   <entry n="2">
   <entry n="3">
   <entry n="4">
   <entry n="5">
   <entry n="6">
      <entry n="7">
   <entry n="8">

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:

20 November 2007, 21:55 | Link | Comments [19]

Older articles | Newer articles