O-Navi Phoenix vs. XBow MicroNAV

[AeroJDK]

I'm looking at buying a UAV autopilot system and have narrowed it down to O-Navi's Pheonix and Crossbow's MicroNAV. I've been trying to read the differences between the two models and have spoken with both companies, but I wanted to throw the question out to you guys and see if anyone has experience with using both of them or one of them, and what your impressions are. I am a fairly decent programming and have access to programming help when needed, so that side of it is pretty well covered. Any feedback or input you could provide would be great. Thanks for all the help...

AeroJDK

[hugo_vincent]

Hi,

First: disclaimer, I haven't used either system, so this is based only on what I have seen and heard.

I would go for the MicroNAV/StarGate combo. Embedded Linux is a really nice development target. Also, (most of) their code is open source.

Cheers,
Hugo.

[haakworks]

Hi

I was involved in the testing of CrossBow uNAV. Since I don't have an experience with the O-Navi unit, I can't compare, but I think the uNAV provides excellent development environment. You can tune all the gains on the fly so that you don't have to constantly land the airplane.

They demonstrated quite robust way point navigation using Zagi Tazz.

Good luck,

Hak-Tae

[AeroJDK]

Is it fair to say that the MicroNAV unit is really not all that it could be without the Stargate add-on? I've tried to read online about it, but it's very difficult to get info on the Stargate on XBow's website, so I'll ask it here: what exactly does the Stargate bring to the table? I understand that you directly plug the MicroNAV into the Stargate and the Stargate itself is a mini-computer, but what can the MicroNAV/Stargate combo do that the MicroNAV can't do on its own? Again, thanks to all for the help...

AeroJDK

[clolson]

Is it fair to say that the MicroNAV unit is really not all that it could be without the Stargate add-on? I've tried to read online about it, but it's very difficult to get info on the Stargate on XBow's website, so I'll ask it here: what exactly does the Stargate bring to the table? I understand that you directly plug the MicroNAV into the Stargate and the Stargate itself is a mini-computer, but what can the MicroNAV/Stargate combo do that the MicroNAV can't do on its own? Again, thanks to all for the help...
AeroJDK

Let me try a quick explanation.

The MicroNAV provides:

- 3 axis gyro (raw)
- 3 axis accelerometer (raw)
- 3 axis magnetometer (raw)
- gps
- static and dynamic pressure sensors
- some sort of temperature sensor for gyro/accelerometer calibration
- ppm signal decoding (to read your receiver output)
- ability to drive servos (I forget how many, maybe 8?)
- communication to and from the unit is via a serial port.

The MicroNAV supposedly gives you really good temperature calibration (tested and setup at the factory.) They also supposedly do a lot of work to mathematically compensate for small mounting alignment errors (i.e. when the sensors aren't all exactly orthogonal.) Finally they supposedly do a really good job of handling high vibration situations. I watched a xbow presentation where they showed graphs of all these properties relative to 2 unamed "competitors" and of course xbow was *way* ahead of them in all respects. I don't know how much of that was honest truth and how much of that involved picking the worst competors possible, but it looked really impressive in the presentation. And I did appreciate that they consider temperature calibration, sensor mounting error compensation, and vibration handling when they designed the unit. It tells me they aren't just shipping out crap, they've put a lot of thought and experience into this unit.

What this does *not* give you is a kalman filtered attitude and position solution. it also doesn't give you and autopilot code. You only get the raw sensor outputs (plus the ability to interface with standard R/C hardware.)

The stargate is a little embeded computer. That's all it is. It gives you a processor (XScale 400), usb ports, serial ports, compact flash port, pcmcia port, and ethernet. It runs linux.

XBow provides open-source kalman filtering and example autopilot code that runs on the stargate. So when you plug the MicroNav into the stargate and run their code on the stargate, you get a full kahlman filtered gps/ins/imu solution at pretty good update rates. The gps position is augmented by the inertial sensors, so you can get faster position rates than the gps spits out natively, etc. And it's all open source.

Theoretically, you can plug the MicroNav into *any* computer that has a serial port, compile their kalman filtering/autopilot code and run that way (i.e. gumstix, ye olde pc, etc.)

For a software guy, the micronav + the open-source kahlman filtering code just makes me grin from ear to ear. It's way cool, because I can get in there and write my own PID code, develop my own autopilot modes, tune my ground station communication protocol, add battery monitoring and other sanity checks, etc. It's all there and wide open to play with. The down side is that if you aren't a software guy (or don't have a software person handy), the MicroNAV/Stargate will be more difficult to get running than one of those off-the-shelf pre-programmed autopilots, where you just plug it in, point the arrow forward, and you are doing autonomous take offs and landings 15 minutes later.

Curt.

[AeroJDK]

Curt --

Wonderful explination...thanks a ton. I am a software guy (little C, lot of Visual Basic) and I know someone who knows C quite well, so I don't think this will be a problem. What I am curious about now, after that explination, is how the Kalman filtering works. Is it treated somewhat as a subroutine that will "condition" the 6DOF and GPS and then allow me to take those values and use up in the main autopilot code? I understand Kalman filtering somewhat, but I am not expert, so from where I sit, it sounds like that's a great thing to have but I'm not sure how difficult it is to implement it with my own custom PID routines. Again, any help or insight you could give would be most appreciated, and thanks again for the help thus far.

AeroJD

[clolson]

Curt --

Wonderful explination...thanks a ton. I am a software guy (little C, lot of Visual Basic) and I know someone who knows C quite well, so I don't think this will be a problem. What I am curious about now, after that explination, is how the Kalman filtering works. Is it treated somewhat as a subroutine that will "condition" the 6DOF and GPS and then allow me to take those values and use up in the main autopilot code? I understand Kalman filtering somewhat, but I am not expert, so from where I sit, it sounds like that's a great thing to have but I'm not sure how difficult it is to implement it with my own custom PID routines. Again, any help or insight you could give would be most appreciated, and thanks again for the help thus far.

AeroJD


You probably know more about kahlman filtering than I do, but essentially what the stargate/xbow code does is process the raw sensor data and output a roll/pitch/yaw estimate at some fixed rate (50hz?) and a lon/lat/elev estimate (25hz). So you can keep that code as is (I wouldn't know enough to touch it) and replace all the autopilot and servo control code with your own.

I have this dream of setting up a flight control mode where the system behaves much like an airbus. Your stick inputs command a roll and pitch rate, and when you center the sticks, the system holds the current roll and pitch. I can imagine some smooth flying at the flying field and impressing my buddies with how good I am (but of course under the hood I would be blatently cheating.) :-)

Curt.

[Tuner]

I just wanted to point out the Paparazzi Project. It requires more leg work on your end. But it comes with a great community of developers that seem very willing to help out and work with people.

http://www.nongnu.org/paparazzi/

They have an IRC room that people are in all the time due to developers being in Europe and US.

More leg work to get a stable setup but also more flexibility and support at a low cost.


Scott

[AeroJDK]

Wow...that would be sweet. Again, thanks for the insight. So from what I gather, there exists source code for the Stargate side of things as well as the MicroNAV side of things. The autopilot code runs on the Stargate (?) and talks to the 6DOF and servos through a serial connection (?), which connects the stargate to the MicroNAV (?)? The source code is in C (?) and is changed directly on the Stargate, meaning connecting to the code is rather simple as there is an additional serial connection on the Stargate (?) as well as Ethernet, etc. (?)

AeroJDK

[Medve]

What would you guys reccomend for rest of us peseants who don't know programing?
Yes, I live in the silicon valley, but I'd really prefer a plug and play system for now.

[clolson]

Wow...that would be sweet. Again, thanks for the insight. So from what I gather, there exists source code for the Stargate side of things as well as the MicroNAV side of things. The autopilot code runs on the Stargate (?) and talks to the 6DOF and servos through a serial connection (?), which connects the stargate to the MicroNAV (?)? The source code is in C (?) and is changed directly on the Stargate, meaning connecting to the code is rather simple as there is an additional serial connection on the Stargate (?) as well as Ethernet, etc. (?)
AeroJDK

There is source code for the stargate (kahlman filtering, autopilot, pid, ground station communication.) I don't know if there is code for the micronav, but that is more of a raw sensor head so you don't really need/want to mess with programming it. The stargate code is written in C and can be pretty easily ported to any platform running unix.

Connection to the stargate is straightforward via ethernet, wireless, or serial.

You can't program on the stargate, you have to cross compile on a host computer (typical embedded programming stuff) and then upload the binary to the stargate (with ssh or zmodem)

Curt.

[AeroJDK]

Interesting...so buying the MicroNAV would almost definitely require some sort of external processing? Is it true that the 6DOF and GPS info are being sent over a serial connection to the Stargate? Do you know if the Hz at which that data is sent is adjustable? Also, how exactly do the servos play into this...I'm assuming they can be controlled with the Stargate via commands sent over the connection between the two devices, and same with the pilot control commands but in the opposite direction. Again, thanks for all your help on this stuff...I just want to make sure it's going to do what I want before I jump in and buy it. Does anyone know if there exists more information on this device than simply what is on the website?

AeroJDK

[clolson]

Interesting...so buying the MicroNAV would almost definitely require some sort of external processing? Is it true that the 6DOF and GPS info are being sent over a serial connection to the Stargate? Do you know if the Hz at which that data is sent is adjustable? Also, how exactly do the servos play into this...I'm assuming they can be controlled with the Stargate via commands sent over the connection between the two devices, and same with the pilot control commands but in the opposite direction. Again, thanks for all your help on this stuff...I just want to make sure it's going to do what I want before I jump in and buy it. Does anyone know if there exists more information on this device than simply what is on the website?
AeroJDK

Unless you just want the raw sensor data, you need to plug the micronav into something to compute your attitude and position estimate.

Sensor data is sent over a serial connection to stargate (or other computer if you choose.)

I think the data rates can be adjusted, although the serial connection is a limiting factor in how far you can turn them up.

PPM signal and servos plug into the Micronav. Micronav will send transmitter stick positions along with other sensor data. You can send back servo position commands over the serial link.

There is a forum and more information at:

http://sourceforge.net/projects/micronav/

I believe there might be something for the stargate at SourceForge too.
Curt.

[jszeto]

Dear Everyone,

Please welcome to join this platform, for a FULL SEC UAV Project.

Gumstix is Software Embedded Control, so its exactly the advance solution!

We can build this easy upgradeable UAV system together here, as an Open Source!

http://www.sourceforge.net/projects/full-uav-sec

Idea & Outline, (Module)
PXA 255 Hardware design,
Algorithms & Programming,...


Sonar Alti., Digital Compass, Expansion Interface, CAN Bus, Motor controller,-
Temperature, Servos --------------------> Gumstix -----> GPS
IMU, Pressure, Airspeed, ----> ADC’s --------> Gumstix -----> Comms Radio


Together we could have a complete system, in 6 months.

we only need to map servo to connect Gumstix, convert formula to program!
Ground control: Glass Cockpit (Open source)
Our system turnout to be far better, more flexiable & accurate than those -->
Xbow- MNAV $1719 (USD) / O-Navi - Phoenix $ 9XX !
And not even using Kalman Filter !!

Look forward to start task allocation!

Be a part of it, & Have fun !

Jeffrey

[ashvani]

Thanks all for the great info!!
Now here i have a rather a simple question.. but its bugging me a lot. uNAV has one connecter pin, numbered 35 for PPM input. This is where i have to connect my Radio receiver to take over as manual control. My question is, there is one port for battery, anad 6 others for 6 servos in the receiver. So how do i connect this with the uNAV and when there are 6 different channels... how can i connect all of them with one pin on uNAV?

Thanks,

Ashvani...

[clolson]

I hope I understand your question correctly. Disclaimer, I'm a software guy so forgive me if I don't get the hardware terminology quite right.

The unav is designed to take the raw (combined) ppm signal straight off the radio signal decoder chip on your receiver. Onboard the receiver that raw ppm signal gets passed along to a demux (?) that separates out the individual channels and sends the signals to the individual servos.

The unav needs you to tap off the raw combined ppm signal from the radio signal decoder chip so you need to crack open the case on your receiver, identify the correct pin, and solder a wrire on there. This is pretty detailed work and you'll probaby void your receiver warrantee. And it's not a job for someone like me who goes through about 10 meters solder to finally get two wires to stick together. But a good hardware person ought to be able to handle this pretty easily. So for myself, I found a good hardware guy to do this hack on our receiver. FWIW, this all could be considered a minus point for the unav, but once you get it all hooked up, it seems to work well enough.

Curt.

[Unterhausen]

Most recent code for the micronav runs at 50 Hz sample frequency. You can download the micronav firmware code and modify it. People are doing this for helicopter control.


I am contemplating replacing the Stargate with a Gumstix. This will allow me to use the stargate for camera and communications, and offload the radio communications from the Gumstix. It's just a thought at this time. I may also try it with a two Stargate system.

[clolson]

Most recent code for the micronav runs at 50 Hz sample frequency. You can download the micronav firmware code and modify it. People are doing this for helicopter control.

I am contemplating replacing the Stargate with a Gumstix. This will allow me to use the stargate for camera and communications, and offload the radio communications from the Gumstix. It's just a thought at this time. I may also try it with a two Stargate system.

This is heading off in a bit different direction, but does anyone here know where I would need to look to start finding info on upgrading my stargate to a newer kernel version (i.e. 2.6.x) and perhaps newer other things? Is there some big image floating around that I can just upload to the stargate and overwrite/clean/wipe everything that is currently there? Or is this sort of "upgrading" a bad idea? I'm not an embedded systems guy, so my hope is that I don't have to build my own kernels from scratch and boot strap the whole system from nothing ... I want to work on uav's not become a stargate embedded systems expert ...

My main motivation here is that I found a kernel module that will monitor my battery power voltage so I can generate a warning when my stargate power supply is waning. However, the kernel module is for 2.6.x and my stargate comes preloaded with 2.4.x How do I proceed?

Thanks,

Curt.

[AeroJDK]

I'm writing to see if there is anyone out there successfully programming for the PhoenixAV board. I have currently been thrust into a project where I'm using the board but need to load custom software onto the board. Programming isn't my problem as I've already written the C software and compiled it in a freeware Windows compiler. This, however, is where the problem begins: I can't figure out how to use GCC (via Cygwin in Windows) successfully to make the required S19 file to be uploaded to the board. Any help anyone could lend would be greatly appreciated, even if it includes a suggestion or two....

Thanks in advance,

AeroJDK

[Unterhausen]

did you use the GCC cross-compiler for the MCC-2114 processor? That should be able to generate the Motorola format Hex file. I assume there is some sort of programming tool to download.

[AeroJDK]

That's just it...I can't seem to find the proper cross-compiler. I found one for the MCore line in general and have been blindly copying command line switches from the internet to create S19 file. When I take them into the Programming software to verify the S19 file, I get errors, so I'm pretty sure I'm not compiling it correctly. Unterhausen - any idea on where to get that MCC-2114 specific cross compiler? Again, any and all suggestions would be most appreciated...

[Unterhausen]

i found an interesting answer on metafilter: http://www.google.com/url?sa=t&ct=res&cd=3&url=http%3A%2F%2Fask.metafilter.com%2Fmefi%2F14538&ei=2flARZ-FIqGUgAPmmemdCg&sig=__DXYMjGeRPqxr08cz3Fv1iCAeRpg=&sig2=HgFjU1W89gRn0OaS-d6MeA

The 'Info' file for the GNU ld has a section on writing linker scripts. They're not necessarily complicated; basically they just tell the linker, "Okay, put all the code in a section starting at address FOO, and all the initialized, read/write data at BAR, ..." and so on. A minimal one tells the linker "just stash everything in order starting at address 0", which might or might not be what you want; I forget if the 68k has interrupt vectors there or something.

Converting to s-records is as easy as invoking objcopy with "-O srec". (Objcopy is part of the GNU binutils that'll have been built along with the cross-compiler.)

If you already have the ability to write stuff for the board in assembly language, you could use "gcc -S" to produce assembly files from your C sources, but gcc might use a different set of mnemonics from what your assembler is using.

Also, I'd suggest asking in comp.arch.embedded for pointers (or read the recent posts there looking for a FAQ).

[Sauli Sarkka]

What kind of gimmickry does it require to slap a few additional sensors onto a uNAV + Stargate -combo? The idea is to add a laser scanner (USB, connects directly to the Stargate module AFAIK) and two ultrasound sensors to monitor distance above and below to obstacles. The ultrasound sensors are the biggest question here. Does the uNAV have additional input-pins for more sensors? What about Stargate? Would I need some sort of USB input stage to convert A->D so that Stargate could understand the additional sensors?


-Sale

[Unterhausen]

the hokuyo laser scanner would work pretty well, I've thought about that, but it only has a 16ft range. Don't think it would be easy to hook up to the micro-nav. Not much documentation, and my understanding of the circuit is that they use external a/d, so there probably aren't any extras.

The stargate with the daughter card has a usb host port, so adding on there should be relatively easy. In addition, there are lots of serial ports.

[Sauli Sarkka]

The 16ft range doesn't limit us in any way, since the aircraft will need proximity data mostly when indoors. Outside it's the GPS and inertial sensors, etc. that handle navigation/motion.

Are there any plug&play proximity sensor packs available?

EDIT: What daughter card are you referring to go with the stargate?
EDIT2: Duh, the module's daughter card, that has several available ports.. :p


-Sale

[Unterhausen]

my previous answer probably wasn't too clear. They Hokuyo would work fine with the stargate in serial mode, the usb mode puts out tons of data, and may be too much. Player/Stage robotics software has a driver for the Hokuyo, and since people have compiled Player for gumstix, I assume it would compile for the Stargate. Problem is the price is nearly $3k in single quantities. http://www.hokuyo-aut.jp/products/urg/urg.htm

[Sauli Sarkka]

We already have the scanner, so that won't be a problem and it's exactly the one you mentioned (lucky us! :) .

So if we were to connect the scanner via RS-232, we'd have to communicate with the stargate via WLAN or Ethernet (not a problem, as long as it's reliable) - am I correct?

Has anyone had any real experience with using this scanner with a Stargate? The large amount of data the laser outputs did in fact raise thoughts about its usability via USB.

The next step in the design is to find a suitable USB front end for two proximity sensors (up/down) for landing assistance and obstacle avoidance. Since the unit (MNAV + SG) will also be used indoors, we need to investigate the stability of the software with the GPS either disabled or just not having a decent link to satellites. (Navigation indoors would naturally occur by using the scanner and proximity sensors)

Thanks for the help so far :)


-Sale

[AeroJDK]

It's been a while since I started this thread and I got sidetracked, but I wanted to thank everyone for their input. One remaining question I still have is regarding programming the O-Navi: is there a way to do this on a standard PC (even by installing Linux) without having to purchase the Motorola programming kit (~$5,000)?

I've been looking around for quite some time now, but I simply haven't found the right packages to put together to be able to make this happen. I'd like to avoid spending the $5,000 but in the absence of an alternative, it looks like I'd have to if I were to use the O-Navi.

Thanks again for everyone's help...

[Valerio07]

I have some problem with my mNAV configuration settings.

This is my setup:

1) hook the PPM signal from RC receiver (JR mod R700, PPM receiver)

2) "ppm.h" : we change the following parameters :
PPM_RX_TYPE 2 (it was 1 but we use JR receiver)
FLIGHT_MODE=0 (RC mode forced)

3) compile & upload the MNAV firmware

4) connect the MNAV to radio receiver by "PPM-INPUT"

5) power on MNAV and Radio Receiver
(only red led goes on)

6) power on transmitter

7) open PPM GUI from "Micro View" : I can see 31918 in each column

The problem is that i am not able to change the values working on transmitter.

What goes wrong?

Hope in your help.
Reagrds
Valerio

[clolson]

Now that Xbow has officially discontinued the MNAV, I have been hunting around the net for other options. The O-Navi Phoenix AX seems to be the closest things I've found so far to a device that covers most of the same functionality as the MNAV (without being a full blown, commercial, closed source, proprietary autopilot.)

Has anyone out there developed and flown a Phoenix AX based autopilot. Anyone have comments or opinions? Are there any drawbacks to the o-navi phoenix? Can any one comment on how it directly compares to the MNAV?

Thanks in advance,

Curt.

[Albe]

Now that Xbow has officially discontinued the MNAV, I have been hunting around the net for other options. The O-Navi Phoenix AX seems to be the closest things I've found so far to a device that covers most of the same functionality as the MNAV (without being a full blown, commercial, closed source, proprietary autopilot.)

Has anyone out there developed and flown a Phoenix AX based autopilot. Anyone have comments or opinions? Are there any drawbacks to the o-navi phoenix? Can any one comment on how it directly compares to the MNAV?

Thanks in advance,

Curt.

My MNAV did not survive a crash and now I am in the same exact situation.

Curt, did you find an answer on your own since your last post?

Thanks.

[Albe]

Just talked to someone at O-Navi. He says that if there is enough interest (i.e., more than 5 people asking) they will build a MNAV replacement. (The Phoenix is close, but has no magnetometer, and does only 10-bit sensor sampling.)

[rnaldi]

Just talked to someone at O-Navi. He says that if there is enough interest (i.e., more than 5 people asking) they will build a MNAV replacement. (The Phoenix is close, but has no magnetometer, and does only 10-bit sensor sampling.)

Hi Albe, probably I would be interested in buying one. We have got two MNAV and now one is damaged. I still wonder why it has been discontinued.