Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on December 14, 2009 at 4:34pm

The only two Gumstix projects I know of are these:

Fixed wing

Heli

The general problem with them is that they're relatively expensive and need a lot of supporting parts to make an autopilot.

• ▶ Reply

Permalink Reply by Heinrich Mueller on December 26, 2009 at 1:08am

For the interface you can use a part of the HB-Autopilot fond here:
http://www.akaflieg.hs-bremen.de/trac/akaflieg/wiki/airborne/hw/aut...
https://www.akaflieg.hs-bremen.de/trac/akaflieg/wiki/airborne/hw/qc
http://paparazzi.enac.fr/wiki/Tiny_v3
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
http://www.voidpointer.de/rsimu/index_en.html

• ▶ Reply

Permalink Reply by Jack Crossfire on December 26, 2009 at 2:02am

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.

• ▶ Reply

Permalink Reply by Achim Walther on January 10, 2010 at 2:59am

Hi,

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.

• ▶ Reply

Permalink Reply by James Turner on January 10, 2010 at 4:08pm

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.

• ▶ Reply

Permalink Reply by Pbreed on January 22, 2010 at 11:42am

The NetBurner can do interesting things....

http://www.youtube.com/watch?v=8UJDxp2gv3o

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...

Paul

• ▶ Reply

Permalink Reply by James Turner on January 22, 2010 at 2:31pm

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

• ▶ Reply

Permalink Reply by Pbreed on January 22, 2010 at 2:50pm

Netburners 5282 module has ADC libraries built into the board support package.

• ▶ Reply

Permalink Reply by James Turner on January 22, 2010 at 3:19pm

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.

• ▶ Reply

Permalink Reply by Pbreed on January 22, 2010 at 4:00pm

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

Permalink Reply by James Turner on January 22, 2010 at 4:20pm

That's a great head start and I'm sure I will be able to work something out from this. Thanks very much.

• ▶ Reply

Permalink Reply by Karloff on January 21, 2010 at 6:52am

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!


Regards,
Karl

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page