gumstix + xbow mnav?

[clolson]

When I search through the forums I find numerous references to gumstix and I find numerous mentions of the xbow micronav.

I have one of each on my desk here and I am trying to run the xbow open-source code on the gumstix instead of the stargate that it is designed for. (The gumstix and the stargate use the exact same xscale cpu running at the exact same clock rate...)

I find that my code (which works fine on the stargate) starts running, but quickly locks up and doesn't proceed when run on the gumstix. I suspect it's related to some sort of threading issues on the gumstix but I haven't had a chance to try to come up with a test program that is non-threaded.

Has anyone out there connected an xbow mnav up to a gumstix and achieved anything useful?

I see many advantages to using a gumstix instead of a stargate if I can get this to work ... such as much more flexibility with mounting and installation and much less fuselage width required. Much more modern software platform (newer gcc, 2.6.x kernel, etc.) I also kind of like the blue tooth option, the cost, and the expandability.

Thanks,

Curt.

[Unterhausen]

cost is much better. I wouldn't have expected any problems at all. I have a batch of Gumstix -- the size alone would be a big advantage.

Are you sure it's not an electrical problem?

[clolson]

cost is much better. I wouldn't have expected any problems at all. I have a batch of Gumstix -- the size alone would be a big advantage.

Are you sure it's not an electrical problem?

I'm running everything off A/C power. The MNAV works well when connected up to Microview. The gumstix has been rock solid on everything else. I independently verified that the 2nd serial port (where the MNAV is/will-be connected) is working fine on the gumstix.

Right now I really think there's some difference in the threading support that is causing the program to dead lock right away when running on the gumstix. I'm hopefully going to test that theory by coming up with a single threaded test app that just talks to the mnav.

I've not been a big fan of the way xbow set up their threaded avionics app. By my reading of their code, their threading accomplishes basically nothing other than to add complexity. All their threads block on each other so if something stops running (i.e. your MNAV comes unplugged) all the other threads block, waiting for a signal from the MNAV data acquisition thread, but if that thread is sitting there waiting for data that will never come, it will never give it's signal to the other threads, so you are dead in the water anyway. What can an autopilot do intelligently if it completely and abruptly loses all it's sensor data? Center the controls? Pull the throttle back? Go into some sort of fail safe mode?

I asked Xbow about their threading implementation, and got back some generic answer about running the state estimation loop even if sensor data blips out for a while, but unfortunately, I don't think their code works the way they wish it did.

Ooops, I probably should have put "Warniing editorial content" at the top of this message. :-)

Curt.

[Unterhausen]

Are you using the Hirose connector, or the .1" header that microview hooks up to? I thought that all the data came across on serial port 0. Serial port 1 just has the GPS. That's what it says in the manual, could be wrong I guess. Does the Stargate have extra serial ports? I'm starting to think you have a simple connectivity problem -- that's because it happens to me every time I try to connect two things together.

The avionics can't do anything if it loses contact with the micronav -- no actuators. The micronav has to be programmed to do something intelligent.

I don't mind a good rant. The code isn't the best, but at least you get to see their dirty laundry instead of staring at a black box wondering why strange things happen. I must admit there are days when I wished I spent $50k on my autopilot/software/source code, but not too many. This is far more entertaining.

Threads blocking on each other sorta makes sense if the time base is external hardware -- is there a good mechanism to have a sample rate that isn't based on the micrnav itself? But what you say does make me wonder if they either are too tightly coupled, or they shouldn't just be using one thread.


I have never even booted a gumstix, I've just been too busy since I bought them. I want to have a cluster of gumstix in my airplane doing processing, they weigh just about nothing, so I should be able to get as many as I can support with my batteries.

[clolson]

Are you using the Hirose connector, or the .1" header that microview hooks up to? I thought that all the data came across on serial port 0. Serial port 1 just has the GPS. That's what it says in the manual, could be wrong I guess. Does the Stargate have extra serial ports? I'm starting to think you have a simple connectivity problem -- that's because it happens to me every time I try to connect two things together.

The avionics can't do anything if it loses contact with the micronav -- no actuators. The micronav has to be programmed to do something intelligent.

I don't mind a good rant. The code isn't the best, but at least you get to see their dirty laundry instead of staring at a black box wondering why strange things happen. I must admit there are days when I wished I spent $50k on my autopilot/software/source code, but not too many. This is far more entertaining.

Threads blocking on each other sorta makes sense if the time base is external hardware -- is there a good mechanism to have a sample rate that isn't based on the micrnav itself? But what you say does make me wonder if they either are too tightly coupled, or they shouldn't just be using one thread.


I have never even booted a gumstix, I've just been too busy since I bought them. I want to have a cluster of gumstix in my airplane doing processing, they weigh just about nothing, so I should be able to get as many as I can support with my batteries.

Lot's of questions/comments here ... For the MNAV serial connection, I'm using a servo style connector feeding off pins 2,18,33 (a column of pins on the MNAV header.) The other end of the cable is a standard 9 pin serial connection. This works when talking to a PC running MicroView (Xbow's debugging and testing app.) And to spoil the suspense, it also works when talking to the gumstix.

Can't remember how many serial ports the stargate has ... one externally usable I think, but if you get out your solder iron, I think you can expose another one ... saw a web site that explained it all somewhere, but have lost the link.

In terms of rants ... half of the point of a good rant is that I'm never 100% sure I'm exactly right. So I'm hoping (really!) that someone knows better than me will be slightly (or extremely) :-) offended and be willing to take the time to explain to me where I went off track. So the more I rant and no one corrects me, the more I think I might actually be on to something.

My initial honeymoon with the gumstix is starting to wear off as I run into some issues I can't immediately solve and am having difficulty finding appropriate documentation. But I'm sure I'll work through these issues eventually. Overall I think the gumstix is a really great platform. I'm 98% extremely impressed with it and the associated development environment.

So today I took my mnav code, and ripped out all the threading and rigged it so it just activated the MNAV and fetched data from it as fast as the MNAV sends it. That works! So there is something about threads on the gumstix, or something about how the MNAV structures it's threading calls, that causes the code to deadlock when running on the gumstix. I'm going to proceed to just rip out all the threading and I think I'll be much happier in the long run.

I'm going to probably do a number of things with this code that could offend some people's sensibilities, but what the heck, it's open source so if people don't like it, they can write their own. :-)

If I had to guess, I would guess that there's nothing wrong with the gumstix threading implementation and that the problem is in the MNAV code ... something they inadvertently did worked ok on the stargate (older kernel, older compiler, etc.) but they can't get away with the same mistake on a newer kernel with a newer compiler ... that's just my current theory though ...

Curt.

[clolson]

Just another quick update on my progress.

It's slow going here, but I have the gumstix computing the attitude estimates and getting very plausible looking numbers. The code is in place to compute "nav" estimate from gps, but I'm a moron and forgot to bring home the gps antenna so I can't test that out. But it all looks very promising. I'm doing quite a bit of code reorg to remove the threading, and as I progress with that I continue to see less and less need for a complicated multi-threaded architecture ... other than to score cool points with your fellow engineers.

I think I'm going to *really* like this combination of Xbow MNAV + GumStix ... it might just be the way to go if you want an advanced, full featured, programable autopilot, but aren't able to cough up $5-10k or more for one of the popular commercial solutions. Looks like once I get a bit further with the coding, I'll be able to put something together in the $2000 - 2500 range for hardware. Still not cheap, but hopefully this will become an interesting option to consider ... especially for people who want or need to get in and fiddle with the sensor integration code, or the autopilot code.

I could start to ramble on and on here, but I've got all kinds of ideas for "smart" and flexible autopilot behavior that go far beyond following a series of waypoints ... we'll see, that's the direction I want to head, but how far I can run before I hit the end of my gumstix rope. I'm imagining the dog chasing the chicken in the old looney toons cartoons ... :-)

Curt.

[Unterhausen]

Curt,
are you using the tweener board on the Gumstix?

Using a gumstix would definitely change the class of airframe that can use a micronav to a much wider selection.

What version is the compiler on the Gumstix? The newer compilers are much more strict, but then again that's supposed to help you catch things at compile time. You are probably right about the threading, my guess is it has changed since the linux that runs on the stargate was put together.

[clolson]

Curt,
are you using the tweener board on the Gumstix?

Using a gumstix would definitely change the class of airframe that can use a micronav to a much wider selection.

What version is the compiler on the Gumstix? The newer compilers are much more strict, but then again that's supposed to help you catch things at compile time. You are probably right about the threading, my guess is it has changed since the linux that runs on the stargate was put together.

The gumstix board I have been playing with already has a serial/console port (it has two external serial ports.) So I can burn one of them to talk to the MNAV and one of them to talk to my ground station via a radio modem.

Yes, the MNAV+gumstix combination gives you *much* more flexibility in your mounting and packaging. The MNAV+StarGate pretty much burns up the full width of our Rascal 110 cockpit. You could actually think about putting a MNAV+gumstix into a smallish conventional fuselage (for an electric or small glow trainer.) I've got a 49" wing span Rascal "C" which would be a tempting target ...

The gumstix buildroot environment allows you to pick one of a variety of gcc versions. I went with 4.1.1 which was the most current they make available. The gumstix build root has a "clunky" selection/configuration interface, but it's very cool in that it let's you select your compiler, select build options, and select the various source packages you compiled and installed on your root image (and thus are available to run natively on board your aircraft.)

After my original post, I ported my gumstix code back to the StarGate+MNAV (which is virtually no different software-wise from the gumstix) and ran the code with the gps working and the radio modem working. It's all coming together pretty well. My code should be able to run equally well on both the stargate and the gumstix.

I'll be watching for a decent day to fly this week or next ... the sand walls protecting the MNAV from doing useful autonomous flight are starting to collapse on all sides. :-)

[Unterhausen]

we actually put a bubble window/scoop on the Sig Kadet Sr to poke the wifi card out the side just a little. It also allows extra airflow, which seemed like a good idea considering the power supply gets warm.

I didn't think that there were rs232 level shifters on the gumstix, have to go back and look at my options.

[Vindication]

clolson-

Just wanted to drop a line and say I'm really excited you are working on the gumstix unav combo as we discussed a long time ago. Congrats!

-Vind