Welcome

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

  • 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]

Circle navigation

This weekend I implemented a straightforward method for navigating around a circle. For the first day in like a 2 weeks, the weather was also nice enough to take my funjet for a testride. And yes, it worked quite well! I should check GPS logging to see how well in followed the circular path, but from the ground it looked fine.

How does it work

First we calculate which point on the circle we are currently closest to:
alpha = HeadingTowardsCircleCenter – PI

The closest point on the circle is the one at angle radians:
Lon = LonCircleCenter + sin( alpha ) * radius
Lat = LatCircleCenter + cos( alpha ) * radius

Of course we don’t need the point that is currently closest to us, but the one that is “within reasonable range”.
We calculate:
How much radians (circle radians) per second the UAV flies (if he would be on the circle):
(meter per second) / (radians per meter in circle)
vAngular = [radians per second] = UavSpeed / ( (2 * PI) / (2 * PI * radius) ) = UavSpeed / radius

Now comes the tricky part: we need to decide to which point on the circle we want to fly to. We calculate a new angle alpha2:
alpha2 = alpha + vAngular * tSeconds

We calculate the angle on the circle we should be at in tSeconds .

So we need to aim for the point on the circle tSeconds ahead of us:
Lon = LonCircleCenter + sin( alpha2 ) * radius
Lat = LatCircleCenter + cos( alpha2 ) * radius

How do we choose tSeconds? Good question. I quess it depends on how responsive your UAV is. I took 2 seconds on my first attempt. In the future I will experiment with other values.

Circle navigation

Too far from the circle

One exception case should still be handled: What if we are too far from the circle? With the above algorithm, we would fly straight at the circle. This would be a huge problem because we might arrive at the circle with a heading that is perpendicular to the desired heading! In this case we could choose:
angle2 = angle + PI/2

The point at angle2 is the point on the circle where we would “touch” (and not cross) the circle if we were flying straight at it from a point far away from the circle. This is not optimal, because:
1. In most cases we are still quite close to the circle
2. In case of a big circle, we would not take the shortest route towards the circle
As a basic solution we can pick a smaller angle:
angle2 = angle + PI/4

Depending on the UAV’s agility, speed,current heading and distance from the circle, we could come up with a formula that yields an angle between 0 and PI/2. This still needs to be investigated. In a paper by Nathan D. Rasmussen, I found the following interesting yet visually trivial vector field for circle navigation:

Perfect circle navigation

As a conclusion: complex solutions exist, but simple solutions work good enough in most cases!

18 November 2008, 10:57 | Link | Comments

Artificial horizon

Despite of the lack of fresh messages on my weblog (no, I’m not abandoning the hobby UAV scene :-) ), I still get a lot of emails with questions and requests.
Some people emailed me for the code of the artificial horizon I published some time ago. Unfortunately that one was a quick hack and I was planning to rewrite it in clean and well documented .Net code and post them on my weblog. But honestly, so far it works for me and probably will for you, so why should I put more time into it? :-)

So: here’s the VB.net code: ArtificialHorizon.zip
Usage: Build it, drag the user component on your form, update pitch and roll properties.

8 October 2008, 21:37 | Link | Comments [11]

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]

Sparkfun's 5DOF

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.

7 October 2007, 09:59 | Link | Comments [5]

Older articles | Newer articles