MicroGear - Replacement software for the Crossbow MNAV
What is MicroGearMicroGear is a comprehensive flight computer application designed to work with the Xbow MNAV sensor head. It replaces the default "avionics" program on the Crossbow Stargate/MNAV flight controller. MicroGear will run on the Xbow StarGate computer as well as the GumStix computers. It should also be easily adapted to any other unix based platform. MicroGear is still being developed, but the intention is to create an application that is much more robust, much more capable, much more flexible, much more end-user configurable than the original avionics program.MicroGear reads the raw sensor data from Xbow MNAV sensor head. It integrates and filters that data to compute a location and attitude estimate. It has a highly flexible autopilot that is entirely defined by an xml configuration file. This means you can create a huge variety of autopilot modes, multistage controllers, etc. without needing to setup a development system and compile code for your flight computer. It has a robust serial (radio modem based) air to ground communications link. And on the ground it will optionally tie into FlightGear for real time 3d synthetic views, real time instrument panels, real time google maps based tracking, and other interesting functions.
Where can I get a copy?The source code for the MicroGear application is available at the SourceForge MicroGear project page. Follow the "Download" link to download a copy of the source code.
IntroductionStatus:As of Nov 13, 2007 the first public release is available. This release is capable of sustained route following and reliable altitude hold. The license terms are GPL. Features: Here is a quick summary of the current feature set:
December 4, 2007First version of ground station software is tested and running:
November 13, 2007First public source code release. Code can be found at the SourceForge MicroGear project page.
October 15, 2007I am implementing a new altitude hold scheme. I'm close to being ready for a test flight ... hopefully we'll do this on Saturday. I'm looking forward to extremely boring, non-glitching, endless cycles around the route now that the MNAV firmware bug is fixed.
September 22, 2007I added a more optimized servo control command to the MNAV firmware and update the microgear code to use it. This reduces the character stream across the serial connection, and hopefully reduces contention with other commands and I/O.
September 21, 2007Finally! I found and fixed the MNAV firmware bug that had been periodically glitching my servos and occasionally killing the whole MNAV servo driving subsytem. The problem was a buffer overrun which is easily fixed by discarding extra characters rather than writing them over the end of the buffer.
August 16, 2007Today I went out to put in some more autonomous flight time and do a small demo. Here are two plots from the first flight, the first shows actual versus target altitude (I still need to work on the altitude hold module) and the second shows the ground track versus target waypoints.
August 10, 2007Today I performed the first flight test of my waypoint/route following code. This is largely adapted from the FlightGear route following code. I flew 2 test flights and both were convincing successes.There was a bit of head scratching over the past few days on the ground and in my front yard. I wanted to make sure I had as many kinks worked out at home before heading out to the flying field. The good news is that it all worked great. I am extremely pleased with the results.
The 3d visualization of the flights and their paths exposes a weakness in the altitude hold module which I need to resolve. My first attempt at an altitude hold was perhaps about 50% fancier than it needed to be, and that combined with some real world limitations of my sensors and sensor fusion math leads to more errors than I'd like to see. I can replace the current 3 stage controller with a 2 stage PID controller and I should be able to hold much tighter tolerances. But I have to put aside my dreams of a ground based flight director for now ... wahhh! :-)
August 7, 2007Software work is progressing well on the waypoint management and tracking code. Routes can be loaded from a config file, there is no arbitrary limit to the size of routes except for the size of gumstix RAM. Distance and bearing to the current waypoint is correctly calculated. The system automatically clicks over to the next waypoint when the current point is "achieved." And the system computes a heading error between current heading and desired heading to the waypoint currently being tracked. This heading error will be used to drive a bank angle and to steer the uav to the target.July 13, 20073D visualization of the altitude hold performance:
July 11, 2007Second test of Altitude Hold module. Today I flew with more relaxed pitch angle limits on my altitude hold module. This yielded results that were much closer to what I was expecting and hoping for.I have posted a short replay of what the aircraft *thought* it was doing on youtube (embedded below.) Here is a quick word of explanation for the video. The target altitude is 1400' MSL (about 500' about ground level.) The aircraft is flying with the altitude hold module engaged as well as a simple wing leveler. I am in manual control of the rudder and throttle the entire flight. During the flight I am constantly on the rudder, steering the aircraft around the sky to keep it in close visual range. The airframe has a significant amount of roll/yaw coupling, so when I hit it with the rudder for the turns you can see the coupling, quite a bit of dutch roll, but also the wing leveler fighting back against all the elements that are being thrown at it. You will see the aircraft climbing to the target altitude and leveling out. The gauges are a bit hard to read on the youtube version of the video. I apologize for that, but hopefully if you know anything about standard flight instruments, you can figure out what is going on. I find it very interesting to watch the attitude indicator, the altimeter, and the vertical speed indicator. This shows how the aircraft is always working to achieve the target altitude, but also shows some of the sensor noise and turbulence the system has to deal with.
Here is an altitude plot of the flight (including approach and landing which isn't shown in the video.) Click on the image for a larger version.
July 4, 2007First test of Altitude Hold module. Flew a mostly successful test of my first whack at an altitude hold module. My pitch angle limits were set too conservatively though so the system often could not achieve the desired rate of climb so the actual results wandered around quite a bit. I don't think it's worth posting plots or movies. Suffice it to say that I'm very happy that everything was trying to move in the right direction and do the right thing, even though it didn't manage to get where it wanted to go very often.
June 26, 2007I have flown successfully using the MNAV/GumStix/MicroGear as a simple wing leveler and pitch attitude hold. This seems to be working really well. Today I exported the rate of climb into the property system in preparation for building an altitude hold module.April 24, 2007I have applied an Xbow approved patch to the MNAV firmware that exposes the full gps time of the week to the stargate/gumstix. Unfortunately this still isn't enough to set the date on the computer, but it can at least help time stamp data files just a bit.
March 22, 2007More proof that people really should consider using a gumstix as their flight computer and not the Xbow stargate. This is a follow up on my Mar 19 entry where I was whining about the lackluster performance of the stargate.I'm up and running here with my MNAV code on a borrowed 400mhz gumstix, and I am seeing spectacular performance. Code that chugged along and couldn't possibly meet timing deadlines on the stargate, absolutely flies and finishes easily on time with the gumstix. I believe the difference is that the gumstix has an order of magnitude better floating point emuation than the stargate. The servo I have hooked up for testing is stable and responds to attitude changes of the sensor ... that indicates that my main loop is running at a consistant speed. It isn't getting behind and playing catch up like it does on the stargate. Also I time the routine that waits for serial input from the MNAV. Serial input comes in at a rate of 0.020 seconds. If the code did nothing but read the data, this routine should register an average time of 0.020 seconds because that includes the wait for the next data. In my gumstix results, this routine actually does register an average speed of exactly 0.020 seconds and clearly from the program output, all the kalman filtering is being executed at the desired rate. I get plausible attitude estimates, plausible nav estimates, plausible servo response when I change the attitude of the sensor. It's functioning correctly in every way, but registering zero time for all the math crunching. But it's registering 0.02 seconds for the main serial port reading loop ... so the timing functions do work! The system reported load average for the gumstix bounces around a bit, but seems to spend most of it's time < 0.20 of cpu capacity whereas on the stargate this number is usually at about 0.90+ without the nav filtering code and 1.0+ with the nav filtering code. 1.0 == a fully saturated cpu. So at the moment, I'm more inclined to believe that the timing numbers I get back are actually closer to valid and that I am observing pure magic. Everything I see is consistant with the "magic" conclusion. :-) It seems that the little gumstix holds it's own *really* well for floating point operations.
March 21, 2007Today I made the "nav_update()" routine a configurable option so you can decide if you want to run the 10hz nav filter or not. I also made the hard iron calibration parameters configurable in the master config.xml file.
March 20, 2007I discovered my MNAV has the electronic form of torrets syndrome in it's servo controller. My servos (and thus my control surfaces) go bonkers periodically. Attitude estimate is stable, the servo position commands I send to the MNAV are stable ... sometimes it runs stable, some times it sends the servos in completely random directions ... not good for stable flight.I was able to borrow a 2nd MNAV and determine that this 2nd one runs stably and doesn't have the same problem, so the first unit is going to have to go back for service. :-(
March 19, 2007Performance: I have been running into performance problems where the various loops are not finishing fast enough, so I introduced some simplistic timing code to see how long the major subroutines take.I found that the ahrs() routine takes about 0.0125 seconds per iteration on average and we want to run it at 50hz. That's about 0.625 seconds of cpu out of every real time second. The nav() routine takes about 0.0420 seconds per iteration on average and we want to run it at 10hz. That's about 0.420 seconds of cpu out of every real time second. But wait! That means for every real time second of operation, we need 1.04 seconds of cpu time just for these two routines which is not good! This means I need to take a hard look at performance and make some tough decisions. For the short term I've decided to simply not run the nav() routine and use the raw gps values at 4hz which should be ok for what I need to do. Longer term, I think I will shop for a better/faster embedded computer. I also noticed that querying the battery voltage from /dev/platx/batmon took horribly long ... another 0.04 seconds each time. So I wrote a simple "niced" background script that copies then contents of /dev/platx/batmon to /tmp/batmon every 10 seconds. MicroGear can then read the value out of /tmp/batmon and that happens blazingly fast. I have also noticed that my servos freak out occasionally when under MNAV autopilot control. I've verified that my attitude estimate (the values driving the autopilot code) is stable through the blips. I also verified that the values I'm writing to the servos are stable during the blips. I do notice that I often get imu check sum errors at the time the servos blip out, so something is going goofy with the MNAV periodically. Sometimes I can run for 30-60 seconds with no problem, and sometimes I can get several major hits in a 5 second period. Finally, it *seems* like perhaps the problems get worse when I try to drive the servos at 50hz and improve when I drive the servos at 25hz. I hope I just have a sick unit. I haven't heard of anyone else experiencing these issues. The FlightGear autopilot code also seems to run *very* fast on the stargate, I'm really happy about that. We should be able to do some fairly sophisticated multi-stage controllers without worrying too much about performance.
March 8, 2007Today I made some progress integrating a FlightGear style property state tree (hierarchical tree of name/value pairs that can be dynamically referenced by ascii name instead of as a compiler variable.) This is working well.The property system then is the foundation upon which I can integrate an xml based config file parser. The static xml data is loaded into the property system at program start time and then these config values can be referenced later by any piece of the code. The xml parser is used by the configurable autopilot. This allows me to build any arbitrary set of cascading controllers that reference any key sensor value and drive any output property. This might sound a bit abstract (and it is) but it allows the entire autopilot configuration including gains, multiple cascading stages, etc. to be defined in an xml config file. Of course this all implies that the internal sensor data is published to this same property state tree, which it now is. This all means that the onboard code can be instantly reconfigured to fly just about any type of vehicle based on just about any sensor data, controlling just about any outputs. There is no recompiling needed to change the autopilot configuration.
February 26, 2007Today we did a sightseeing drive around Wasilla and Palmer, AK. I had the MNAV up and running MicroGear during the entire drive and was able to feed the data live into FlightGear on my laptop and observe that the FlightGear view of the terrain closely matched the real world perspective out the window, and changed correctly as we moved. The remote data collection feature is now fixed and fully operation as well.
February 14, 2007Today I ported the FlightGear xml parser and property subsystem infrastructure to MicroGear. This paves the way for convenient xml based config files as well as a very flexible and run time configurable autopilot system.I believe the MicroGear autopilot system will be (by far) it's most distinguishing feature. This will expose a level of flexibility and configurability never before seen at this level. You will literally be able to build any combination of PID controller based on any physical or derived state value, driving any control surface (or combination of control surfaces.) Down the road, I have access to a generic (but very advanced) fighter-jet style fly-by-wire system that I would like to test on this hardware. That will be for later though, once the simpler stuff is up and running.
February 10, 2007Today I ported the code changes back to the StarGate and ran them on our UAV installation with GPS and radio modem. Using that platform I got the nav (gps and location estimate) code up and running at the proper update rate and it appeared to be generating correct values.
February 9, 2007I have been working on porting the MicroGear code over to the GumStix platform. I really like the gumstix (mostly) because it has an open and flexible root image build system, it uses modern versions of the various software packages, it runs linux of course, and it generally exudes warm fuzzy feelings ... especially if you have a bit of sys-admin still running in your veins. :-)The work has been going pretty well. The gumstix did *not* like the pthreads structure that worked on the stargate with the old 2.4.x kernel. So what I have been working on today is to completely rip out all the thread structure and redo everything in a single thread. This makes the code *much* simpler and everything fits together in a much more understandable way. Really, as it was implimented, threads bought the original code no advantage. All the threads ran in lockstep, so if any thread blocked unexpectedly, the entire program would freeze. If sensor data stopped flowing, the sensor data acquisition thread would block and dead lock everything else. If an individual thread crashed, the entire application crashed. Just for fun I added system "1 minute" load average to the health packet structure that is sent to the ground station. It's a nice debugging tool to check how hard we are running the gumstix in flight.
January 24, 2007I have observed the built in Xbow MNAV manual override mode glitching out now on several occasions. This is of course unacceptable, so I have purchased a separate standalone manual override board since can't trust that the MNAV can do this task reliably. I hope to have this board ready to go next week some time. I still plan to fly first with the MNAV 100% passive on a separate receiver listing on the same channel as the primary control system. Once I'm happy that everything is working (including GPS, etc.) then I will start looking at installing this manual override board so I can start slowly (and safely) giving the MNAV a chance to fly different axes of the aircraft.
November 22, 2006The MicroGear code flies for the first time. I discovered some minor issues with logging and transmitting battery health data, but overall the code performed very well.
|
