Diary

From Albatross

This article is part of the diary. For all diary entries please select by month below.

2006 • August • July • June • May • April • March

27th July

• [H] Started working at the Geospatial Research Center. At first, I'm working on a standalone and reliable autopilot-manual switch with some nice features. The design uses a CPLD, and can switch between three banks of 8 servos. Verified HDL design in hardware (with an FPGA dev board) and it seems to work very well. Next step is to put together a compact PCB and get it in the aircraft. Then we can finally test our autopilot with confidence that (no matter what it does) we can always resume manual control!

9th May

• Came across a new integrated MEMS inertial sensor from Analog Devices, the ADIS16350 - 3 axis gyro and 3 axis accelerometer with a digital interface, in a single package [1].
• Started to negotiate an arrangement with the Geospatial Research Center. At this stage, it might involve sharing of access to our hardware resources and skills and their integrated navigation expertise. Tentatively, the arrangement might be: They get to use our autopilot hardware (which does actually make a very versatile UAV development system, much more flexible in many ways for research than a COTS autopilot), and we get to calibrate our sensors and software against their ring-laser gyros (orders of magnitude better than ours), mil-spec GPS receivers, and their validated INS/GPS EKF software. I am extremely excited about the possibilities!

26th March

• http://www.sparkfun.com/commerce/product_info.php?products_id=8266 looks like an interesting GPS device.

21st March

• This looks like an interesting and relatively low cost SBC approach for next-gen UAV flight hardware: http://www.garz-fricke.com/render.php?sess_pid=357
• Well, unfortunately this project has to be put on hold. Both John and myself are going to be busy with higher education and other activities for some time. Autonomous flight technology is maturing fast, and being used for more and more applications every day. We are seeking opportunities to combine our work to date with other ongoing UAV research and projects, before it becomes hopelessly obsolete...

7th February

• Found this Accelerating Flight Vehicle Design - hindsight is 20/20...
• Adding to the I pain also found
  • This list of airframe analysis tools
  • And this AVL equivilent seems to be actively maintained

15th-21st January

• Traveled to LCA where we gave a talk.
  • Video
  • Slides

26th December

• Decided on electrically heating the fuel/air mix using a coil of Nichrome wire, to improve vapourisation (as opposed to any of the other fuel vapourisation schemes we had been talking about - ultrasonic atomisation etc.).
  • This means we need a FET on the engine board to turn on power to this heater coil, and another 3-5 W of power from the alternator.
  • In addition, if the engine board can measure the resistance of the heater, we might be able to estimate mass flow in the inlet (proportional to cooling of the wire, which changes its resistance - see hot wire mass airflow sensors).

19th December

• Building a prototype spark ignition system for testing the engine on petrol fuel (rather than alcohol/nitro fuel). It's fairly primitive (no digital timing control yet), just a simple capacitor discharge system, running at 300V. Winding tiny torrodial transformers is extremely un-fun...
• It seems the name "Albatross" was already used for a UAV, http://www.charlesriverrc.org/articles/asfwpp/helmutlelke_asfwpp.htm - started in the 80s using the electrostatic method for altitude sensing and stabilisation.

9th November

• I have spent the last week working on getting FlightGear playing with the rest of the system. Ideally we will use the FlightGear protocol xml files to describe the data flow between different parts of the system.
• I wrote a python app to autogenerate struct definitions and printing and unpacking functions from the FlightGear protocol xml files.
• I patched flightgear to support the addition of headers in the binary protocol. FlighGear will also accept a full path for the protocol definition files, it will no longer look in only fg_root/Protocol.
• I tied all of these aspects together with a few apps.
  • A simple wrapper script which launches FlightGear with the specified protocol xml file and dumps the data to a file.
  • A C application then provesses the data file, using the unpack functions which have been dynamically generated. This is output to a CSV file for later importing into Matlab.
• I wrestled with scons to get all of the above integrated into the build system in a coherant manner.
• I spent a few days investigating Eigenstate assignment for the control system design and comparing this with this output from AVL. With the protocol and FlightGear stuff at a milestone I will now go back to integrating AVL.
• We got accepted to present a paper on the project and our experiences at linux.conf.au

26th October

• We have been working out the design and architecture of the Version 2 Software, in particular, how the data flow will work to allow run time selection of data inputs and outputs for software or hardware in the loop simulations. The structure of the code is starting to come together nicely!
• John has been working on the airframe design flow (using AVL, JSBSim etc.), and we have started to discus how the simulation results, especially the eigenmode analysis by AVL, can be used for automatic optimal controller (and possible estimator) design.
• This is a good link for Flight Theory: http://www.centennialofflight.gov/essay_cat/9.htm

15th October

• Hooked up the remaining pieces in the fuselage/ directory so we can now generate valid .avl and .mass files, and run AVL automatically using these generated files. This should allow rapid (and in the future possibly automated) tuning of the canard design.
• Spent some time researching how to drive flightgear from an external application. Sufficient information can be found at;
  • This thread on the glightgear mailing list
  • This flightgear paper
  • This UAV project using flightgear as a visualizer

12th October

• Yet another open source IMU/Kalman filter code has become available online, and it looks pretty nice. Check it out here or here.
• Met David Park who will be moving to Christchurch to do UAV research starting mid November. We talked about a number of possible (probable?) exciting future collaborations.
• Added a whole bunch of stuff allowing us to generate AVL .mass files from the output of the canard airframe designer. Spent a bit of time making it nice and OO so that if you want to plug your own airframe into the design process (or run many subtle variations of the same airframe) you can just Derive from Airplane.py, implement a few methods and it should work.
• Generating .avl files is coming along, but is harder than the .mass files.
• Dugg out the power electronics textbook and started some work on the motor control board.

10th October

• Checked in first attempt at automating avl and airframe design using python-pexpect
• Wrote Version2:Design Procedure as a design document for what we want to be able to do regarding design and optomizing the airframe.

9th October

• Reorganisation task
  • Moved the wiki content into Version1 and Version2 namespaces
  • Moved all the stuff in svn into the v1 branch and imported all needed tools into trunk
• Got the Gumstix toolchain built on Ubuntu Edgy and made some ligths flash on robostix

8th October

• Started official work on the project for MEM
• Met together and sorted out a rough plan for the next few months which basically involves three priorities
  • Design and Build engine control board. First prototype will probbably built off of the robostix just to try and get as many things going in the toolchain at once.
  • Finalise the the airframe design->simulate->verify cycle
  • Settle on hardware requirements for the rest of the platform

5th October

• Had a talk to Mark Tomlinson of Navman about GPS receivers. He showed me some test results of some of the various GPS chipsets and modules on the market: SiRFStar-III and uNav (with Orion software) seem to be the stand-out performers. The uNav chip is available in a 10x10mm module, and performs much better than our current u-blox receiver (at least in Navman's tests). We need to find out where to get some samples and datasheets.
• Met Synco Reynders of GPS Boomerang, had a long talk about the practicalities of autonomous flight and our trans-Tasman attempt project.

7th August

• David got some reciprocating fuel pumps that are driven by engine vibration ("Perry pumps" I think). We tried them yesterday on the test stand, but didn't really see any improvement from its use. I suspect the test stand damps the vibration too well, and they will perform much better in flight. They are quite heavy though (~25 g).
• David also got some in-flight mixture control modules he bought, that will do much the same thing as the home-made one he had previously made, but hopefully with better precision.
• Talked about getting a mould made from the APC Electric prop (like the one that cracked, see below) and having a copy made from carbon reinforced plastic.
• Measured the exhaust gas temperature at the end of the muffler at between about 95 and 125 deg C (using both my thermocouple probe held in the exhaust gas stream, and David's infrared thermometer aimed at the muffler). The RPM was varied between about 3700 and 4500 RPM. When the mixture was tweaked so the temperature was high (125 deg C), the engine became quite unstable and stalled easily. We concluded that the digital mixture controller will need to be quite smart. The engine has a very narrow sweet spot with the large prop (14x12), at around 4000 RPM, and dies very easily. There appears to be much work needed here (although things should be better with petrol fuel and spark ignition).
• I rigged up a simple PicAxe-based protoboard with and wrote code to do servo control. Next week this will be hooked up to the throttle and mixture servos and we can start building a large table of performance data. (Set up a electronics bench in the corner of David's workshop with a PC, lab power supply etc.) Also I need to connect the PicAxe to a thermocouple amp and a RPM sensor and automate the data logging process.
• Surprisingly little oil leaks out the power take-off hole in the back of the crank case, which is good.

21st July

• David has got all three engines back from the spark-eroding place, where he had the crank shaft bored out for the power take off connection to the alternator. David machined some small brass liners for these bores, glued them in with high temperature Locktite glue and tapped them with a thread for the alternator connection.
• David added some kind of shim to the cam shafts to decrease the compression slightly so the engines can drive the larger props we need. We now have three modified engines that run fine (albeit still with methanol fuel and with the stock carb). Next steps are to connect and test the alternator, then the smaller carb, then modify the engine timing for reverse rotation (so we can use normal props in the pusher configuration), then switch to petrol fuel and spark ignition. Finally, we need to investigate and implement a way of getting (much) better fuel vapourization. The smaller carb will help, but we will need something else. We talked about using a piezo-electric transducer as an ultrasonic atomizer, a small pump (e.g. Perry pump) to increase fuel pressure into the carb for better vapourization, or a small turbo or super charger type fan/turbine in the fuel/air mix to increase turbulence and possibly pressure.
• The APC electric props we were planning to use now appear to be unsuitable - one cracked and became unusable after about 20 minutes of running on one of the engines. This is because they are designed to be much thinner/lighter/not as strong for use on electric motors, not combustion engines.
• Need to rig up some simple quick & dirty system for testing the engine control algorithm. I think something based on a PicAxe dev board will do nicely, because it's cheap, easy (servo control commands built in) and locally available (at SICom).
• Need to talk to someone about 3-phase alternator design, and also a CFD expert.

10th July

• Got interviewed by the University of Canterbury student radio station (RDU) today about our trans-tasman plans.

6th July

• There is an article on our trans-tasman flight plan in Chronicle, the University of Canterbury alumni magazine. Check it out here (p7) or here.

24th June

• The three Enya 0.53 4-stroke engines David ordered have arrived! We can now start work on modifying and tuning the engines, which may be the hardest part in developing our Trans-Tasman aircraft.
• Initial simulation results (very preliminary at this stage) lead us to change the Trans-Tasman design around somewhat. We are now aiming for a canard design (tail at the front) to keep the center of gravity in range, simplify the wing design (substantially - no wing tanks, no tail booms plus their associated wing twisting moments), and simplify the fuel system (one larger tank rather than two wings tanks + a header tank). Specs so far: 3m wing span, <3L fuel tank, 0.8m canard span, 1.4m fueselage length (but it will probably become longer and much less conventional...), approx 95 kmph cruise speed (very rough first estimate) at 4500 rpm.
• The wing will use a carbon fibre tube spar (hopefully an off the shelf tube), balsa ribs, and will be skinned with a boPET/mylar film covering.
• Canard will be attached to a moulded fibre-glass pod (containing the elevator servo), mounted forward from the main fuselage on another carbon tube.
• The main fuselage will be a kind of extruded-T shape, with the horizontal part of the T a flat-ish ~20cm wide by ~10cm tall body containing the fuel tank and wing joiner, and the vertical part of the T will be a combined rudder, engine scround, and landing skid (total about 20cm from bottom of rudder/skid to engine shaft). The engine will be mounted upside down, with the cylinder head and spark plug hidden in the rudder fin. Inlets in the fairing between the fin and the rest of the fuselage will provide cooling air for the engine (although it won't be putting out much power so won't be getting very hot). The carburetor will be mounted some distance forward from the engine on a tube so that the fuel can vaporize better (as the fuel/air mix gets sucked through the tube) before going into the engine. Exhaust will be vented near the center of the propellor, just outboard of the spinner. A small metal tube from the engine exhaust port needs to be fabricated (it also needs to house a thermocouple for the exhast gas temperature measurement used by the digital engine controller).

13th June

• I've been working on an Unscented Kalman filter as part of a new Inertial Navigation System in C++. (I managed to shoe-horn it into a university assignment on DSP programming. A disadvantage of this was that my code had to compile and work in Code Composer Studio (yuck!) for a TI DSP. The CCS C/C++ library support is pretty poor (compared to GCC and Linux anyway), and none of the major existing matrix libraries seemed to work (missing dependencies etc.), so I had to write my own really simple Matrix & Vector classes. The actual matrix algorithms needed (matrix inversion, Cholesky factorization etc) were based on those in "Numerical Recipes in C", so they seem robust enough, but my classes probably need some serious testing.) So far, the UKF itself is working, but the Inertial Navigation part (the INS "mechanization equations" that constitute the process and observation models in the UKF) are not yet finished or working. When this is all finished and going, it should give really good navigation: as much as 30-50% better accuracy than Extended Kalman filter approaches according to several papers). For more information, see van der Merwe's papers and thesis, especially "Sigma-Point Kalman Filters for Nonlinear Estimation and Sensor-Fusion - Applications to Integrated Navigation". Next step will be to change the UKF over to a square-root implementation (see van der Merwe's papers), which will reduce computational requirements by at least half.
• Working towards a simulation environment for our larger UAV system, and especially our Trans-Tasman endurance attempt, I have been investigating a bunch of software: FlightGear, JSBSim, CrrcSim, AVL, XFOIL, QPROP, etc. The latter three of these are Computation Fluid Dynamics (CFD) codes by Mark Drela of MIT, that can be used for estimating an aircraft's flight properties (lift, drag, stability, moments of inertia, thrust required etc) from descriptions of the aircraft (geometry, mass distribution, airfoil sections, engine characteristics, etc). These tools were all written for low Renolds number applications, which is what we are dealing with here, and are also all GPL'd. I am trying to work out how we can use these to model our Trans-Tasman aircraft before we build it, to test it in a "virtual wind tunnel", and to iterate the design according to the results. More to come...

8th May

• Today we were interviewed and filmed by TVNZ for One News, New Zealand's main daily news program. Watch us (streaming video) here and here.
• Been thinking more about the version 2 electronics. See here.

25th March

• Started playing with SCons Software Construction tool (replaces make, autoconf/automake, etc.) and applied it to my OpenGC code base. It is rather nice because you have access to a complete programming language and libraries (Python) inside your build files, so it is really easy to do sophisticated things. The Scons functionality itself works very well with automatic dependency analysis, compiled object caching, smarter rebuild decisions (has the file actually changed based on a MD5 hash, rather than just the timestamp ala Make). The SConstruct/SConscript files for OpenGC are much shorter than the CMake files they replace, but admittedly the CMake files included a lot of special casing for Mac/Windows build support which I have not yet included in the SCons files. With this change, as well as my ongoing work to eliminate unneeded dependencies in OpenGC, it is now much easier to compile (at least on my Ubuntu Linux machines - haven't tried on anything else...) compared to before. Now just type: $ scons to build, and: $ scons -c to clean.
• Started working on the KFilter projects' Kalman filter C++ templates/classes from http://kalman.sourceforge.net.
  • Changed from Make to SCons
  • Enabled compiler warnings, and fixed all the warnings... (I think some of them might be newly-introduced by gcc 4) - except the example segfaults with optimizations turned on on gcc 4 (Ubuntu dapper) but works fine on gcc 3.3.5 (Ubuntu hoary). Need to investigate/fix, as well as check it on ARM.
  • Investigated their sample implementation (an Extended Kalman Filter applied to observing a plane from the ground), and started working out how to apply it to our inertial measurement system.
  • Trying to work out what it is doing/how it works. There implementation seems to use a special form of the Kalman filter (UdU - something to do with upper diagonal form) and looks a lot more sophisticated/complex than other simpler implementations I have seen. They say it has better stability and numerical properties, but looks to be (much) more CPU intensive. Need to check.
• Also came across the Bayes++ project which also has C++ implementations of Kalman Filters (Extended/Unscented/etc.) as well as Information filters etc. but it looks like too much effort for us to use - it depends on Boost and the Boost BLAS (basic linear algebra) library, which I can't be bothered porting to ARM. The KFilter code uses their own minimal Vector and Matrix classes and has no major dependecies.
• Did some more work on my fixed point library, after being inspired by a recent post on the Gumstix mailing list.
• Did some more work on my OpenGC navigation display, but much work remains to be done before it is useful. Most importantly, we need to write the onboard navigation system (i.e. how do we represent and store waypoints, how do we navigate between them).
• John started working on GIS/mapping stuff for decent flight planning/navigation/mapping/etc support.

12th March

• More OpenGC stuff:
  

  

  OpenGC showing rudimentary navigation support.
  • Added basic navigation support using a heavily modified version of the upstream OpenGC navigation infrastructure.
  • Optimizing: reduced CPU usage of navigation code by about one third after profiling with OProfile.
  • Rearranged layout, as shown in the screenshot.
  • Fixed lots of bugs and made lots of general improvements (too many to list...)

28th February

• David has been busy with Endurance design and testing work and ordering parts:
  • Ordered three Enya 0.53 4-stroke engines to be converted to gasoline (96 octance automotive fuel) and spark ignition.
  • We have decided on 96 octance petrol as our fuel because it is widely available and cheap, and appears to have better calorific content per volume and per weight than the other more exotic fuels we were considering. We will use 5% oil, and because the engine will not be heavily loaded (except during climbs) - perhaps 100-150 W (about 1/8 horsepower), wear and heat should be manageable.
  • Ordered three O.S. 0.10 carbs (small throat, mechanically suitable) and on one of these, he has mounted two micro-servos (throttle and mixture).
  • Ordered a lot of wood and other supplies including carbon fiber tail booms and servos.
  • Built some spars (load-bearing lateral structural member in the wing), one half scale and one full scale, destructively tested the half scale one, and non-destructively partially tested the full scale one. After noting that his design didn't have enough torsional rigidity, he changed the design, which does make it slightly heavier. He is still confident that it will be able to withstand +2.5G/-1.5G loads (needed for flight in mild turbulence etc).
  • Selected a preliminary airfoil (probably won't change, but it is not a definitive choice yet). Having selected a airfoil, we can now pursue assembling some wings (David has lined up a laser cutter in Christchurch that will cut balsa for about $0.60 per meter). The airfoil has a thickness of about 3.6 cm with a 10" (25 cm) chord. This will be a nice clean and fast airfoil (David now estimates that optimal cruise will be 50 mph (80 km/h)), but because it is quite thin, we probably will need a fuselage fuel tank as well as the two wing tanks. David estimates that 2/3 of the fuel will be in the wings.
  • More pondering about launch and exhaust ducting (two main sticking points in the design). With 5% oil, only about 3-5 mL of liquid should be coming out of the exhaust per hour, so we decided to just vent the exhaust into the prop, right next to the hub/spinner. A thin film of oil on the prop probably won't detriment performance much, and may even improve it, by preventing icing and possibly cleaning bugs and what not off the prop.

18th January

• More OpenGC improvements:
  

  

  OpenGC enhancements to date (showing random test data).
  • added engine instruments (RPM, CHT, EGT, battery and alternator voltages, space for a few more; maybe mixture and radio RSSI)
  • added command line options to enable test mode, set zoom, set font path etc., and a new global Configuration manager to manage settings.
  • more refactoring, making use of inheritance to reduce code duplication in the gauges, reducing use of global variables, consistency, etc.
  • work on engine instruments and general graphic improvements
  • heaps of other stuff :)

16th January

• Made a bunch of improvements to the OpenGC-based glass cockpit:
  • made the window resizeable
  • reduced CPU load by only rendering when there is new data.
  • fixed copyright header block so it is consistent with http://www.opengc.org/licensing.html
  • refactored much of the code (indentation, ogc_ prefix, moved files around so the directory tree is simpler and shallower, fixed the Find___.cmake files so CMake actually finds things, made configuring much faster/easier, eliminated commented-out dead code).
  • eliminated the config file (opengc.ini), hardwired instrument set up (there was only one option there anyway), hardwired the default window size and zoom (but it is resizable now and zooms nicely anyway), and added code to automatically work out the font path.
  • improved the graphics, fixed the anti-aliasing (yay!), fixed up some small rendering bugs and changed some of the colours (what works in a 777 doesn't necessarily suit a UAV).
  • started to add engine instruments (RPM, CHT, EGT)
  • added flight director (i.e. marks on the GUI what set-points the autopilot is trying to regulate to) for roll, pitch, heading, altitude, and airspeed.
  • added test mode for when there is no datalink (i.e. all the time when developing).

• Other stuff since last post:
  • design of Mark 2 hardware and software is progressing, albeit quite slowly.
  • more thoughts and designing about the Endurance attempt, including estimating possible Routes. We need to be able to fly at 40 mph for about 40 hours.
  • more inkjet hacking (know how to drive it and how to mount it now), but we might will probably just use a carbueretter with in-flight adjustable mixture control instead. Simpler and probably lighter weight, but harder to calibrate and control well (optimal mixture control servo position is a function of air temperature, fuel temperature, pressure/altitude, fuel pressure, RPM).
  • decided on a Enya 0.53 4-stroke engine with spark ignition and an OS 10 PET carb, with two micro servos, one each for throttle and mixture.
  • thinking about how to launch it -- the pusher propellor complicates things quite a lot. Will probably air-launch it from on top of a large and powerful model aircraft (David already has a suitable one).
  • David is progressing quite well with the airframe design. Need to design an airfoil. David has a wing design and contruction method worked out. We estimate that we can make an airframe that weighs around 1 kg, then we have 1 kg of [engine, electronics, servos, battery, etc.], 2.5 kg of fuel (~3 L), and about 0 - 500 g of wiggle room to keep us under 5 kg.