MNAV/Stargate or homegrown

[modles]

Hi Guys

Firstly a hello, great to get involved with this forum, im sure it will help me alot with my UAV project and I promise to help out other whenever I can.

My first question is on of sensors and microcontrollers. The big decision at the moment is whether to go with a solution such as the MNAV/Stargate or to build my own using individual sensors such as http://www.sparkfun.com/commerce/product_info.php?products_id=758 and controller such as the basicx stamp.

I guess I am asking your opinion on pros and cons for both routes.

Some questions that spring to mind... Does the stargate provide enough room for expansion? I know usb devices can be hooked up but what about if i want to use I2C sensors, can i use them with it?

One thing thats really edging me towards the Stargate route is the fact that I have no experience with Kalman Filter code, and to be honest it scares me. I would rather have the accurate (well as acurate as it can be) data provided to me and take the coding from that point.

Other packages i have looked at...
http://www.sparkfun.com/commerce/product_info.php?products_id=8189
http://www.sparkfun.com/commerce/product_info.php?products_id=754


Thoughts, suggestions?

Many thanks

Ben

[phubner]

Ben,

I'm not familiar with the MNAV Stargate, but I've opted for building my own. Though I'm an engineer, I'm new to embedded designs. I have selected a solid chip from www.Parallax.com (coincidentally named the Propeller chip) as my main processor. There is a vibrant community forum and many processor functions (like servo control) have already been done at one level or another.

I'm building first a return-to-home function based on GPS to aid my UAV piloting if the video breaks up. Here is a list of my projects at a high level that should be doable on one chip:

1. Return Home feature (GPS based)
2. Glass Cockpit - Passthrough and overlay data on existing video downlink
3. Wing leveler
4. Pattern Flight - Preconfigured patterns relative to GPS location ie smoothly fly a 100m circle around a point.

The project board is only $20 so I figure I cant go wrong!
Good Luck and post your progress,
Paul

[clolson]

I think from my perspective, it boils down to whether or not you like (or want) to build electronic hardware. The MNAV gives you a lot of functionality out of the gate, but it's in the $1500 range for price. Add another $200 for a gumstix to run the sensor integration and autopilot code ... and with other spare bits and pieces, you are probably easily pushing $2000 before all is said and done (and that doesn't include ground station, the airframe, or any other payload/camera you might want to fly onboard.)

So the questions should be: What do you want to do? What are you able to do? How do you want to balance time versus money? Building something from scratch will take a lot longer than you think. But the MNAV is not flight ready either ... that will take some significant integration and software work to get flying as well.

Curt.

[modles]

Thanks for your replies

I guess time is more valuable to me than money at the moment, so having a large chunk of the work done already sounds appealing. The gumstix board is being mentioned here, is there any reason other than size to go for this rather than the stargate? does it connect easily to the mnav?

what are the areas that make MNAV not flight ready?

Thanks

Ben

[clolson]

I guess time is more valuable to me than money at the moment, so having a large chunk of the work done already sounds appealing. The gumstix board is being mentioned here, is there any reason other than size to go for this rather than the stargate? does it connect easily to the mnav?

what are the areas that make MNAV not flight ready?


I figure about $200 for a gumstix and $500 for a stargate. There are some I/O differences which may or may not matter depending on what all you want to do. The gumstix connects just fine to the MNAV, but the stock MNAV-1.4 code gets hung up in some sort of threading deadlock on the gumstix. With my code, I went with a single threaded design ... there's no loss in the original functionality and it greatly simplifies the structure and understandability of the control flow.

I'm not a hardware guy so for some of these things, others might just breeze on through without a second glance, but took me a while to get up to speed with how to power it. Xbow recommends a 3.7v lipoly battery, but try finding a place that will sell a 3.7v lipoly battery with any kind of connector soldered on. We finally found a source, for 1320mAh 3.7v lipoly batteries, but we get abysmal performance of these batteries in cold weather ... maybe 1 hour run time at room temps, but only 5-10 minutes in sub-freezing weather. I finally grabbed a 4.8v 1200mAh nimh receiver battery and I get 1.5 hours run time in the same cold temps and maybe 2-3 hours at room temperature ... so as you might guess, right now I'm leaning towards using the 4.8v nimh receiver battery as my power source. That's easy enough, but took me a long time to get there.

Another thing you'll need to do yourself is modify your receiver to tap the ppm signal off the radio decoder board. In my case I lucked out and we have a really smart grad student that knows how to do these things, so I just hand him the receiver and tell him he'll never graduate unless he does the needed modification. Works like a charm. :-) The ppm signal is needed to feed into the MNAV so it can read transmitter inputs and impliment it's built in manual override mode. However, this act of tapping the ppm signal greatly reduces the range of the receiver ... in my case range is reduced below the required tolerances for safe flying.

So I bought a standalone manual override board (Jay@reactivetechnologies.com) so that I can fly with a separate primary receiver and feed the mnav with a crappy-range secondary receiver ... but that secondary receiver is looking like it might cause more problems than it's worth. I might just need to go 100% autonomous in autonomous mode and then pop out to this standalone manual override mode if anything glitches. My preference would be to pass through all the channels except for the autopilot axis I'm working to tune, but this system will probably not allow me to do that safely or reliably.

They Xbow MNAV system is really open ended ... you get sensors, you get a flight computer, you get some sample code to implement a kalman filter and a simple autopilot. But as you dig in, you will start to realize their sensor integration code is very basic, very simplistic, and has many warts and problems and deficiencies. It's not at all close to the quality that you'd get from a self contained proprietary system. I guess that makes sense ... they don't want to give away all their secrets for free ... but the down side is they build in some serious deficiencies into the MNAV system they are selling.

I'm tempted to use stronger language, but I'll just say that you will probably need to do significant code work both on the stargate/gumstix level as well as some work fixing problems in the MNAV firmware itself. There is a significant servo jitter issue with this unit, probably largely due to code issues in the firmware, but I'm speaking a bit speculatively here because I personally haven't dug into the firmware code myself ... just passing along heresay. To be fair, I hear from Xbow that they plan to have significant servo jitter improvements in their upcoming units.

I don't want to scare people away from the MNAV ... it gives an immense bang for your buck relative to the current competition out there. It's the horse we've chosen to ride for a couple of our projects at the University of Minnesota. It's just that there is some non-trivial (at least for me) hardware integration that needs to be done, and some non-trivial software work that needs to be done in order to do anything useful with the unit.

Part of my goal is to fill in the gap on the software side with a significantly improved flight computer application. Then hopefully my hard fought experiences on the electronics and hardware side (where I tend to struggle a lot more) can at least help move people faster through the hardware integration phase. And I'm a big fan of FlightGear so much of what I'm doing on the software side is designed to be able to plug into and work with FlightGear ... i.e. to simulate an aircraft and do autopilot development and gain tuning in software before trying it for real, using FlightGear to visualize a flight (in real time or after the fact) including actual control surface deflections, using FlightGear to generate real time instrument panels and engineering displays. And then there are a number of directions you could branch off from there to leverage various features and capabilities of FlightGear to do some stuff that at least I think would be interesting.

Right now I have most of my hardware in place and ready to go. So my big push in the upcoming days will be to get my configurable autopilot code up to speed so that when our snow cover melts down enough to fly again, I'll be ready to start testing and refining my autopilot code in ernest.

I think at the end of the day, some of the issues and problems with the MNAV will limit what we would ideally like to be able to do, but I think we'll still be able to do quite a bit of useful and interesting things with it. And I know that Xbow isn't sitting on their butts with this. They are actively pursuing some of these issues and continue to work at improving their MNAV firmware. The MNAV is still a pretty young product, I don't think there are many groups that have it in the air and doing much of anything yet. Other than one group that managed to hover a helicopter with it a year ago, I feel like I'm probably one of the furthest along towards autonomous flight ... unless there are proprietary mnav-based efforts out there I'm not aware of.

Sorry for the extensive brain dump ... but my fingers seem to have an autopilot mode of their own and once I get typing it's hard to stop them. :-)

[modles]

wow, thanks for that brain dump!

after a long hard think, Ive decided (how long it will last i dont know) to go for a 6DOF IMU hooked up to a gumstix. Ive found some guys greating great kalman filters etc for the spark fun IMUS and gumstix. Seeing as GPS is not an initial requirement of my uav (small indoor), an IMU should be sufficient. Plus im going to save around $1000 which will help go towards covering lost income due to spending too much time on this thing :) and probably a couple of meals out to get the missus back on side!

ill let you know how it goes.

[Unterhausen]

modles, are you talking about the kalman filter on the sparkfun forum?

[modles]

yeah, thats me. ideas changing every day as i find new options

[treehog]

@ clolson

Very informative. i have tried to utize the flight gear but didnt get very far

will come back to to this thread and flight gear issues in the near future if I cant crack the problems

Ralf

[clolson]

Very informative. i have tried to utize the flight gear but didnt get very far

will come back to to this thread and flight gear issues in the near future if I cant crack the problems


FlightGear has many sides to it. You can load it up and just play with it like any end-user application. But it also can be thought of as a tool box or collection of parts and tools that together with other things, can be used to build a larger, more capable system.

When it comes to applications like UAV's, you have to think of FlightGear more like a stack of lumber and a garage full of tools. It's up to you to build what you want ... but that takes some effort and there is a bit of a learning curve. And flightGear is just one piece of a much larger puzzle.

Curt.