Xbow MicroNav update

[clolson]

Hi,

I just thought I'd post a small update on my experiences with the Xbow uNav. I finally got "mine" to play with this week. (Not mine exactly, but I get to have it on my desk for the foreseable future which is close enough to the same thing to make me happy.)

I observed that on my unit, in manual pass through mode, the channel mappings were all fouled up. I couldn't figure out a pattern, they were just jumbled up. Normally CH1 = aileron, CH2 = elevator, CH3 = throttle, CH4 = rudder, CH5 = gear, CH6 = flaps. But here CH1 and CH3 caused the servo to go BERZERK. CH4 was the throttle pass through, and I don't remember how the rest was mixed up. Has anyone else seen anything like this? I might have a hardware problem :-( but at least I can work around it for the moment by remapping the output channels.

Anyway, this mismapping led me to misunderstand the manual pass through mode of this device. The manual override switch is actually hardwired to CH5 in the uNAV firmware. (That's CH4 if you start counting from zero.) That threw me off because I was expecting this to be handled in software. I guess doing it at the hardware layer is a bit safer. The software can all blow up, but you can still get manual control back any time you want it.

Still it's important to understand that this is a "manual override" only, it's not a "fail safe" mode. If the uNAV itself goes chips up, or you lose power to the uNAV, you are done, you lose all manual control and everything else with it. I wonder what would happen if you cut your UAV loose for a long x-country and happened to fly over someone operating on the same channel. Seems like a potential weakness in their hardware scheme, and it's not something you can change in hardware. Perhaps you could change this in the uNAV firmware? I haven't dug in that deep yet.

So having waded through all that manual pass through mess, I think I've finally got my head mostly around how this unit works and am ready to go full throttle on the autopilot.

I'm not happy with the open-source code they provide for this unit. The code to read the uNAV sensor output is fine, the Kahlman filtering/sensor integration code is fine. But I'm not thrilled with how their autopilot code is basically hardwired to fly a zagi flying wing in one simplistic mode, nothing more, nothing less.

I plan to completely rip all that out, along with their groundstation stuff (which I am also not impressed with) and completely rewrite all that.

I will probably replace the autopilot PID with the FlightGear PID implementation since that is a fair bit more advanced and robust as compaired to the simplistic PID implementation. I also want to make the autopilot much more configurable and flexible so you can select different modes of operation without having to change the code, recompile, and re-upload a new binary to the unit.

And in the back of my head I want to be able to refine the FlightGear model for my UAV and be able to do some initial autopilot tuning in FlightGear, then just dump that configuration straight over to the uNAV/stargate for a plausible starting point. Further tuning will be necessary, but the goal is to have a reasonable starting point. Plus in FG there are examples of all sorts of autopilot modes, wing levelers, heading hold, virtual nav aid tracking, cross track error handling, pitch hold, altitude hold, bank hold (that works even if you change rudder position), auto-speed by varying throttle, auto-speed by varying pitch, etc. All with the possibility of connecting these to a virtual flight director. Conceptually in FlightGear you can run the autopilot with the "servos" turned off if that makes sense, and then just use the autopilot output to drive the vbars on your virtual flight director.

I'm probably getting way ahead of myself here though. The next step is to get the uNAV up in the air flying passively and collect data so I can get some confidence in the unit and the sort of sensor data it spits out. Then if that goes well I'll slowly ease into the autopilot thing, axis by axis. Should be a lot of fun if the manual override doesn't ever fail me and the unit behaves well.

Anyway, I think I've gotten through the most frustrating part of the learning curve with this unit and hopefully I'm about ready to start having some fun with it. :-)

Curt.

[LukeZ]

Excellent post, Curt. It's nice to have someone forge the path on these things and document the bugs/shortcomings. I am particularly interested in your plan to meld FlightGear with the Xbow.

Not much I can contribute to your quest, but you can be sure I will be watching your progress closely.


Luke

[clolson]

Excellent post, Curt. It's nice to have someone forge the path on these things and document the bugs/shortcomings. I am particularly interested in your plan to meld FlightGear with the Xbow.

Not much I can contribute to your quest, but you can be sure I will be watching your progress closely.


Just one more quick update. I heard back from Xbow late last night (well actually there was an email waiting for me this AM) and they found a servo mapping issue in the latest firmware. They fixed it and sent me new firmware to load on the uNAV, so I guess that is what I'll be doing 1st thing Monday morning.

Small comment on FlightGear: I've been tightly involved with the FlightGear project for the last 10 years so it has become my hammer which which I hit just about every problem. Other people have talked about using X-Plane or MSFS or Matlab/Simulink in various capacities and those are also very capable applications (but less interesting to me personally.) :-)

The thing that makes me really excited about the xbow uNAV is that the code is wide open to be modified or extended and that allows for some really interesting possible intereactions between FlightGear and a UAV (or multiple UAV's.) Here's a quick brain dump of various things I'm pondering ...

UAV Development:

- Use FG to model the UAV airframe and flight dynamics.
- Use FG to model, test, and tune the autopilot. (I'm well along in this process with our Rascal 110 model.)
- Use actual flight data (from the uNAV) to refine and improve the simulation model.
- You can prototype higher level functionality like flying a precision approach to touch down at a specific point, or formation flying. Debug and tune your algorithms in simulation first. For instance, I've written a FG script that will adjust the autopilot target values to track another aircraft, matching speed, heading, and altitude, and following some fixed distance behind. So your aircraft can follow another aircraft, completely hands off (in simulation anyway.) :-)

Mission Planning and Training:

- FlightGear + the model of your UAV can be used to train pilots, practice missions, visualize and evaluate routes, test fly flight plans to make sure you are properly avoiding terrain, restricted airspaces, towers, etc.

During the Flight:

- Telemetry data from the UAV can be fed directly into FG in real time. This enables some interesting real time functionality ...

- FG can be used to draw a real-time synthetic view of the world from the perspective of the UAV (or the ground operator, or many other perspectives.) (Check out http://www.cobbin.com)

- FG can display restricted airspaces, obstacles, waypoints, destination, etc. You can make things more visible and highlight critical information or locations in the synthetic view.

- FG can draw a HUD or cockpit style display that is driven by real time data from the UAV.

I've done some of these things already with our Rascal 110:

http://baron.flightgear.org/~curt/Models/Special/Rascal110_1/
http://baron.flightgear.org/~curt/Models/Special/Rascal110_2/

- It's possible (with some additional effort) to overlay live video on top of the synthetic view (conformally) so that the two (synthetic + real) are blended and match as closely as possible. This would allow you to ...

- Click on any point on the ground in the live video and get back the lon/lat/elev of what you just clicked on. (Accuracy would depend on how well your video is aligned with the synthetic view, accuracy of the FlightGear world elevation data, and latency in data transmission.)

- Some of this capability could (with even more work) be leveraged to automatically orthorectify your imagery ... again depending on how well calibrated your equipment is.

- Once you have the telemetry data fed into FG, you can connect that same copy of FG to the FlightGear multiplayer system. If you have multiple UAV's in the air, they can all be tied into this same system. That way all the UAV's in the air show up in each other's synthetic view.

- In addition, once connected to the FG MP system, your aircraft (possibly plural) are now tracked in our google maps hack: http://mpmap01.flightgear.org/ which superimposes your aircraft location over google map imagery or street maps.

- We have a new "beta" google map hack which tracks all the activity in the multiplayer system and logs each and every flight. So you can go back and plot out your entire flight later. This just happens automatically, you don't have to do anything special.

After the Flight:

- If you save your flight track data, you can feed that back into FG and replay your flight later. (If you connect to the MP system while replaying your flight, you can watch the flight replay in the google map page as well.)

The very exciting thing about FlightGear is that because it is so open and extensible, features that are added for one purpose, can be adapted to other purposes and when you mix in things like UAV's, FAA certified flight trainers, engineering simulators, synthetic visions systems, with a host of private contributors from around the world, you get a lot of interesting synergy and features and tools that can get connected together to do new and useful things. I know I'm only scratching the surface here ... Lot's of fun!

Curt.

[LukeZ]

Small comment on FlightGear: I've been tightly involved with the FlightGear project for the last 10 years so it has become my hammer which which I hit just about every problem.Yeah, I've noticed. :D

But if the shoe fits...


Luke

[Unterhausen]

The mapping of rc channels to servos was always screwy. I have a pan/tilt servo that goes crazy when it's hooked up and goes into autopilot mode. Gotta track that down.

I'm kinda stuck right now on the magnetometer output, it is noisy, and I haven't quite figured out what the bias variables are supposed to be. Next step is to read the code for that. You can't tell it an accelerometer bias in the existing code. It supposedly estimates that in the Kalman filter, but it failed to do anything in about 15 minutes of sitting on the ground. The biases in my accelerometers are very consistent, so I'd like to tell the code what they are as an initial condition. It would be nice to have an input file for all the default values.

The autopilot is very minimalist. I don't really want to write one, but I think my plane would probably not turn too well without some rudder and elevator along with the ailerons. I did finally get the code working so that it will do attitude hold properly. I was thinking about flying the plane today.

[clolson]

Excellent post, Curt. It's nice to have someone forge the path on these things and document the bugs/shortcomings. I am particularly interested in your plan to meld FlightGear with the Xbow.

Not much I can contribute to your quest, but you can be sure I will be watching your progress closely.

Yestereday in bench testing our Xbow MNAV/Stargate, the MNAV's built in manual override glitched out for several seconds on me! I was running batteries down and testing software with the manual override mode active, my transmitter on, etc.

Every once in a while I would walk over and wiggle the transmitter sticks to make sure everything was happy.

One of the times I did this, I wiggled the sticks and got NOTHING, no servo movement at all. I flipped the manual override switch back and forth a couple times ... NOTHING ... All of the sudden my servos went crazy, running to full stop, and click, click, clicking the gears as it tried to run them past full stop. I flipped the switch back and forth a couple more times and all the sudden things returned to normal.

SCARY and not in a good way!!!

I have decided that I will NOT trust the MNAV receiver decoding functions or built in software manual overrride. It appears to not be as reliable as a person would hope ...

So I'm now trying to find a stand alone manual override device I can purchase.

For what it's worth, the Xbow MNAV holds so much promise and is such a cool device, but I'm really frustrated right now because there seems to be a number of issues with it that indicate that this device really hasn't seen much real world practical shake down yet.

- The manual override works most of the time??? Not acceptable!

- The press fit gps antenna connector seems to be a really weak spot in the hardware design. Ours has quickly become flakey and we've had to take extreme measures to keep it connected reliably in flight.

- MNAV PPM signal decoding and servo pulse generation don't seem to have solid timing ... leading to workable output, but noticable servo jitter as the pulse widths aren't controlled very well.

- When the reciever is tapped to feed the PPM signal to the MNAV and everything is hooked up and powered on, we are seeing substantial range reduction to the point that I don't feel we have safe range margins to manually fly our aircraft.

- The scheme to mount the MNAV to the stargate involves only two kitty-corner bolts. This allows the MNAV to pivot along a diagnal axis and the connector can come loose!

- We are also building up a long list of issues and weaknesses with the AHRS open-source code that ties all the MNAV sensors together to give you pitch/roll/yaw/lon/lat/elev. It makes sense that they won't open-source their best algorithms, but at the same time, we have been disappointed in what they do make available.

I think that many of these issues can be engineered around ... but I'm still very frustrated right now. I'm having to spend a lot of time solving stupid issues that I would have hoped would just work, spending time working around bugs, and weaknesses, and non-robust behavior. :-( I still think this is the most coolest autopilot on the market right now, but it might need a v2.0 to address many of these issues we are running into.

Curt.

[Unterhausen]

Did you ever try using regulated 5v? I don't think it's a good idea to run it straight off of one lipo with unregulated voltage. We've had ours on for up to 3 hours with no problems. The only thing I really have complaints about is the occasional startup glitch which requires a restart.

[clolson]

Did you ever try using regulated 5v? I don't think it's a good idea to run it straight off of one lipo with unregulated voltage. We've had ours on for up to 3 hours with no problems. The only thing I really have complaints about is the occasional startup glitch which requires a restart.

Right now we are running with a 3.7v lipoly battery powering the MNAV/Stargate. This is how the Xbow folks had their UAV setup so we are attempting to follow their example and their advice ... perhaps a little naively ... (?)

Curt.

[danstrider]

For a reliable manual override switch that is independent of the autopilot and works as long as the servos have power, see:
http://www.rcgroups.com/forums/showthread.php?t=360746&page=2&pp=50

At last update, Jay Francis sells these for $99. A nice insurance policy for experimental autopilots :-)

Dan

[clolson]

We did another test flight of our Xbow MNAV + StarGate + MaxStream + Sig Rascal 110 setup today.

In our test last November, we had problems with our gps antenna connection. We made an attempt to fix that issue, but have been waiting through about 40 days of brutally cold weather here in MN to find a flyable day. Finally today the weather and our schedules matched up so we put in 2 very nice test flights.

The MNAV worked well. The secured gps antenna connection held up well though all RPM ranges, taxiing, take offs, landings, and some relatively agressive in flight maneuvers. Everything seemed solid. That is great news because it lets us move on to more interesting things.

In addition to just collecting the data, I fed it into a running copy of FlightGear in real time so you could visualize a synthetic view of the real world flight on the computer. This includes the world position, attitude, and flight surface deflections. It's very cool to see the virtual view on the computer match exactly what the real world airplane is doing as it happens.

When the Rascal is flown through a loop or a roll, you see the virtual rascal concurrently perform the exact same loop or roll in the sythetic view on the ground station.

This synthetic view will be useful for a number of things down the road. For example, we can click anywhere in the synthetic view and get back the real lon/lat/elevation of the ground point we clicked on. Now imagine that we have overlaid live video on top of the synthetic view in a way that matches the two views "conformally".

The synthetic view also gives us the ability to highlight obstacles, restricted airspace, planned routes, approach paths, other uav's in the air, etc.

Last, but not least, our synthetic view allows us to visually check the performance of our sensor suite and kalman filtering code. We don't have an absolute truth reference, but it's helpful to watch the flight data in real time, combined with the control surface deflections and if anything is too far off, it immediately jumps out at you. And of course there are certain things (discontinuities or incorrect flight attitudes that your eye will immediately pick up in real time visuals, where as you could stare at columns of numbers all day and never see a problem if the basic trends and relationships look right in the data.

So I'm very excited to establish a working baseline for our sensors ... our MNAV sensor suite now seems to be hitting on all cylinders. Our data link seems to work well. Our synthetic view and ground station also seems to be working well.

So now the last piece of the puzzle will be to test and install our stand alone manual override board. Hopefully I can get done next week. The manual override board + Rascal airframe + mav/stargate/maxstream will give us a safe platform to move forward with auto pilot development.

We have some pictures and movies from the fligh today so if any of those turn out to be interesting I'll see if I can post something.

Regards,

Curt.

[Wulffy]

...We have some pictures and movies from the fligh today so if any of those turn out to be interesting I'll see if I can post something.

Regards,

Curt.Interesting? That is an understatement. Heck, even if it is uneventful, it will still be EXCITING!!! Please do post something. If not in the forums, I suspect that you will post it to the website, at least.?. Thanks for taking the time to update us.

-t

[clolson]

Interesting? That is an understatement. Heck, even if it is uneventful, it will still be EXCITING!!! Please do post something. If not in the forums, I suspect that you will post it to the website, at least.?. Thanks for taking the time to update us.


I know that I definitely find this stuff exciting, but I also suspect (from trying to explain this all to my wife) that I may be among a small minority! :-)

I've posted some pictures and movies at my blog. Reminder that what I did today was fly entirely by hand. The MNAV and other equipment was riding along onboard simply to collect data, it was not in the critical control path. We use a 2nd receiver onboard to feed the transmitter signals into the MNAV. So here is the link:

http://baron.flightgear.org/~curt/UAV/Rascal110_1/Instrumentation/

In case you are wondering, I'm the guy that looks more likely to have a last name of Olson. :-)

Curt.

[clolson]

I was visiting a friend up in Wasilla, AK this weekend and we had our Xbow MNAV up and running in the car as we drove around doing some sight seeing.

I captured the data stream and I'm replaying our drive in FlightGear connected to our multiplayer system. I'll try to keep this running for the rest of the afternoon.

http://mpmap02.flightgear.org (select pilot "Rascal2")

We drove up to Hatcher pass, came down through Palmer and then down to Anchorage to drop me off at the airport.

The Really cool thing was that we were feeding FlightGear running live on my laptop as we drove and observed the flightgear terrain matched the view out our window very closely for the entire drive. That was really reassuring that (a) we are getting reasonable data out of the MNAV and (b) FlightGear's terrain model matches the real world pretty well.

So the next big thing is to get this unit back in the air for some more flight testing.

Curt.

[Wulffy]

Wicked kewl!

[sergio123]

Hi,
I'm new here and I'm making also a UAV based on my own hardware with a gumstix. In the past I was stopped with the kalman software ( I do not have the mathematical level for this). Now I have installed the MNAV Kalman filter in the gumstix and also made my software compatible with FlighGear ( it is very nice to see the aircraft in the FG moving like my uav, at least on my desk). I'm waiting to have good wheater ( next week end) to test the kalmann filter in flight to see if it works well or not. I will provide you video when I will be able to do the test inflight.

Curt, do you use the kalman as written in the MNAV or did you do some modification on it?
Serge

[clolson]

Curt, do you use the kalman as written in the MNAV or did you do some modification on it?
Serge

Add me to the long list of folks that really doesn't know much about kalman filtering ... not enough to modify the algorithm, and definitely not nearly enough to implement something from scratch. I can talk about some of the high level concepts though and pretend like I'm an expert ... for instance, in the MNAV code, the prediction step for roll and pitch and yaw is done at 50hz and correction step for roll and pitch is done at 25 hz. The correction step for yaw is done at 10 hz ... hehe, don't be fooled though ... I hit a brick wall with my kalman filtering understanding soon after that.

So yes, I'm just using pretty much the stock MNAV algorithm from v1.4 of their source code.

Just about everything else in my flight computer application is much different from their code though. Not to be critical of the original MNAV code ... well, let me just say that I have my own thoughts and opinions and ideas for how an application should be put together and how code should be structured, standards for organization, and very little of the original MNAV code fits within my world view.

So I am developing my own application, based on the MNAV 1.4 kalman filtering code, and using some of their other code as a starting point. My application is going to be substantially different, but I think will be much more flexible and capable and will also support the gumstix platform along with the stargate.

I need to do a fair bit more development and testing before I can even start to think about sharing copies, but since much this application borrows from other open-source code, if I do release it, it will have to be licensed under the GPL.

For what it's worth, my airframe and hardware is now all in place and tested, so my next big step is to begin work on the autopilot code. I've started laying the foundation for that, but there is a lot of infrastructure work to do before any good stuff will happen.

Regards,

Curt.

[sergio123]

Ok Thanks for your comments Curt. I will let you know about my flight tests with this Kalman filter. I was upset by the kalman filter from autopilot and I hope this one will be better ( I'm like you : I do not have the level to change the algorithm to the kalman filter). On my hardware I send the datas to the ground by the audio channel of the video signal but I don't know the format of the data expected by flightgear from the serial port, if you have any web link which expalin this I will be able to see in real time the flight and replay it.
Here after the link of the video I made yesterday between my UAV and FlightGear, seems to be OK .... in static ! will see in flight
http://serge.laforest.free.fr/videos/FG_UAV.mpg
Serge

[clolson]

Here after the link of the video I made yesterday between my UAV and FlightGear, seems to be OK .... in static ! will see in flight
http://serge.laforest.free.fr/videos/FG_UAV.mpg
Serge

The movie seems to show that you have your airplane synced with FlightGear quite well!

[sergio123]

Hi,
just to let you know that I did a flight test with the MNAV1.4 Kalman filter and was a little bit upset because the angles ( pitch,roll and yaw) were not accurate. May be this is because all the tests I made in my desk before was at a temperature about 40 degrees celcius and in flight yesterday was only 20 degrees. Will see next Saturday , i will compensate the gyros ( and Acc ?) drift with the temperature sensor in the algo
serge

[treehog]

I will definitly moniter this thread

@sergio123
belle piste et vol circular
I like your site a lot
i still have my my ff6 on 41mhz from my FFAM days if I get to fly in France this year but since 2000 then been like you displaced throughout EU

@UAV flyers
possibly some body in the future can put up a thread on how to make flight gear interface as I havent had much luck with that so far

Ralf

[sergio123]

Ralf,
I use FlightGear with my hardware to do simulation in real time. From your software you have to send to Flightgear the structure net_fdm.h described for example here:
http://zone.ni.com/devzone/cda/tut/p/id/2942
( also on this page you will find how to set up FlightGear. ). I found an example of a C software able to send the minimum data to Flightgear and this soft works well for test purpose:
http://mail.flightgear.org/pipermail/flightgear-users/2004-April/007605.html

The problem I have is to replay a Flight with FlightGear. I made a file with the net_fdm structurre and setup FlightGear to read this file ( --native-fdm=file,in,10,c:\FG.dat )
But Flightgear seems to get the first position and attitude from my file, but don't replay the file.

Curt,
Do you know how to replay a flight with FlightGear? I have seen on your web site that you did this but I'm not able to do the same.
Are you making, like me, a file with the structure of net_fdm.h or do you have another way to send the data to FlightGear ?
Serge

[clolson]

Theoretically you can replay a saved flightgear file, but what I've done is to write an external program that has two modes of operation. 1. read the data in over the serial port, log it to disk, and create the flightgear FGNetFDM structure and send it over in "real time". 2. Read back in the saved log file (not the flightgear log file, but an exact log of the incoming serial stream) and create the FGNetFDM packets again and send them to FlightGear. For the 2nd mode of operation, my code loads the entire data file and the interpolates at whatever data rate I want to feed FlightGear.

Regards,

Curt.

[sergio123]

Ok Thanks Curt for this explaantion, so you has always used the network to send data to FG, you never get a file containing the FGNetFDM structure for mFG. It seems that the FG's command "--native-fdm=file,in,10,c:\FG.dat" doesn't works ( of course the file c:\FG.dat exist on my disk).
Regards
Serge

[sergio123]

Curt,
Does your software run under Windows ? If yes is it in the domain public ? In other word where can we get it ?
I haven't a compiler for windows and I would like to replay the flight I made but not spending lot of time to install a compiler just for that and write the same software has you did.
thanks
Regards
Serge

[clolson]

The software is actually available as part of the FlightGear development tree which you can access via CVS (following the instructions on the flightgear.org web site.) It's designed with the unix way of doing sockets and serial I/O, but if you compile with cygwin for windows I would think it should work. I've never tested it or tried to compile/run it on windows though. FlightGear itself (obviously) runs on windows.

It's one of those things though that I threw together for my own needs, put it in with the rest of FlightGear and make it available for people to look at or use, but I don't have much time to support it, so beyond a few quick questions, you are going to be mostly on your own with it.

Regards,

Curt.

[sergio123]

Curt,
Thanks for your answer. I will have a look on the FG's CVS and manage it, don't worry
Thanks again for your help
Regards
Serge

[treehog]

Thanks working on this info

ralf

[clolson]

I thought I'd post a quick update on my Xbow MNAV adventures ...

Over the last two days, I've flown 4 flights with the MNAV participating in the control and stabalization of the aircraft.

Yesterday I flew two flights with the MNAV acting as a simple wing leveler. This worked out pretty well. My control algorithm is a full PID so when you kick in full rudder, the wings get pulled back to actual level (roll angle = 0) again. This is good and bad, bad because it makes it really hard to do any steering with rudder only, but good if you are trying to point a camera and really do want to keep the wings as level as possible.

Today I flew twice more, this time I added a pitch angle hold. Again, this seemed to work pretty well. I don't think my gains are exactly optimal, but they certainly are good enough to fly. I usually get one larger overshoot before the system zeros in on the target attitude. It was a pretty windy/turbulent day today so if the control algorithms can stay stable today, they should be that much happier on a calmer day. I was joking that it was a good day to fly a kite because my aircraft was having trouble making any headway at all into the wind. :-)

Well, after 2 days of flight testing, I can say that the RxMux manual override board I bought on recommendation of this forum worked spectacularly. Thanks Jay! The MNAV still looks like it can live up to all it's promises, and seems to be performing adequately in the early going here. I still have all the right number of airplane pieces (even though I did bring a garbage bag to the field with me just in case) :-) And I'm really happy because the gains I developed using the FlightGear flight simulator seemed to work out just fine on the real aircraft (running the exact same PID code as FlightGear.)

I still have a long way to go, but this was a ***HUGE*** hurdle to overcome ... safe flying with the MNAV in the active control loop ... and with the MNAV even doing the right things. :-) I was ready to give up on the whole UAV thing if this didn't work out, so it is with a very large sigh of relief that I am able to post some positive results. :-)

Curt.

[Wulffy]

:) Wicked Kewl Curt. I am mega-geeked for you. I am building my own IMU, so I am a heck of a lot further from the finish line than you are... ;) KUDOS!!!

[clolson]

:) Wicked Kewl Curt. I am mega-geeked for you. I am building my own IMU, so I am a heck of a lot further from the finish line than you are... ;) KUDOS!!!

I'm a software guy and an R/C nut, so I wouldn't know the first place to start in building any kind of electronics. So the MNAV fills in a big gap in my own abilities, but it's not exactly a plug-n-play device so it's been a long adventure here getting to the point where I can even begin to introduce it into the critical control path.

But it's very exciting to see it do something reasonably close to what I expected and hoped for it to be able to do!

The next steps are to impliment a full blown altitude hold mode (probably based on inertially augmented gps altitude which I get at 10hz) along with a heading hold and route following.

The magnetometer actually works well enough to get a plausible heading out of it, but it probably makes more sense to navigate based on ground track ... with some additional logic to avoid doing stupid things when wind speed approaches or exceeds air speed. :-)

If I can keep all the hardware in one piece, this project is going to get really fun, really soon.

Curt.

[kd7ost]

Way to go Curt,

Your project sounds great. I did some looking on the MNAV site but can't find a hardware unit. Just software downloads. I use the FMA co-pilot to manage a flat roll in my Ag pictures while steering with rudder. Just as you described. What hardware are you using to get that flat roll with rudder input?

Dan

[clolson]

Your project sounds great. I did some looking on the MNAV site but can't find a hardware unit. Just software downloads. I use the FMA co-pilot to manage a flat roll in my Ag pictures while steering with rudder. Just as you described. What hardware are you using to get that flat roll with rudder input?


Hi Dan, the MNAV (aka micronav, unav) is sold by Crossbow, http://www.xbow.com

This is a pretty full features IMU/GPS. You get a roll/pitch/yaw estimate at 50hz and lon/lat/elevation estimate at 10hz. Plus it has static and dynamic pressure sensors and the ability to drive 8 or 9 servos right on a single unit. It has a couple weak points and that is what has taken me some time to work around, but the open-programability of this device is exactly what I need to keep me happy.

The co-pilot uses IR differential and a proportional controller to drive the wings back towards level. But if you apply constant rudder pressure, or your co-pilot isn't calibrated perfectly, or your plane isn't exactly all trimmed out just right, or you change your throttle setting, etc. etc., you aren't going to have exactly level wings (at least I never did with my Kadet Sr.) The MNAV can do much of the same sort of thing, except it senses the aircraft attitude through a combination of gyros and accelerometers + fancy math. On top of that, I can program a similar proportional wing leveler, or in my case I built a full PID controller so that I can force the wings to be exactly level. They don't stay pegged there since any disruptive force will knock you off level, but the controller is always working to get the wings back to level again ... so if you apply full rudder deflection and hold it there, the wings do pretty quickly come back to exactly level.

The promise of the MNAV is that for < $2k of hardware, you can build an autopilot system that is similar to pretty advanced autopilot systems like the micropilot or kestrel. The reality of the MNAV though is that it seems to take a huge amount of engineering and software development to make it do it's thing. It's not nearly as plug and play as products from the more established uav autopilot companies.

So I'm not going to encourage everyone to run out and buy an MNAV just yet, but for myself, it's a really interesting product. It gives me a level of programmability that keeps me interested in pushing it forward. And now I have managed to clear a big hurdle I needed to overcome in order to be able to use the MNAV for actual [safe] autonomous flight tests.

Regards,

Curt.

[kd7ost]

Oh, thanks. I think we talked about this once and I just didn't realize what you were using. I get too many projects going and lose touch sometimes.

I've seen the same problem with the co-pilot but a lot has to do with the inherent stability of the platform in use. I stay far away from dihedral in my wings because yaw induces extra roll and the co-pilot has to fight that. I keep my wing designs flat and keep my fuselage and mass as close to the center of lift as I can. The co-pilot will keep the plane very flat that way. But it is a fair weather device.

Dan

[clolson]

Oh, thanks. I think we talked about this once and I just didn't realize what you were using. I get too many projects going and lose touch sometimes.

I've seen the same problem with the co-pilot but a lot has to do with the inherent stability of the platform in use. I stay far away from dihedral in my wings because yaw induces extra roll and the co-pilot has to fight that. I keep my wing designs flat and keep my fuselage and mass as close to the center of lift as I can. The co-pilot will keep the plane very flat that way. But it is a fair weather device.


In the world of UAV's there seems to be an especially large number of ways to accomplish things. And there is a huge spectrum of what people want to accomplish, what experience they bring to the table, and what budget they have at their disposal.

I think at the end of the day simplicity is almost always better, and if you get something working robustly and it does what you want, you are ahead of 99.9% of the herd. :-)

My MNAV efforts are just in their infancy still. I had something fail in one of the flights today causing the controls to go hard over, but then it recovered itself and was working ok later ... so I need to figure that one out before I go too much further down the path.

(Jay's RxMux saved my butt, and I was able to get back under manual control before the aircraft rolled more than about 60 degrees. I never felt like the airframe was in any kind of danger.)
Curt.

[Unterhausen]

Curt,
The RxMux http://www.rcgroups.com/forums/showpost.php?p=6733939&postcount=91 looks like it would be a very nice addition to any UAV. Have you done anything that helped your range?

[clolson]

Curt,
The RxMux http://www.rcgroups.com/forums/showpost.php?p=6733939&postcount=91 looks like it would be a very nice addition to any UAV. Have you done anything that helped your range?

Big disclaimer: I'm not an RF expert, but here is what I have done:

1. Primary manual control of the UAV is handled through a separate stand alone receiver. The outputs of this receiver is fed into "Input B" of the RxMux. I found that tapping the PPM signal off a receiver and feeding that into the MNAV caused a *significant* (and for me dangerous) reduction of range on that receiver. So I do not use the MNAV's built in manual override mode. Also I would point out that the MNAV manual override is implemented in software ... take that however you want to. :-) The RxMux is pretty simple standalone hardware ... it wins by a mile in my book.

2. I disabled the BEC on my speed controller (Phoenix 80). Powering the receiver and RxMux board from the BEC contributed to a huge and dangerous loss of range when I had all the various pieces plugged together. So my receiver and servos and the RxMux board is all powered from a nice clean separate battery power supply, not the noisy BEC.

2a. I don't know if this helps or hinders or doesn't make any difference, but I power the MNAV from yet another separate battery pack. So I actually have 3 batteries in my aircraft and that number may increase when I add a radio modem.

3. I've been wondering about trying one of these new 2.4ghz radio systems, but not understanding much about where all my specific RF, noise, range issues are coming from, I don't want to drop that much money on a big fat guess. I need to find someone around here who has one and is willing to do some testing with me. Longer term though I do like the idea of a 2.4ghz radio because it allows you to do a "secure" handoff of your uav to autonomous mode by turning off your transmitter ... and you don't have to worry about stray signals from that point on.

Regards,

Curt.

[Unterhausen]

Thanks Curt,
You bring up an interesting point: if you don't use the failsafe on the uNav, you don't need to have any special receiver.

[clolson]

Thanks Curt,
You bring up an interesting point: if you don't use the failsafe on the uNav, you don't need to have any special receiver.

It is still nice to have a second "hacked" receiver to feed the MNAV so you can log your stick inputs, but you are right, if you don't care about that, you can use anything that outputs a standard servo signal.

Curt.

[Unterhausen]

My only personal radio is a Spektrum, so I've been thinking about how to integrate that with the uNav. The fact that the uNav takes a multiplexed signal which is not available from the Spektrum has been holding me back. Obviously, I could build a multiplexer to hang off a reciever just for the uNav, but that seems like a lot of work. Basically, I figured I'd do the same thing as an RxMux only with an added microcontroller to combine all the servo signals from the Rx to feed into the uNav.

The other problem is that I want to use WiFi downlink, so it's likely that there is an interference problem. I've been thinking about using the same maxstream 2.4GHz module as the extreme flight XPS system, and use it for control and downlink. That would be a big project even if the open source version comes to fruition. Hasn't been any activity on that thread in a while. http://www.rcgroups.com/forums/showthread.php?t=651255&highlight=open+source

[clolson]

Another related thing I thought might be interesting is that there is some device by a company in Germany (don't have the link handy) :-( that will take receiver output and make it look like a usb joystick. If you had usb support and joystick drivers on your flight computer, you could use something like that to read in your stick commands. I have this goofy dream some day of building an "airbus" style flight control system for R/C model aircraft ... it would certainly help tame those landing approaches on the tricky cross wind days and make the airplane fly a lot smoother and more "scale like". Even the "lowly" co-pilot really goes a long way towards making windy days fun. I have one on my Kadet Senior and was out flying in some swirling cross winds that made most everyone else put their airplanes back in their trucks. The co-pilot took care of leveling the wings, so I could concentrate on glide path and tracking the runway centerline (with about a 30 degree crab.) Turned out to be a lot fun and made me look like a much better pilot than I really am. :-)

[Unterhausen]

It is still nice to have a second "hacked" receiver to feed the MNAV so you can log your stick inputs
Curt.
Is that what you are doing?

The issue with the way the uNav is set up, and using the RxMux in the most obvious way, is that it would be nice to have the uNav return the plane to a pre-determined spot if it loses radio contact. But that's another project.

Interesting about the copilot and wind. I like the idea of the copilot sensor, it's simple and works pretty well. I sometimes wonder if it wouldn't be a good addition to a full rate gyro IMU.

[clolson]

Is that what you are doing? [Second receiver hacked to feed the mnav]


Not yet, but it's on the short term plan.

The issue with the way the uNav is set up, and using the RxMux in the most obvious way, is that it would be nice to have the uNav return the plane to a pre-determined spot if it loses radio contact. But that's another project.


Supposedly the RxMux will flip over to input set A if signal is lost. But with a PPM receiver, when things get noisey, it's a little weird ... at least in my basement where things are really noisey. Seems like a pretty plausible thing to do though with an MNAV ...

Interesting about the copilot and wind. I like the idea of the copilot sensor, it's simple and works pretty well. I sometimes wonder if it wouldn't be a good addition to a full rate gyro IMU.

It would be nice to have the "data" to feed into your control algorithms. Having it inline and having more than one controller fighting for the controls would at least take some thought to make sure it does something reasonable.

Curt.

[Unterhausen]

Supposedly the RxMux will flip over to input set A if signal is lost. But with a PPM receiver, when things get noisey, it's a little weird ... at least in my basement where things are really noisey. Seems like a pretty plausible thing to do though with an MNAV ...
Curt.

The other day when I was modifying my receiver, turning off the Tx sure seemed to generate a lot of random PPM frames. I wonder how the uNav can possibly handle that, they are doing some sort of counter input I believe.


It would be nice to have the "data" to feed into your control algorithms. Having it inline and having more than one controller fighting for the controls would at least take some thought to make sure it does something reasonable.
Curt.
Yes, using the sensors in the algorithm is what I meant to suggest. Somebody on here mentioned a scheme (gyrodometry) from robotics where they only pay attention to the gyros when magnitude of the gyro signal is over a certain amount. I felt the robotics guys made a big fuss over this rather pedestrian idea, but it avoids a lot of trouble. If you had the copilot sensors running things under normal conditions, you could do that. Of course, just putting them in a Bayesian filter might work just as well.

[JayFrancis]

Supposedly the RxMux will flip over to input set A if signal is lost. But with a PPM receiver, when things get noisey, it's a little weird ... at least in my basement where things are really noisey. Seems like a pretty plausible thing to do though with an MNAV ...
Curt.

With most PPM receivers, when the signal is lost, you tend to get garbage out. The RxMux may, or may not, determine that the garbage is a valid signal. Sometimes it LOOKS like a valid signal!

You really should feed the RxMux with a receiver that has some sort of failsafe output mode (i.e. a PCM receiver, or smart PPM receiver). The RxMux makes an attempt at signal validation, but it can be fooled - please don't rely on it.

(from the documentation)
"By itself, the RxMux does not perform any failsafe, redundancy, or protection services. Although the RxMux will default to Input A in the absence of any Select input signal, this is not a reliable failure mode."

--Jay

[clolson]

With most PPM receivers, when the signal is lost, you tend to get garbage out. The RxMux may, or may not, determine that the garbage is a valid signal. Sometimes it LOOKS like a valid signal!

You really should feed the RxMux with a receiver that has some sort of failsafe output mode (i.e. a PCM receiver, or smart PPM receiver). The RxMux makes an attempt at signal validation, but it can be fooled - please don't rely on it.

(from the documentation)
"By itself, the RxMux does not perform any failsafe, redundancy, or protection services. Although the RxMux will default to Input A in the absence of any Select input signal, this is not a reliable failure mode."


I was thinking that with a 2.4Ghz system (or maybe a smart PCM receiver as well) you could take off, activate your autopilot mode, then turn off your transmitter. The failsafe would hold the channels in their last known position which would keep the autopilot selection channel locked to autopilot-activation until you turn your transmitter back on. The nice thing about a 2.4Ghz system is that your own transmitter would be the only one that could regain manual control of your uav. It's secure in some sense of the word (although probably a smart hacker could easily defeat the identity validation, this isn't going to happen by random like it could with a 72Mhz system.)

Curt.

[clolson]

Quick update on my progress. Today I did a first flight test of my altitude hold controller (based on MNAV + Gumstix). I did a 17 minute flight in the Senior Telemaster with altitude hold and wing leveler enabled and I just steered around the sky with rudder and played with the throttle.

I need to do some more tuning, but after looking at the data and replaying the flight, it appears that the results are understandable. The exciting thing is that it aside from setting my max nose up/down pitch limits too conservatively, everything seemed to actually work and move in the right direction. I'm going to do some more tuning though before I post any plots, however. :-)

Curt.

[clolson]

Today I flew a fairly successful test of my altitude hold controller (Xbow MNAV based.) I've posted more details in the July 11, 2007 entry of my MicroGear blog here:

http://baron.flightgear.org/~curt/UAV/MicroGear1/

I'll attach a movie (replaying what the aircraft *thought* it was doing) along with a plot of the alitude. Climbing to 1400' MSL and then holding that altitude.

http://www.youtube.com/watch?v=nTzf8WxGSUs

I haven't spent a lot of time tuning the real system yet so I know I can lock in better than this as I move forward. Most of my setup and tuning has been in the simulator but I'm very pleased to see the real aircraft behaves reasonably well with the gains I've developed in the simulation.

[gwenhastings]

Wow, I am blown away about the MNAV + FlightGear integration(it actually impresses me as the "right" way to develop an autopilot,) I have a O-navi system gathering dust on the shelf because of the 5k cost of a development systems for same. BUT I do have a gumstix(the stargate is kind of pricey) and the bucks to buy an MNAV and begin shaking out the bugs.

So is your source tree for 1.4 modded for the gumstix available for download yet?

would be UAV integrators are dying to know
gwen

[Unterhausen]

You could download the current unav software from sourceforge and build it for your gumstix for practice

But I would like Curt's code too.

[clolson]

Wow, I am blown away about the MNAV + FlightGear integration(it actually impresses me as the "right" way to develop an autopilot,) I have a O-navi system gathering dust on the shelf because of the 5k cost of a development systems for same. BUT I do have a gumstix(the stargate is kind of pricey) and the bucks to buy an MNAV and begin shaking out the bugs.

So is your source tree for 1.4 modded for the gumstix available for download yet?

would be UAV integrators are dying to know
gwen

Hi Gwen,

Thanks for your kind words. My source tree is almost a complete rewrite/replacement of the original v1.4 mnav code except for the kalman filtering/sensor fusion code. There is an effort underway on that front to come up with a *much* better algorithm, however it's being developed in matlab, so I'm not sure if the C version of that will be able to run on a gumstix yet or not.

I haven't made the code available for download yet for a couple reasons ...

1. It's not quite to the point of having "alpha" functionality ... and by that I mean I'd like it to be able to follow a preprogrammed route, hold altitude, and hold speed as a bare minimum.

2. I haven't had a chance to do any documentation at all, and I honestly don't have the time right at the moment to walk people through all the steps of getting things running. I'm a big fan of open-source software, but right now I don't have time to do much additional open-source tech support which this code would most definitely require.

3. Things are always more complicated than you'd like. This code depends on a custom gumstix root image (or a *lot* of horsing around to get proper runtime libraries copied over to the stargate.) I also have a couple patches to the MNAV firmware itself which aren't critical, but are helpful.

4. There are other compenent integration issues that you'll face that probably are nothing I should be worrying about, but maybe would fall into the category of "best practices I've discovered so far ..." Those would either need to be carefully documented or passed along from generation to generation through the oral tradition in order to maximize your chances of success.

5. There are safety and liability issues I haven't had a chance to really think through. The thought of my code piloting someone else's airframe into an unsafe situation at least gives me pause. I don't know what my liabilities might be, but it's something I want to at least think a little bit more about????

6. And laying all my cards on the table here (since I guess I'm a lousy sales person) ... I've spent the last 11+ years of my life immersed in FlightGear, an open source flight simulator. I've expended literally countless hours and late nights over these past years developing code, answering emails, traveling to expos, writing documentation, rolling out new releases, managing the web site, etc. etc. all on top of a regular day job and my family commitments. It's a huge time commitment, most days it runs me ragged, and I've done it all for free. I'm really nervous about jumping in and doing the same thing in an entirely new field while at the same time, still trying to keep my flightgear ducks in formation and trying to hold down my day job and see my family once in a while. Unfortunately I'm not a member of the liesure class just yet and I've got a wife and two kids. So quite honestly, I'm also trying hard to think how I can cast my UAV efforts into some form that might eventually support itself.

That said, please feel free to PM me and I'd be willing to discuss this further. Maybe I can send you some sort of "preview" that you could play with a bit.

[Unterhausen]

Curt,
Does your code still written without threads?

What tools did you use to rebuild the mnav firmware, did you do it on a Windows machine? What did you change in the firmware?

I was messing around with the buildroot for the gumstix, but I haven't gotten that figured out yet.

[clolson]

Curt,
Does your code still written without threads?

What tools did you use to rebuild the mnav firmware, did you do it on a Windows machine? What did you change in the firmware?

I was messing around with the buildroot for the gumstix, but I haven't gotten that figured out yet.

Yes, I have no threads. My personal view is that threads can obscure your code and execution order to a great extent, and hide so many really subtle and nasty bugs, that I only do threads as a last resort when I can't figure out any simpler way to accomplish what I want.

I'm pretty sure I downloaded the windows tools from xbow to rebuild the firmware. The firmware upload utility is a windows app, so I guess we are stuck doing firmware development in windows already.

It's been a while since I set up the gumstix buildroot stuff, but I seem to recall doing the svn checkout first, then following a couple simple steps that I found documented, and it was off and building.

Regards,

Curt.

[Unterhausen]

I was trying to remember why I was using threads in one of my programs the other day, and I couldn't remember. It is nice for communications. For example, keeping in contact with the ground station doesn't really have to happen synchronously with the flight control. If the ground station doesn't get every packet, it's no big deal. That's usually the sort of thing where I use threads.
I'm also going to use threads in a program that gets data and aggregates it before doing an analysis step. The data acquisition step can then be running in the background.

[clolson]

I was trying to remember why I was using threads in one of my programs the other day, and I couldn't remember. It is nice for communications. For example, keeping in contact with the ground station doesn't really have to happen synchronously with the flight control. If the ground station doesn't get every packet, it's no big deal. That's usually the sort of thing where I use threads.
I'm also going to use threads in a program that gets data and aggregates it before doing an analysis step. The data acquisition step can then be running in the background.

I'm not disagreeing here, there are plenty of legitimate uses for threads ...

On the flipside, a serial port driver or network socket will aggregate (buffer) the data on it's own within some limits. Your main thread isn't going to be able to use this data until it's ready for it, so either way ... if you add a thread to aggregate it, or let the data sit in the serial port or socket buffer, it will still be there when you need it. If your main thread is getting so far behind the data stream that you are worried about overflowing the built in I/O buffers, then there are probably other performance issues that are going to be more important to you anyway.

In the case of the MNAV, you want everything to run at a core rate of 50hz. The open-source mnav code spawns several threads, however, they all block on each other in order to maintain the correct execution sequence and timing. So if one thread stops for some reason or takes too long, the others will be delayed too. Part of the rational of threads on a uav is that if one thread dies, there is hope that the other threads will live and continue to function, perhaps giving you enough data or control to at least save the airframe. However, in the case of the mnav code (or any threaded application running on linux that I've seen) if a thread dies it just crashes the whole program and you are done anyway.

In addition, I observe that the MNAV spits it's data out the serial port at 50hz, so if you just key your program execution off the incoming MNAV data stream, then you automatically get everything to run at the 50hz rate you are hoping for. If the MNAV communication link dies, then you lose all your sensor data, you lose all your ability to control servos, so you are pretty much done for the day anyway.

A lot of this boils down to programming styles and preferences, however in my experience, threads can make the code and it's execution sequence really hard to understand. This in turn can hide some really non-obvious bugs, and if these bugs are timing related, you might only have glitch or hang once every day or once every hour. If bugs are really hard to reproduce, they are really hard to fix.

So that is why personally I minimize my use of threads, although I do use them when I have no other choice ... for instance in FlightGear there is a thread that load new scenery in the background to minimize the frame rate hit. There is also a thread that goes out and fetches current weather conditions off the internet. Both of these tasks can spend a signifiant amount of time doing nothing while waiting for I/O, and that time must be spent drawing the scene to keep the frame rates smooth, so in this case we went through a lot of pain a debugging headaches, but we made it work.

So far I haven't found a compelling reason to go through the pain of putting additional threads back into my MNAV code though. At some point I'll probably run up against something, but for now I'm ok.

Curt.

[Unterhausen]

I think you're right about the unav code. Since the data acquisition is being done on the unav, and the heavy calculations are being done on the stargate/gumstix, the obvious processing split is done in hardware.

[clolson]

Here's another mini update for my UAV project if anyone cares. I *think* I have my route following scheme all worked out. I'm going to go do a test flight tomorrow. In the meantime I've been playing around with some different ideas for visualizing flights (either in real time via a radio modem link or later as a replay.)

I posted a movie of about 150 seconds (35Mb) of flight. The quality is low since I filmed it off my computer monitor with a cheap digital camera, and I won't claim any sort of hollywood style action, but hopefully there is enough detail there to get the general idea of what can be accomplished.

http://baron.flightgear.org/~curt/tmp/MVI_4715.AVI

The movie shows a portion of a flight where the autopilot is holding the airplane at a preprogrammed altitude and I am manually steering it around the sky in somewhat of a random pattern.

It's probably just a time waster, but I've been having a lot of fun with it ... :-)

Curt.

[clolson]

Here's another quick update. I did 2 successful test flights of my route following system this morning. This was the very first flight test of my route code following code, so I was extremely thrilled to see it work pretty decent on the first flight attempt. I'm still flying high so to speak. :-) I put in a few hours of hair pulling on the ground though in advance so it wasn't just pure luck that it worked out of the box on the first try. All the building blocks were carefully debugged in stages before this point.

Here's a snapshot of a 3d visualization/animation of the 2nd flight. I made up a figure 8 pattern and programmed that into the flight computer. After a couple loops around the circuit, you can see a definite pattern emerging. This is *real* flight test data, not just a computer simulation. The computer animation is simply playing back the data collected on board the UAV. For what it's worth, this looks really awsome when it's all in motion and you can pan around your view and look from different vantage points. You can also see some weaknesses in my altitude hold scheme ... which I think I know how to address.

Curt.

[clolson]

One more picture ... MNAV + gumstix + telemaster + electric motor + 2 lbs lipo ...

[clolson]

Here are two plots from the autonomous portion of a test flight today. I still need to work on the altitude hold ... it's loosing too much altitude in the turns. Oh, here is a movie from a manual flight today ... I like playing the landing and take offs in slow-mo ... (32Mb)

http://baron.flightgear.org/~curt/UAV/SeniorTelemaster/Movies/Cap0011.mpg

Curt.

[Unterhausen]

Curt, I was playing with my Gumstix, and I was wondering if you had run into the same problem I did. My gumstix buildroot version is 773, but when I check that version out of SVN, there is no such thing as "make menuconfig"

When you build the latest, of course there is a menuconfig. Should I just update the kernel on my gumstix and use the latest buildroot?

Your progress looks great, the altitude hold seems like something the stock MNAV will not do, is that correct? Or at least, since it has no throttle control, it seems like it will not do altitude hold under general flight conditions.

[clolson]

I'm just using the most recent gumstix buildroot stuff.

At the moment I'm not using throttle to control altitude, but I do have some safety limits in place so that I can't inadvertantly stall the aircraft if the engine stops running. My biggest problem with altitude hold is that I tried to get too fancy ... dreamt of someday building a manual flight director on my ground station ... that all works great in simulation and works "ok" in real life, but I think I can get a much tighter hold if I switch to a slightly different approach.

I'm have the code ready to be able to add an air-speed hold module to my autopilot xml config file, but I haven't added the xml block in the config file.

Curt.

[clolson]

I just wanted to post a quick update here. I have about 250+ minutes of autonomous flight in on my Senior Telemaster with a Xbow MNAV + Gumstix based autopilot system. I was having a problem with the servos going hard over and locking on me, but I did some didling in the MNAV firmware and seem to have gotten that problem to go away.

But I was still having a problem with momentary glitches in the servos ... they would quickly recover, but in flight you might see the airplane jump in some random direction periodically (maybe every 30-60 seconds) and then recover just as quickly to straight and level flight. I was pulling my hair out, pouring over the MNAV firmware code, trying all kinds of little changes with no luck ... interrupt priorities, timing/order bugs, uart code, ppm signal decoding ... anything that might affect the servo output ...

Finally, this evening, I think I may have gotten to the bottom of what was going on ... and would you believe ... the problem was in my own code ... Dohh!!! I only had the aileron/elevator servos connected to the MNAV output so I figured all the other 9 channels of servo data in the pulse train didn't matter. So I wasn't initializing those values and that resulted in occasional random data being sent over for those positions. Apparently this would lead to the MNAV generating a pulse train that would periodically confuse my servos. When I set all the servo positions to a consistant value, life became much happier!

Learning lots of little things (I never thought I'd need to know) as I go here ... :-)

I may get this MNAV beat into submission yet.

[Unterhausen]

do they do that in their code? I need to fix our code so that we can use the camera pan-tilt. Right now we can't have it hooked up, since the pan tilt servos are hard-over, get really hot, and draw down the batteries quickly

[clolson]

Hmmm, I think I may have spoken too soon about eliminating the periodic/momentary servo glitching ... i thought I was running clean last night, but today I powered everything on to double check for myself and things were still glitching periodically ... :-(

I wonder if different servos are more or less sensitive to the "revisit time" of the ppm pulse train. I have some hitec micro servos here that behave as you describe. But if I plug in the high torque hitec servos I have on my telemaster, they run pretty well (minus the occasional glitching.)

I need to do some more research on the servo control code and get my head around exactly how every little bit of it works. One thing I think I see is that as soon as one pulse train is finished, it seems to immediately start the next one. I.e. there isn't a consistant 20ms frame. So as the servo values change the larger frame time changes and varies ... and I wonder if different brands or types of servos are more or less sensitive to this. Does the MNAV have some additional hardware to help drive the servos? I don't know, I'm still trying to figure all that out, but I continue to be frustrated by this periodic problem of momentary glitches in the servos.

If I don't send any servo position updates at all, then they stay stable at the last position sent, the glitches seem tied somehow to the fact that I'm sending updates and the faster I send updates, the more often the glitches.

And then, every once in a while the system will run perfectly clean for me with no jitters at all (but that is rare ...)

So there's got to be some wierd timing issue, or something related to parsing/updating the servo position commands, or just too many interrupts get stacked up once in a while ... but the servo control timer interrupt should have a higher priority than the uart interrupt, so serial control interrupts should jump to the front of the line rather than getting backed up behind a bunch of serial I/O ...

I don't know, been going round and round through the MNAV firmware and my own code trying a whole boat load of things, but not developing too much traction towards solving the problem.

Curt.

[clolson]

Ok, one more update on the subject of the MNAV and periodic servo glitching. This problem does not appear to happen when sending servo position commands from a PC or from a stargate embedded computer, but does seem to happen when sending servo commands from a gumstix (which is my flight computer.)

The good news is I think I got to the bottom of the issue. It appears that the gumstix I/O system can occasionally get bogged down with other various activities and sometimes the outgoing serial commands can get bottled up (2-3 of them) and they are released all at once.

When the MNAV gets hit with a larger chunk of incoming data all at once (such as multiple commands stuffed together becuase the sending side did some buffering), it's fixed size command buffer can overflow leading to some random goofiness ... not something you want on an autonomous craft. All it takes is a quick check to discard excess characters beyond the buffer size and life becomes ever so much better.

That is my theory, and so far it seems to be working out well, my servos are running very nicely now ... I can even send servo position updates @ 50hz with 100% robustness ... something that not even crossbow could reliably do in their lab from a PC with the old unpatched firmware.

So at some level I'm a little disappointed I had to spend so much time battling this issue in the MNAV firmware, but at another level, I really appreciate that Xbow publishes their firmware code so I can hunt for problems that perhaps are hard for them to reproduce and debug since they don't have access to my exact combination of hardware and software.

Still riding the Xbow MNAV horse here ... :-)

Curt.

[Unterhausen]

Glad to hear you've tracked this down, is this going to make it into a firmware update?

[clolson]

That's up to xbow I guess to decide what they want to do about it. I'm pretty sure I found a real bug and came up with a reasonable fix for it. But I've been wrong before ... only once or twice in my life but it has happened. :-)

My system here is finally running the way I always thought it should. But, they probably want to take some time to confirm that this really is a bug, then if so, decide if they like my fix or if they want come up with a better approach.

Curt.

[bujora]

Hi,
My project is a crop duster UAV.Technical data about my project :
- The airframe will be capable to fly with a payload of 50-75 liters (enough to spray 1-2 ha ) ( will be a biplane with the wingspan of approx 4 m)
- Power will be supplied by a hang glider or para glider engine .(Solo 210, Rotax 503)
- UAV controls will be operated by giant scale servos

Requirments for the Autopilot :

- Ground control software needs to:
- communicate with a mobile GPS system that will provide the coordinates of the field to be sprayed.
- design the flight path in order to cover the field.
- Autopilot requirements:
- communication with payload sensor (pressure or weight) that will indicate when all the load have been sprayed. The system needs to memorize this point. When this payload sensor is triggered, the UAV must return to the " base" and after loading, come back and start spraying from the same spot. The UAV will need to follow this kind of cycle until the hole field is sprayed.

At this point, after talking with tech representative from MicroPilot, who said that theoretically this project can be done, I am not sure if the GPS can provide me the needed positioning accuracy! This UAV of mine needs to be on the designed path with a tolerance of +/- 15 cm.
Does anybody know how accurate are those devices ? What kind of hardware / software should I use to get where I want ?
Thank You !
Aries

[clolson]

I'm not a big gps expert, but I don't think you are going to get 15 cm sensing accuracy with a solo gps receiver. If you can setup and survey in a base station and do differential gps, then I know you can get down to about 2cm accuracy. I worked on a surface vehicle project using differential gps and we had 2cm accuracy at 10 hz and that was enough to have the truck / bus even drive itself down the road with pretty tight tolerances.

However, when you put yourself up in the air with wind, roll/pitch sensing errors, turbulence, etc. even if you could sense your position within 15cm, you may not be able to actually fly a route within that tolerance. It will definitely take some experimentation to get acceptable results ... I doubt you are going to be able to spec out a system in advance, plug it in and have it work beyond your wildest expectations on the first try.

Given your specific flight planning requirements, you may need a flight computer and autopilot system that is a cut above average, and has the ability to accept custom programming or scripting. I'm working on such a beast right now (thus this thread) so if you want to bat around some more specific ideas about your project with me, I'd be happy to do that. You can find my direct contact info on my home page here:

http://baron.flightgear.org/~curt/

Feel free to email me if you like.

Curt.

[gael.desilles]

Hello there,

just to mention that as an expert of navigation technologies on UAVs :eek: , I would say your project of a UAV flying with +/-15 cm is simply impossible. As for today, the GPS horizontal accuracy (when you're lucky) is within 5 m, 95% of the time. The vertical axis is way beyond this, at roughly 15 m. DGPS may reduce the positionning error down to 50 cm.

Therefore, if you really need a 15 cm accuracy, you need a medium class inertial navigation system ; such systems are usually sold around 15000 US$...

The XBow* doesn't offer all this ; you will reach 5 m at best. And as Curtis Olson said, the localization accuracy does not count for flight performance, that is usually lower, due to winds, unmodeled dynamics, etc... So at best, an operationnal UAV with XBow would allow 10 m, 95% of the time.

Gael

* any micropiloting system based on MEMS technology less than 10,000 US$ will be comparable.

[bujora]

Thank you guys !!

So, with a spraying width of 5 m, using DGPS, the best I can make would be a 10% horizontal positioning error ! For the beginning doesn't sound very bad!
What would be the vertical axis error in this case ? Following the horizontal calculations would result a 1.5 m error?!?! .That is also not bad! Flying 4-5 m above the crops should be close enough !
Now, it is all about the costs ! ( Thank you for the market prices Gael !) I would keep hammering on this project and hopefully, next year I will be able to get in the air something close to my initial project (and budget !!!)
DGPS - any suggestions where I can learn more about it ?

Aries

[gael.desilles]

Dear Aries,

intuitively, and taking into account my personal knowledge of UAVs or guidance systems, it would cost about 5,000 US$ to get a DGPS-compliant autopilot. At that price, you'll get a guidance system that's able to fly your fixed wing uav within a "corridor" of roughly 1 m large (x,y,z). But you'll also have to cope with drawbacks : you won't probably be able to define appropriate flight plans to your applications, so you'll have to enter hundreds of waypoint coordinates. This means you will have to KNOW these coordinates before hand, and won't be able to enter simple figures to follow (I don't know : maybe you would need the uav to make "snake trajectories" above the fields ?).

Moreover you'll have to perform appropriate integration of your autopilot, and this requires basic knowledge of mechanics, power management, and so on. Differential GPS requires a reference ground station of your own (more accurate), or an internet connection running on board to get differential corrections from the nearest reference station (less accurate).

Any specific system that would closer fit your need will cost... more (I'm sure you've guessed) ! For instance, Yamaha is selling a turnkey VTOL UAV (RMAX or R50) that's able to care for your crops "at a press of a button" (sorry about my english). This nice machine is sold... 100,000 $US... I'm thinking of another system we've bought a year ago or so : the WePilot2000 autopilot system by www.wecontrol.ch (the company is now owned by a French one). The total cost of integrating the system into a R/C plane (Rascal 110) was aproximately 50,000 US$, and this price does only include a very basic ground station.

So, theoretically your project is viable. But it will require efforts (raw money or raw hard work) !

Sincerely,
Gael.

[bujora]

Dear Gael,

Thank you for the information ! The last couple days did changed a lot my approach on this project. There is no way I can put 50 000 US $ on my UAV crop duster !
I know that sometime soon the market will get cheaper and then....maybe I can have a shot to get where I want !
But,...I want to go to "school" in the meanwhile....make some experiments...
If you have any suggestions about how someone can spend some money learning the basics, I would really appreciate that !

[clolson]

I just wanted to post a quick note here since several of you have asked me about getting a copy of the open source autopilot/flight computer code I am developing to run with the Xbow MNAV.

I have registered a project at SourceForge and uploaded the first public release:

http://sourceforge.net/projects/microgear/

MicroGear is an open-source flight computer application. It contains xbow's open-source kalman filtering, an advanced an highly configurable pid autopilot system, detailed onboard logging, and air->ground communication support.

This application has several unique features which may interest (or scare!) people. :-)

It's written in C++. It should be able to run on the stargate platform, but is really much happier running on the 400mhz gumstix which seems to have about 10x faster software floating point performance.

Application configuration is done via structured xml files (the flight computer application has a built in xml parser.)

The autopilot configuration is very configurable. The system is PID based. For each final output, you can configure any number of stages and leverage any published value in any of the stages. The autopilot configuration file is also formatted in xml and is essentially the exact same format used in FlightGear. So if you have a plausible dynamics model of your aircraft built for FlightGear, you can setup your autopilot stages, test and tune them, all within FlightGear, then copy the config file over to the real UAV and have a sporting chance of success on your first flight. I actually get to claim that exact success for my Telemaster project ... the first real flight test of roll and pitch hold worked out of the box and yielded convergent behavior. More tuning was required of course, but the simulation yielded a set of gains that produced stable flight right out of the box.

The flight control system supports conventional 4 channel configurations (aileron, elevator, throttle, rudder) and also supports flying wing elevon mixing. There has been no attempt so far to adapt this code for use in helicopters. Theoretically, the software can support flight control systems involving up to 8 servos.

The system can do detailed onboard data logging, and also supports sending telemetry to a ground station in real time via a serial port (i.e. radio modem.)

The code is loosely based on the original Xbow code, but all threading support and ncurses support has been removed.

I would also like to point out that this application is only one [arguably small] component of a successful, robust, reliable UAV system. You are welcome to send me any questions you like and I will do my best to answer them. But I have a family and a full time day job and other volunteer activies, so my time available to do "free" UAV support is very limited. I should also point out that this code is being developed as part of a larger UAS project with commercial ties. The MicroGear component of this system is licensed using the Gnu Public License (GPL).

Enjoy ... :-)

Curt.

[zik]

Looks really cool Curt - great work!

[clolson]

Last Friday I took my telemaster out and logged about 50 minutes of fully autonomous flight (looping around a figure-8 pattern.) Now with my MNAV firmware bug fix in place, I'm getting rock solid servo control, and starting to build up some good confidence in the reliability and robustness of the system.

I posted a couple "screen shots" to my sourceforge project page (including some pictures of a neat marinized flying wing I've been helping with.)

http://sourceforge.net/project/screenshots.php?group_id=209804

Curt.

[clolson]

Just for fun, I thought I'd post a movie. Disclaimer: it's taken with a digital camera pointed at my computer monitor and picked up some audio of my girls playing in the other room.

http://baron.flightgear.org/~curt/tmp/MVI_5227.AVI

What the movie shows is MicroGear/MNAV compatible ground station software during a replay of an actual UAV flight. The route is a simple "figure 8" pattern.

The altitude strip is in-op, but we are working on getting to the bottom of that. Just about everything else is working pretty well. Longer term, we have vbars which we can use to show the pitch and roll angles that the autopilot is trying to achieve (as compared to the actual pitch/roll of the aircraft.) We can also show target heading and altitude bugs as well as a rate of climb bug so you can get a pretty good idea of what the autopilot is trying to do compared to what's really happening.

The indicators in the upper right show what control surface deflections are being commanded. Generally they don't move very far so I might up the gains on the display so you can see a bit more action.

Anyway, kind of fun. We have yet to hook this up to the UAV in real time, but hopefully we'll get that done next week so we can use the software to monitor the progress of the actual flight, not just visualize the flight later on.

[kbosak]

The airframe will be capable to fly with a payload of 50-75 liters.
This UAV of mine needs to be on the designed path with a tolerance of +/- 15 cm.

Let me guess your next questions: classical examples of the layout of the windows in white-painted circular buildings, and resistance of reinforced concrete buildings to prolonged fire?
You approach the problem in very strange way. Crop dusting is not the most precise job in flying. Also the capacity being 10 times smaller than real cropdusters, will require spraying rather Agent Orange than classic chemicals. :eek:

[bujora]

Let me guess your next questions: classical examples of the layout of the windows in white-painted circular buildings, and resistance of reinforced concrete buildings to prolonged fire?
You approach the problem in very strange way. Crop dusting is not the most precise job in flying. Also the capacity being 10 times smaller than real cropdusters, will require spraying rather Agent Orange than classic chemicals. :eek:

Very funny ! Check out Yamaha's RMAX ! I won't go any further on this mean post of yours because I respect Curt work and I this thread is about Curt !

[kbosak]

I respect everybody but who on earth needs accuracy better than actual cruise missiles just to spray crops? :p 15cm is around 6 inches!!!

[bujora]

I respect everybody but who on earth needs accuracy better than actual cruise missiles just to spray crops? :p 15cm is around 6 inches!!!

This 15 cm was a just a number to start working with. This is what I get with my regular tractor driven spray equipment. With such accuracy this UAV sprayer could have worked in my vegetable fields. I learned from Curt and all the experts that were kind enough to consider answering my questions that this accuracy is far away from what an autopilot with regular gps can provide.
Satisfied ?

[kbosak]

Yes :D
However my point was not about the POSSIBILITY.
Even it this would be POSSIBLE with GPS or anything, why to follow.. tractor tracks? Just curious. :rolleyes:
The aerodynamic of sprays is so much complicated that you couldn't in any way predict where is will fall with accuracy better than say 0.5m even flying 1-2 metres over the field.

[small_rcer]

Just a few observations about the 15cm accuracy objective.

Driving a tractor, it is possible to place the wheels within less than 10cm consistently. Just pick a rock and have the front wheels just skim by it. At field speeds it is quite doable and I have done it. Thus the spray accuracy is possibly very good. Also consider the spray heads are only cm above the tallest part of the crop, depending on what crop you are spraying. Also consider the earth in most parts of the world is not shaking and moving under the tractor.

Now consider the aerial spray task. A full size crop duster likes at least 100 cm between the lowest part of the plane and the top of the crop, and prefers 2-3 metres or 200-300cm. Secondly wind is moving the aircraft around and the smaller the plane the more it moves even in the lightest of winds. In other words the ground appears to be moving under the aircraft track.

Finally the full size tractor or aircraft have the most sophisticated computer system with a full 3D vision system in control, that is the operator/pilot in the seat.

Very high accuracy with a UAV based crop duster is possible. The cost and complexity is likely way beyond being economic. However if one was to instead consider an Unmanned Autonomous Vehicle vs Airborne vehicle then it is eminently doable. A ground based GPS guided spray vehicle, functionally an unmanned tractor will work and provide the accuracy and repeatability that is likely required.

So, high accuracy objectives are acceptable, however the method to achieve them may not be best served with an aerial vehicle. The techniques employed for guidance and position determination are very similar or the same. Much of the guidance and control software would be interchangeable. The carrying capacity and regulatory hurdles might also be easier to overcome if an autonomous ground based vehicle is the platform.

Just some thoughts.

Jim H

[kbosak]

I would like to indicate that the accuracy better than 1-2m in horizontal position tends to require military GPS receivers, using DGPS, and exceptionally well tuned UAV platform (I think best airplane amateur systems on rcgroups reach waypoints +/- 20m during 180deg turns and 5m during straight flight - but there is a lot to be desired in their sensors in particular amateur UAV hardly ever predict actual wind direction and include this in mission planning). Civil WAAS corrections for GPS may or may not be sufficient for getting less than 2m (it is US specific system anyway).
An even better accuracy (less than 0.5m) might require high-power custom processing boards, based on FPGA + DSP (in general much more difficult part of electronics than microprocessors for washmachines) and in general image processing technologies, would need serious R&D company in electronics, cost 50-500KUSD (at least 20e6USD if you ask NASA), would add onboard digital camera, all this custom and suited to this very exotic application (ordinary application would be vehicle tracking). :cool:

[bujora]

Thank you guys ! It is a pleasure for me to see your interest on this subject ! With every new information the overall image of what I want and what I can do is changing. I already use a ACVS rate gyro on my AP model and I suspect that the first flying sprayer will use this basic control system to see how it can handle spraying glyphosate on drainage ditches, irrigation channels....

[zentakz]

Hi Curt,

I'm new to this thread, and I apologize if this question has been asked before. Do you use a cable to connect a gumstix uart to the 51-pin connector, or do you use an rs232 level shifter to connect the pins on the top side? Are you using a custom board for the gumstix-mnav interface, or one of the expansion boards?

Thanks,
Jake

[clolson]

I'm new to this thread, and I apologize if this question has been asked before. Do you use a cable to connect a gumstix uart to the 51-pin connector, or do you use an rs232 level shifter to connect the pins on the top side? Are you using a custom board for the gumstix-mnav interface, or one of the expansion boards?


In the system I prototyped, I connected the MNAV to a gumstix via a serial cable. The gumstix I used was one that was purchased as a "computer package" so it had the add on board with 2 serial ports.

Regards,

Curt.

[zentakz]

Ok, thanks. I am starting to design my own expansion board for the Gumstix that will provide connectivity with the MNAV as well as an RF modem (an xtend OEM module). For ground communications, did you use an RF modem, and more specifically, how did you implement UDP/IP over serial? My best guess is to use PPP to establish a connection with the ground before initializing the flight computer code. Is that how you approached it?

Cheers,
Jake

[clolson]

Ok, thanks. I am starting to design my own expansion board for the Gumstix that will provide connectivity with the MNAV as well as an RF modem (an xtend OEM module). For ground communications, did you use an RF modem, and more specifically, how did you implement UDP/IP over serial? My best guess is to use PPP to establish a connection with the ground before initializing the flight computer code. Is that how you approached it?


I didn't see a need to do IP over serial ... that adds complexity and overhead. I just designed a simple binary packet protocol and stream that across the serial line to the other side. The ground station picks this up, parses it, and distributes the data where it needs to go.

[clolson]

I made a quick movie of one loop around a simple autonomous circuit with my senior telemaster flying with mnav + microgear:

http://youtube.com/watch?v=gO88h20H-AQ

Curt.