YADIYA - Yet Another DIY Autopilot Project
Yet Another DIY Autopilot :)
I've decided to go about making my own AutoPilot board from the ground up. Well, I won't exactly be starting from scratch - hopefully I will be able to incorporate the collective wisdom of this community :). I know there are several boards out there that may fit my needs/wants closely. However, I just wanted to go through the whole process of doing it myself.
My goal is to order a batch of PCB's by the end of this year, probably from Gold Phoenix PCB.
For some reason I'm bent upon using a RTOS. Actually, there are very good reasons.
FreeRTOS is free, popular, and well supported. So as far as processor selection, I want to choose a supported device.
FreeRTOS Supported Devices
http://www.freertos.org/a00090.html
I would like the device to be powerful enough to run an AHRS algorithm (extended kalman/DCM - possible both in parallel to compare them), navigation, telemetry, image compression (for images through wireless xbee or whatever data link), input filtering (some inexpensive FIR filters), and whatever else I can think of. Also, the availability of free development tools and debuggers for the processor is a must.
As far as sensor inputs - versatility is the name of the game.
* 3 axis gyro
* 3 axis accel
* 3 axis magnetometer
* 3 axis thermopiles
* differential pressure sensor (speed)
* barometer (altitude)
* GPS
* (optional) camera (simple image processing, horizon detection or something)
* Ultra sonic/laser for range finding (used for landing)
So, something that can handle all of the above if possible.
Another factor in deciding what hardware to use are the packaging of the various parts. For example, while BGA's and LGA's are possible to solder at home using a toaster oven reflow technique ... I would want to avoid that - unless many of you have had positive experiences with it. Quad flat packs are do-able by (my) hand ... Still considering if I want to make a mini project out of soldering grid-array type parts. I'm reading up on how easy or difficult it is currently - as it will effect my choice of parts.
For the 3 axis accel and gyro, should I use the Sparkfun Razor 6DOF board? I heard that there are some significantly better performing gyro's in the same flat configuration [I really really want a flat board .. no funny things sticking out of it *cough* ArduIMU *cough* UAVDevBoard :) ]. Is that true? Part numbers? If there isn't much benefit in switching devices, I would rather just buy the SparkFun module just to stay away from having to solder BGA/LGA chips which the gyro/accel's usually come in. I would like the IMU board to be separate anyways, in order to mount it as close as possible to the CoG of the plane. Also, I would like the magnetometer to be able to be remotely located - so as to be able to position it away from EMI.
Anywhoo, here's a thread - let's toss some ideas around. I'll be putting schematics together in the next few days and weeks - and will perhaps get an eval kit for whatever processor is chosen.
I've decided to go about making my own AutoPilot board from the ground up. Well, I won't exactly be starting from scratch - hopefully I will be able to incorporate the collective wisdom of this community :). I know there are several boards out there that may fit my needs/wants closely. However, I just wanted to go through the whole process of doing it myself.
My goal is to order a batch of PCB's by the end of this year, probably from Gold Phoenix PCB.
For some reason I'm bent upon using a RTOS. Actually, there are very good reasons.
FreeRTOS is free, popular, and well supported. So as far as processor selection, I want to choose a supported device.
FreeRTOS Supported Devices
http://www.freertos.org/a00090.html
I would like the device to be powerful enough to run an AHRS algorithm (extended kalman/DCM - possible both in parallel to compare them), navigation, telemetry, image compression (for images through wireless xbee or whatever data link), input filtering (some inexpensive FIR filters), and whatever else I can think of. Also, the availability of free development tools and debuggers for the processor is a must.
As far as sensor inputs - versatility is the name of the game.
* 3 axis gyro
* 3 axis accel
* 3 axis magnetometer
* 3 axis thermopiles
* differential pressure sensor (speed)
* barometer (altitude)
* GPS
* (optional) camera (simple image processing, horizon detection or something)
* Ultra sonic/laser for range finding (used for landing)
So, something that can handle all of the above if possible.
Another factor in deciding what hardware to use are the packaging of the various parts. For example, while BGA's and LGA's are possible to solder at home using a toaster oven reflow technique ... I would want to avoid that - unless many of you have had positive experiences with it. Quad flat packs are do-able by (my) hand ... Still considering if I want to make a mini project out of soldering grid-array type parts. I'm reading up on how easy or difficult it is currently - as it will effect my choice of parts.
For the 3 axis accel and gyro, should I use the Sparkfun Razor 6DOF board? I heard that there are some significantly better performing gyro's in the same flat configuration [I really really want a flat board .. no funny things sticking out of it *cough* ArduIMU *cough* UAVDevBoard :) ]. Is that true? Part numbers? If there isn't much benefit in switching devices, I would rather just buy the SparkFun module just to stay away from having to solder BGA/LGA chips which the gyro/accel's usually come in. I would like the IMU board to be separate anyways, in order to mount it as close as possible to the CoG of the plane. Also, I would like the magnetometer to be able to be remotely located - so as to be able to position it away from EMI.
Anywhoo, here's a thread - let's toss some ideas around. I'll be putting schematics together in the next few days and weeks - and will perhaps get an eval kit for whatever processor is chosen.
Replies to This Discussion
-
DeveloperPermalink Reply by Ryan Beall on -
I use the ADXRS300's which are BGA. I have soldered over 15-20 of these by hand and have had 100% success rate except for the time that I picked up the board when it was still hot and the part fell back off. So I'd say with the right techniques BGA are actually really easy to do. Kinda of scary to screw up soldering a one time only part that costs 50$ each but like I said....Haven't messed up one yet knock on wood!
Good luck.
Ryan
-
Permalink Reply by Faisal Shah on
-
How do you put the solder paste on the pads? Do you get a solder mask made and use that ($$$), or do you put little dabs of solder paste with a fine tip or something (I know someone who has done this :) ) ? Is there a particular method that you use? Got a link to it or something?
I appreciate input on this aspect, as it may drive which components I choose (or even topology if I'm forced to by a ready made IMU board!)
-
DeveloperPermalink Reply by Ryan Beall on -
The ADXRS300's have solder already on the bottoms of the chip and I just load up the board with liquid flux and place the part as centered and square as I can visually. Then I use a heat gun to stick the part down. As it heats up the solder will almost float the part such that it self aligns and you can see the part actually sink into the board. I then just take the heat off and let it cool before moving it.
-
-
The ADXR series are really nice, as they have a differential measurement - eliminating vibrations and the such for the most part, and an on-die temperature sensor output. However, they are only single axis and significantly more expensive than the ST Micro gyros.
Would it be a mistake to go for LPR300AL (300 deg/s Pitch and Roll) and LY530AL (300 deg/s Yaw), as opposed to 3 ADXR300's ? Whichever route I do go, would it make sense to get a lower rate yaw gyro for increased resolution? My rationale is that yaw rates are typically lower than pitch and roll rates. So, how about 300deg/s for pitch and roll, and 150deg/s for yaw?
Hmmm, another idea. The dual axis pitch+yaw gyros from ST Micro and the single axis yaw gyro are about the same cost. Since I have to use 2 chips anyways - will there be any advantage to having two measurements for the pitch if I go ahead with 1 pitch+roll gyro, and 1 pitch+yaw gyro? If it is a better idea to have a lower deg/s rate for yaw, then one advantage is see is that I can get the pitch+yaw gyro in the 150deg/s - giving me pitch measurements from this chip at a higher sensitivity than the pitch+roll gyro which will be 300deg/s. If I detect that the pitch rate is > 150deg/s (i.e. saturating), then I can switch over the 300deg/s pitch measurements from the other gyro. Also, maybe the two measurements could be combined to compensate for drift or something .. just ideas. Comments please! :)
-
Permalink Reply by Andy Geppert on
-
Ryan, what flux do you use? And how do you clean it up after reflowing? Have you considered a paste style flux, or is the liquid just fine? I haven't used either and I really need to start using some.
-
-
I like your proposed approach. I'm considering something similar, although I'm probably going to use Arduino (on a Mega - with all sorts of modularity and the ability to leverage all of the work already done on ArduPilot), but I am curious about the FreeRTOS possibility. I wonder how much simpler that would make the project. I think the bulk of the challenge is in the math with respect to navigation and stabilization. Everything else (even the hardware) seems simple compared to that. It sounds like you are just looking for an opportunity to dive into RTOS programming - or do you have some benefits in mind for RTOS? BTW, it looks like that RTOS will run on a Mega. I'm not sure if the Mega can handle image manipulation (in fact I doubt it), but it would handle everything else all right.
-
-
All the word done on ArduPilot is a simple matter to transfer to another processor, as long as it has a C compiler. So, you don't have to worry about that.
I guess on some level yes, I would like a convenient excuse to dive into RTOS programming. However, there are very real and good reasons for using an RTOS. Future expandability is a great reason, and the ability to design and write code as "parallel" tasks makes for a simple and elegant implementation. It makes things easier to debug, and allows one to focus on writing one thing at a time. From what I have heard from most firmware engineers - excluding the most simple designs, there are always more benefits to having an RTOS than not having one.
Maybe Tom Pycke can chime in with his experiences in using an RTOS in his autopilot: http://tom.pycke.be/mav/106/real-time-os .
Additionally, here is a presentation by AVIX (a commercial RTOS) on the benefits of a RTOS.
http://www.docstoc.com/docs/14194944/AVIX_-Why-use-an-RTOS
-
-
Another capability that I would like to have on board:
Data logging to an SD flash card. This would be an invaluable resource - being able to be obscene and log as many parameters as I want to without worrying about available space in EEPROM/whatever :) .
-
-
That's some great stuff. I'm very intrigued by using an RTOS, but I'm still inclined to stick with Arduino, just because that's the course I'm already on. But that's not a real good reason and there are several good reasons to move to an RTOS... Decisions... I'll definitely be watching your progress, as well as Tom's. Thanks for the links.
Top Discussions
Groups
-
Micro Drone
45 members
-
ArduPlane User Group
1472 members
-
3D Printing Drone Parts
282 members
-
Andropilot Users Group
470 members
-
3D Models
57 members
© 2019 Created by Chris Anderson.
Powered by
