Hey everybody,

Do any of you have experience building an autopilot with a Gumstix module? I know the idea has been thrown around before, but I haven't seen much real discussion about it. I'm torn between the KISS philosophy and the idea of just having room to experiment (ie Arduino/ATMega vs. Gumstix).

One intriguing use for a more robust processor is the ability to attach a USB webcam or special-purpose CCD camera. However, I know the limiting factor for beaming back to the ground is still radio speed. Also, there is the added complexity of setting up the Gumstix environment, plus the microcontroller probably needed to deal with analog signals.

On the other hand, I would like to build a UAV platform for experimentation, ie attaching different sensors and modules and trying out different configurations. In this sense, it seems like using a Gumstix-level processor up-front would save me time and money later, since I would already know how to use it when I wanted to do more powerful things.

Any advice/thoughts?

Views: 2576

Reply to This

Replies to This Discussion

The only two Gumstix projects I know of are these:

Fixed wing


The general problem with them is that they're relatively expensive and need a lot of supporting parts to make an autopilot.
For the interface you can use a part of the HB-Autopilot fond here:
You can also use the booz IMU from the paparazzi project
The interface is only a spi connection or a usb connection for both autopilots.
The HB-Autopilot can fly all kinds of aircrafts.
The software for the old gumstic can be found here
They're not necessary anymore, too expensive, & too fragile thanks to those hirose connectors. Microprocessors are at the point they can do everything on 1 chip. Netburner can do a Linux environment for a lot less money.

as mentioned in the link above, I am engaged in developing an autopilot for fixed wing using the Gumstix. See http://www.voidpointer.de/easybot/index_en.html for example. So far, I am not disappointed to have choosen the Gumstix for main computer. Having a standardized software environment can enormously boost the development process. Gumstix in combination with Linux has the advantage to provide an uniform and convenient environment for rapid prototyping. Connecting a GPS is just a "cat /dev/ttyS3" and connecting I2C is easy as well. Using SD cards there is lots of disk space for extensive logging. I am currently testing the fusion of SRTM data with altitude information - SRTM files for Germany take about 200 MB - no problem for a Mini-SD. Bluetooth or Wi-Fi provide standardized communication. And even running at (only) 166 MHz my autopilot still has a big margin of computing power. With 4Hz GPS and 50Hz IMU rate "uptime" tells me a load average of 0.10. And I wouldn't say that $99 is expensive for a prototype.

About the fragile hirose connector: I had 3 severe crashes with the Easy Star the last years but the Gumstix and the connecting mother board are still working fine. The biggest disadvantage however is EMI. I am still struggling with shielding and opto couplers to get a "clean" EM environment.

When I started dealing with autopilots 5 years ago, I could hardly estimate how much computing power would be necessary for the task of sensor data fusion and navigation. Back then, the Gumstix was a good choice for me. Today I am looking for a even smaller 32-bit system mainly for space and EMI reasons.

Regards, Achim.
If you find one please let me know. I've been looking for something like gumstick but without the tiny connector. I looked at the Netburner Jack suggested but cannot find much support for it.
Though I am new to DIY Drones, I'll take the plunge and disagree with some previous comments regarding ROI on a Gumstix based auto-pilot.

The Arduino platform is terrific, no doubt, but I'd say its best fit comes for sensor / pwm applications. For anything more advanced, they just don't pack enough crunching power. Neither do Netburner modules. Sure, they might suffice for simple GPS waypoint navigation, but not for computer vision guided UAVs.

Think of autonomous surveillance UAV capable of processing real-time video with GIS data, object localization and tracking or complex swarming modes to name a few. Even basic SW video stabilization requires a lot of processing power and for us mere mortals and hobbyist UAV aficionados, the Texas Instruments OMAP3 based SoCs such as the Gumstix Overo are one of the few viable and cost effective options out there. The best part is they come packed with a PowerVR SX530 GPU and beefy DSP letting us offload the video processing routines.

If you need them any smaller have a look at Logic's OMAP3 SoC. If you need any more, consider tiny Overo clusters. The tools are readily available both commercially and open source. There's a myriad of libraries and applications ready to run OOTB or with few modifications. No special programmers / interfaces required. You can easily test on a BeagleBoard if you prefer the ease of connectivity it offers and then deploy to and Overo later on.

IMO, those are all key points that differentiate the OMAP3 SoC such as the Gumstix from most other auto-pilot platforms. Sure, you pay a little more, but you receive A LOT more too! It boils down to what you wish to do with your UAV project. If it's to fly around autonomously, an Arduino or similar will do it justice and be cheap to boot too.

If you want your UAV to become a platform for performing interesting / useful autonomous tasks or do anything with RT video processing, the Gumstix Overo quickly becomes the most cost effective solution available today and I'd think it should suffice for many hobbyist UAVers for years to come.

Speaking of Gumstix based UAVs, head on to the PixHawk project for an extensively documented project!

The NetBurner can do interesting things....


Full disclosure I work at Netburner.
I have libraries that will send and receive servo pulses with the NetBurner modules.
I'm currently building up a Netburner MOD5213 based autopilot for fun...

Something that popped up on my radar recently is http://www.xduino.com/ a full 32bit ARM Cortex 3 chip and a stack of rom/ram. The only thing it appears to really lack is a suitable number of PWM IO for driving servos/ecs/etc as it had 2 12-bit DACS. I it may be that the 48 pins of GPIO can be used as PWM but I cannot find any supporting evidence.
Have you got any ADC libraries for the Netburner any chance ? I eventually bought A dnp/5280 which is also coldfire based but I didn't get the starter kit so no examples :(
Netburners 5282 module has ADC libraries built into the board support package.
cheers, I think what I'm really tried to find is some examples of how to use it. I had hoped to find some example for ADC, PWM and I2C on the net but there doesn't seem to be a lot around for the Coldfire but maybe I'm just not looking in the right places.
At Netburner we do things a bit differently than the freescale references....
We map the entire chip register set into a large structure 'sim' for easy access....
So the following code won't map directly to the freescale coldfire chip definitions, but with a little thought you should be able to translate.... its an example of how to set the QADC to run in the background and then get the latest value when you want it.
For things like an IMU where the exact sampling point matters one would want to enable the interrupt and trigger each set of A/D conversion rather than let them run free....

* Set up the QADC to continuously sample all 8 input channels, plus
* the Vrl, Vrh and Vmed channels. The results are stored the results.
* See the 5282 Users Manual, section 28, for reference.
void InitializeQADC()
sim.qadc.qadcmcr = 0x8000;
sim.qadc.portqa = 0;
sim.qadc.portqb = 0;
sim.qadc.ddrqa = 0;
sim.qadc.ddrqb = 0;
sim.qadc.qacr0 = 0x10; /* FQCLK = 66.355MHz/(2*(16+1)) 1.952MHZ AD clock and 2MHZ is maximum accuracy*/
sim.qadc.qacr1 = 0x1100; /* Continuous software scans in queue 1 */
sim.qadc.qacr2 = 11; /* Disable queue 2 with Queue 1 ending at position 11 */
sim.qadc.qasr0 = 0;
sim.qadc.qadcmcr = 0x0000;
asm(" nop");
sim.qadc.ccw[0] = 0xC0; /* Convert channel 0 see 5282 users manual table 28-16 */
sim.qadc.ccw[1] = 0xC1; /* Channel 1 */
sim.qadc.ccw[2] = 0xC2; /* Channel 2 */
sim.qadc.ccw[3] = 0xC3; /* Channel 3 */
sim.qadc.ccw[4] = 0xF4; /* Channel 4 (52) */
sim.qadc.ccw[5] = 0xF5; /* Channel 5 (53) */
sim.qadc.ccw[6] = 0xF7; /* Channel 6 (55) */
sim.qadc.ccw[7] = 0xF8; /* Channel 7 (56) */
sim.qadc.ccw[8] = 0xFC; /* Should return a measured 0 */
sim.qadc.ccw[9] = 0xFD; /* Should return a measured 1023 or max */
sim.qadc.ccw[10] = 0xFE; /* Should return half scale or 512 */
sim.qadc.ccw[11] = 0xFF; /* End of Queue Code */
sim.qadc.qacr1 = 0x1100; /* Continuous software scans in queue 1 */

* Returns the Right-Justified Unsigned Result Register (RJURR)
* value for the specified A/D input channel. Channel numbers for
* this example program are 0-7 for the external A/D inputs, and
* 8-10 for the internal references Vrl, Vrh, Vhalf.
* ----------------------------------------------------------------*/
WORD GetQADC( int ch )
return sim.qadc.rjurr[ch];

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service