A distributed and scalable autopilot architecture is attractive to me due to space and sensor positioning demands on my airframes.  The existing range of autopilots simply doesn't fit.  The uNode (microNode) is the result of my desperate attempts to fix this.  uNode is a very cutdown version of Pixhawk with a little bit of AUAV-X2 added.

Board contents are:

• STM32F427 Processor (as per pixhawk)
• 64Mbit onboard flash - no sdcard
• 4.5V to 10V input power supply or power from USB.
• No USB connector, only 0.1" holes
• MAX21100 6dof sensor - an experiment and about the only sensor I have space for.
• No I/O buffers.  ESD and EMI protection on everything.
• Power for GPS module
• SRAM Battery backup
• Pinouts for
  • 2x I2C
  • SPI
  • 3x UART
  • 2x CAN with transceiver onboard
  • 8x servo outputs
  • PPM input
  • SBUS or Spektrum module input.

Total manufacturing cost in volume may be ~$25.

These boards are designed to fit into the servo hatch of a wing.  They have about the same area as a slim wing servo.  There is no USB connector because there is absolutely no space for one.  There is no sdcard because it is not accessible.  Some other potential uses:

• As a CAN connected failproof board
• Failproof remote servo expander
• Remote sensor interface - I2C sensors over long wires without interference.
• A backup, get you home autopilot.  Just add GPS module.

The board uses the same processor as the pixhawk so that the same OS and software is used.  You pick whatever you need to run in what node location.  The dual CAN can then be used to setup a robust network to transport the data between nodes.  The PX4 firmware is structured to be very suitable for this.

The prototype hardware functions well.  The onboard flash works and I have had bi-direction file transfer over mavlink-ftp working.  I had it working...  The PX4 codebase has taken another leap forward, broken my branch and I somehow need to catch up again.

That's all for now until I manage to make it do something useful.

Being able to see what the autopilot is thinking in real time is a valuable tool for tuning autopilot behaviour.  FPV is normally used for this but I can't use it on my aircraft.  A good solution is to use minimOSD on the ground driving a video monitor.  I have had a few flights with this and it works very nicely.  minimOSD is amazing but still limited in what it can do.

The raspberry pi is very cheap, has a composite output and a good graphics accelerator.  I need the composite video for the pirate eye monocle I use. Using a laptop and HDMI->composite converter is not reliable and very poor quality.  To get a reasonable frame rate (~20fps) the openGL ES2 3d graphics capability of RPi needs enabling.  The amazing pi3d python library was the obvious choice.  It will also run on an x86 linux machine running x so development time is quick.

There has been a bit of optimising to get reasonable performance.  The resulting python module is a functional proof of concept but it is a way from finished.  At 20fps it consumes 70% of the processor time.  That leaves plenty of capacity for drawing all of the status items and some capacity for drawing more 3d objects.

I do have my own plans to add to the raspiHUD.  What would you put on the display?  Proximity warnings with 3d position?  Ground elevation map?  Local weather conditions?

With some advanced fiddling RPi might be encouraged to put its camera output on the background, then it would become a proper (but large and heavy) in flight FPV HUD.  I don't plan to do this myself.

More raspiHUD details and documentation available here (LINK FIXED)

Learn more about pi3d here

paya tech video monocles

The pirateeye monocle from paya technology.  HUD flying without the need for a buddy.

ps. if anyone else thinks my hud design looks like it is smiling face then you are not alone.

I would like to introduce the community to a mixer method used to fly complex aircraft in manual, fly-by-wire and autonomous modes.

The main challenges of mixing are:

• Flexibility to do anything you want.
• Easy to use and prevents mistakes
• Fly-by-wire capable.
• Field programmable
• Easily expandable
• Failsafe compatible

Fly by wire needs control inputs from your transmitter.  Imagine if your tx mixes together elevator and aileron for a delta wing.  If the autopilot looks at a servo channel, it has no idea if you are commanding pitch or roll.  This means that the transmitter can’t do any of the mixing.  All mixing must be after the autopilot.

You can now choose to have one mixer for AP and one for manual or one combined mixer for both.  Maintaining one complex mixer is difficult but two would be asking for problems.  With one mixer, the mixer must be placed after the failsafe.

When setting up mixers for a complex aircraft, the number of mixer settings is enormous.   For a full wing, there are at least four controls that mix into four channels. Each mix has between three and five mix points with some mixers being conditional on state.  That is around 100 parameters for the wing alone.  A live connected GUI is needed to make home setup and field tuning possible.

Experimenting with different mixer setups is part of tuning the aircraft for different flight phases.  The user may wish to add and remove different mixer functions.  The type of mixer function should be easy to change and it must be easy to add different functions to the system.  This needs a GUI that automatically adapts to new functions and support for automatic code generation.

For the past year I have been flying a mixer that solves these problems. The toolchain consists of automated code generators and a gui with live mavlink communication.  The flexibility has meant that I can accurately tune the settings, certainly beyond the level my radio can.  Without the live GUI, the setup time would be far too long and critical field trims impossible.

This implementation is far from perfect. The key problem is that mixer settings are a one-way communication.  There is no way to verify what settings are inside the mixer.  There is no way to make sure that different versions are synchronized.  These are the reasons that this toolchain has not been promoted for general use.

In the long term I would like to see a system that solves these problems.  My thoughts are for something like the mavlink parameters discovery. There may be other ways to improve this.  I am open to suggestions if anyone is interested.

For an overview of the project, visit the wiki here:

https://code.google.com/p/pyfedit/wiki/HowToEdit

Note that the latest version is mavproxy based compared to the standalone version in the wiki.

Some credit must go to Paul G.  One of the key ideas he gave me was how to safely mix manual and autopilot commands to enable smooth autopilot override.

Airspeed control is critical when flying sailplanes.  You want to fly close to stall but never beyond it, since that will normally cause a tip stall and great loss of energy.  How do you teach an autopilot to fly on the edge of stall?

One solution is to teach the autopilot about the aircraft geometry and aerodynamics.  First you start with the wing section.  From the wing section you can use a simulation tool to generate aerofoil polars (picture above from XFLR5).  These polars describe the lift, drag and moment coefficients generated at different airspeeds and flap settings.

From the aircraft position and the amount of corrective pitch movement you need, you can calculate the acceleration you require from the wing.  This is known as load.  From load, geometry and aircraft mass, the lift coefficient can be calculated.

From lift coefficient and the wing polar you can calculate the required angle of attack for the wing.  From the required angle of attack, you can calculate required elevator pitch.

From the wing polars, you know the maximum possible lift coefficient.  Now you can avoid increasing angle of attack beyond Cl(max) and avoid stalling.  This is only half of stall prevention.  The other half is in energy management.

Both when gliding and under power, the aircraft loses energy due to drag.  For a glider this determines the descent angle.  For a powered aircraft it determines the engine power.  By using the estimate of drag coefficient from the wing section polar, the autopilot can set the target climb/descent rate and pitch angle.  When power is applied, it adds energy to the system so the estimated climb rate and target pitch increases.

Working in combination with basic estimated climb rate is airspeed error feedback.  Airspeed error is converted into meters of potential energy error and added to the target pitch.  The combination of target estimate and energy feedback are great for stall prevention.

Document describing airspeed by energy management

If you change flap settings then the wing polar changes.  As the flaps are changed, the autopilot has to interpolate between the different wing flap polars.  The result is a smooth transition between airspeeds.

This method also automatically re-trims the elevator for different airspeeds.  It also automatically does airspeed control fadeout.  It also reduces dependency on PID gains.  Some optional gains are still required for different flying styles.

One problem with this method is that it relies on knowing the initial wing-elevator incidence.  At high airspeeds the aoa is small and sensitivity to change is high.  The solution is to have a feedback from the accelerometers comparing to calculated load.  This error feeds an integrator which retrims the elevator.  The result is an even better trim for low speed flight.

Despite all the stall prevention, my first test flight resulted in terrible tip stall when turning downwind.  Adding a little bit of extra airspeed command resulted in lovely smooth turns.  When I went back to the estimated airspeed calculation, I had set airspeed setpoint 2m/s too slow.

If this all sounds new, it isn’t.  It is simply re-applying the basics that we know about aerodynamics.  If you are interested in aerodynamics basics you might start here

The project is based on a branch of MatrixPilot based here:

https://github.com/crashmatt/MP_Aerodyn

The original Matrixpilot project wiki is here:

https://code.google.com/p/gentlenav/

Aerodyn uses the MatrixPIlot code base for hardware drivers and IMU.  My thanks go to the MatrixPilot team for their support and innovation.

The Aerodyn project also uses a flexible field programmable mixer which is used to move the flight surfaces with accuracy.  This is used to fly this 5m, 10 channel aircraft.  More about that later.

This is the Vladimir models Graphite 2e.  It is a fairly typical skinny, lightweight, efficient fully moulded motor glider.  Despite its 3.1m span there is not much space for anything.

THE CHALLENGE - HOW TO FIT AN AUTOPILOT AND TELEMETRY SYSTEM IN A GRAPHITE 2E

The removable nose section is filled with motor ESC and battery.  It just fits a 36mm diameter motor.

The receiver, rx battery and BEC is mounted somewhere under the wing. 

No room for servos up front, they are mounted in the tail fin. 

There is plenty of space in the hollow wings.  Access to that space is limited to the 4 servo hatches.

The compact UDB2 is now looking like a tight fit at 38*70mm.

I do not own an APM but that is looking like a 40*75mm double decker.  No hope!

Should I stick to my trusty Cularis with its middle age spread, healthy dose of cellulite (foam) and numerous surgical implants?

If you wish to see more pictures and a video have a look here

http://www.hyperflight.co.uk/products.asp?code=GRAPHITE-2E&name=graphite-2e