Posted by Steff Davies on January 4, 2009 at 7:34am
When I was a small boy, I used to watch the Jindivik target drones take off from Llanbedr (see http://www.airsceneuk.org.uk/hangar/1999/dera/targets.htm) on family holidays to North Wales, where my father was born. I've been interested in unmanned flight ever since.Currently, I have built nothing whatever in this line, but I have done a lot of reading (not least here - thanks Chris!). Ultimately, I'm thinking of a small electric fixed-wing based on a simple kit like the Multiplex Easy Star or Twinstar. My current thoughts on the rest of the kit:Mainboard: Gumstix OveroThe familiar Linux environment is too tempting to pass up, I think (I'm a Linux/BSD sysadmin by trade). Also, the surplus of CPU horsepower means that I can concentrate on getting something working in a scripting language and then making it faster rather than having speed as a constriction from the outset.Servo control: http://www.seetron.com/ssc.htmcheapish and lets me outsource the servo-control nastiness (of which I know very nearly nothing) in favour of talking to a serial port, which is more familiar territory.GPS: A 5Hz GPS module of some sort - there's a San Jose 32-channel on sparkfun which looks impressive. It appears to do serial output over two pins at 2.8V.IMU: I think this is going to have to be the Sparkfun 5DOF. I simply don't have the electronics chops to build my own, and anything nicer is going to cost too much for a first go-round.Telemetry: at least initially, wifi looks like the way to go. Unfortunately, the Overo currently lacks a wifi implementation, but there's a known-working USB dongle.This gives me a functional diagram like this:
Some Unresolved Questions (in no particular order):1) Serial connections. The Gumstix Summit board claims two "2-wire serial" connections - are these right for direct connection to the GPS module? To the servo controller board (I suspect not in this case)?2) Are the AD convertors on the Overo accurate enough (10bit) to be useful?3) Are they electrically compatible with the output from the IMU in any case?Have got the wrong end of any very important sticks? Have I made some glaring omission? I throw myself on your mercy.
Aha - right you are. If the choice is laying out a bunch of rather finicky-sounding external amplification and noise suppression versus reviving my C, there's no contest at all. Consider my planning updated :-)
Of course now I see that the Summit breakout board for the Overo only has two chip-select outs and everything at 1.8V versus the 3.3 or 5V seemingly expected by everything else on earth. Ho hum.
Indeed, if you want something a bit more sophisticated, accelerometer/gyro (also usually airspeed, pressure altitude, magnetometer, etc.) will give a lot more capability. Digital sensors allow you to avoid many of the problems associated with measuring milli/micro volt level signals. Properly laying out the analog portion of a PCB is a bit of an art which generally requires some experience to get right, particularly given the nearby presence of some decent electrical noise sources like the motor(s) and telemetry transmissions. An on-board 10 bit A/D will probably not provide usable resolution for the IDG300 (full span +/- 1 V corresponding to +/- 500 degrees/sec), you'll probably need to go to a 16 or 24 bit external A/D, provide some analog low pass filtering and impedance matching, and possibly offset and amplify the signals (you can, however, get A/D converters that will do most of that). Digital gyros and accelerometers take care of all that for you.
Believe me, unless you have some past analog design experience, learning to bit-bang SPI (or I2C) is comparatively quite easy, and you'll probably need it eventually for something...
I've given some consideration to the simpler RC-part or FMA-style stabilisation, but I'd really like something with the potential to be used on a wider variety of planes beyond the prototype park flyer. My impression, which may be false, is that this is likely to require an accelerometer/gyro approach.
I'm a little confused as to what pain the digital modules avoid - presumably a Kalman filter (or nearest offer) would still be needed to fuse the readings from the different sensors. I guess it comes down to which is more agonising in practice, getting six voltages ADed or learning I2C or SPI. My thought was that the former might be simpler, with low-pass filtering in software to help with noise, but I could well be very wrong indeed. More reading, I guess.
The Sparkfun 5DOF "IMU" just gives you some sensors, you'll need to have a good understanding of analog electronics (in particular, what to do about the electrical noise that will inevitably creep in) and be comfortable with some coding some slightly hairy math (see "Kalman filters") to get usable data for 3-axis stabilization and navigation. In my experience, as one who is comfortable writing code, but has minimal electronics background, it's a lot easier to stay within the digital realm to the greatest extent possible. So, I'd look at the MLX90609 digital gyro (150 degree/sec) and the LIS3LV02DQ digital accelerometer, both available in breakout form from Sparkfun.
The real issue, of course, is what you're trying to accomplish. If you want to navigate around some predetermined points, it is quite possible to do so with just a GPS and simpler forms of passive or active stabilization. Look at the ArduPilot tab above. Use a reasonably stable plane, or make use of pre-packaged RC gyros for roll, pitch, and/or heading stabilization. Consider building an infra-red horizon sensing unit, like the FMA Co-Pilot. Taking this sort of approach will get you flying a lot more quickly with less frustration.
Oh, and I think I'm going to pick up The Art Of Electronics tomorrow lunchtime. My skills are both very basic and very rusty and it seems clear that I'm not going to get away with COTS all the way, much as I'd like to.
I'll look into that GPS module for sure, having seen the blog entry on it.
I had a look at Zigbee stuff at one point, but the references I found were a bit a hazy on its advantages versus just forcing an 802.11g connection to 1Mb/s and I'm reluctant to introduce too many unfamiliar technologies at once (for sysadmin read cynic). Is the integration really easier? I'd pretty much expect the wifi blivet to show up as a standard network interface in gumstix's Linux, at which point I'm on fairly familiar territory. More range would be nice, but good LOS is going to be a given in the early stages at least.
--GPS: Go for the Locosys LS20031 GPS on Sparkfun instead. Cheaper and better.
--Telemetry. I'd use XBee Pro rather than WiFi. Better range and easier integration.
Comments
Of course now I see that the Summit breakout board for the Overo only has two chip-select outs and everything at 1.8V versus the 3.3 or 5V seemingly expected by everything else on earth. Ho hum.
Believe me, unless you have some past analog design experience, learning to bit-bang SPI (or I2C) is comparatively quite easy, and you'll probably need it eventually for something...
I've given some consideration to the simpler RC-part or FMA-style stabilisation, but I'd really like something with the potential to be used on a wider variety of planes beyond the prototype park flyer. My impression, which may be false, is that this is likely to require an accelerometer/gyro approach.
I'm a little confused as to what pain the digital modules avoid - presumably a Kalman filter (or nearest offer) would still be needed to fuse the readings from the different sensors. I guess it comes down to which is more agonising in practice, getting six voltages ADed or learning I2C or SPI. My thought was that the former might be simpler, with low-pass filtering in software to help with noise, but I could well be very wrong indeed. More reading, I guess.
The real issue, of course, is what you're trying to accomplish. If you want to navigate around some predetermined points, it is quite possible to do so with just a GPS and simpler forms of passive or active stabilization. Look at the ArduPilot tab above. Use a reasonably stable plane, or make use of pre-packaged RC gyros for roll, pitch, and/or heading stabilization. Consider building an infra-red horizon sensing unit, like the FMA Co-Pilot. Taking this sort of approach will get you flying a lot more quickly with less frustration.
Good luck with whatever you decide!
I'll look into that GPS module for sure, having seen the blog entry on it.
I had a look at Zigbee stuff at one point, but the references I found were a bit a hazy on its advantages versus just forcing an 802.11g connection to 1Mb/s and I'm reluctant to introduce too many unfamiliar technologies at once (for sysadmin read cynic). Is the integration really easier? I'd pretty much expect the wifi blivet to show up as a standard network interface in gumstix's Linux, at which point I'm on fairly familiar territory. More range would be nice, but good LOS is going to be a given in the early stages at least.
--GPS: Go for the Locosys LS20031 GPS on Sparkfun instead. Cheaper and better.
--Telemetry. I'd use XBee Pro rather than WiFi. Better range and easier integration.
-
1
-
2
of 2 Next