I finished migrating all my hardware-related code from my old autopilot to my new one. The most important new feature for me is datalogging (how could I ever live without it). Data is logged in a binary format on a dataflash chip.
The flightitself was manually and it’s only purpose was to test the datalogging feature.
It works! I was suprised to see how accurate the EB-85’s GPS height is. When I make a flight together with the barometer I’ll post a comparison between those 2 heights.
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…).
- 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
- Powered using the BEC
- Atmel flash chip for data logging
- Switched power supply
- Micro-SD socket for data logging
Because everbody loves pictures (dsPic33 version):
Populated with the sensors:
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”.
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.
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:
As a conclusion: complex solutions exist, but simple solutions work good enough in most cases!
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.
The PWM-pulse used to control an RC-servo doesn’t need to be at the same voltage-level as the servo’s supply current (5V)! Using any voltage between 3V and 6V is perfectly fine for the NE555 driver chip.
Damn if I knew this before it would have saved me quite some time (and pull-up resistors and buffers) on my autopilot module!
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.
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!
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.