Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 2 of 2

Thread: Making a Twin Engine RC Airplane Safe (TwinAir Project)

  1. #1
    Junior Member
    Join Date
    Jun 2015

    Making a Twin Engine RC Airplane Safe (TwinAir Project)

    Hi Teensy Community,

    "Making a Twin Engine RC Airplane Safe" - a Teensy project called TwinAir

    (RC means Remote Control for anyone unsure)

    Some background information

    A friend and I have been flying model airplanes for about 15 years. We have always been a member of a local RC club and over the years we have watched numerous twin engine aircraft come and inevitably go (in a trash bag) after sadly crashing and breaking into many pieces. In almost all cases it has been due to one engine failing and the remaining engine taking the plane to the scene of the crash. This may surprise you (or maybe not!) that flying a twin engine RC airplane on a single engine is a non trivial task when you are standing potentially hundreds of meters away, however, with correct use it not only results in a higher performance platform but one that has a significantly greater chance of being able to return to the field and land in the event of the loss of one engine.

    The solution for most RC fliers with twin aircraft is to simply cut the remaining engine in the event of a failure and "dead stick" land. While benefiting from the performance gain, the reliability and return offering a twin gives is lost. This is understandable because a high performance airplane will rapidly become uncontrollable without prompt and correct use of rudder. It will most likely enter an uncontrollable spin and roll while the user is confused as to which engine and which input needs to be applied.

    In summary for twin RC aircraft:

    - It is hard to know which engine has failed from a distance, made even harder if you can't hear the model due to other RC planes in the circuit at the same time
    - Recognition of an engine failure and prompt and use of rudder is essential, again difficult to reliably achieve from a distance
    - Engine failures at low speed, just after lift off are particularly vicious with powerful RC aircraft due to lack of inertia and a lot of excess power
    - It is very easy to confuse an engine failure (and the associated yaw induced roll) as simply a conventional 'wing drop' and the natural tenancy is to use aileron to 'pick up' the wing when really rudder needs to be used instead.

    A couple of years back my friend suggested we build a twin engine airplane and this got me thinking... A human simply isn't reliable enough to deal with the inevitable loss of engine that will happen at some point (glow engines stop running for all sorts of reasons) for the aforementioned reasons. Followed by the conclusion.... this task has to be completely delegated to a computer. The rudder input doesn't have to be perfect, it just needs to be about 80-90% right and the plane will continue to fly in a perfectly manageable way (100% would be ideal, I'll mention about that later on!).

    Building the Plane

    It turns out that myself and my friend are a good combination in the RC hobby field. He's a great engineer and builder. I am a mediocre computer enthusiast and programmer. During the winter of 2016/17 he set about designing and building the airframe from scratch using SolidWorks, his CNC mill, hot wire cutter, 3D printer, lathe and various other machining equipment. The result was what we affectionately refer to as The Prototype

    This post is about the Teensy project so I won't mention more about the physical build process, that is for another post on another forum.

    Developing the Software

    During the winter of 2016/17 I started work on a system to manage everything I wanted to achieve. Fortunately I already owned a Teensy 3.1 so I started by using that. The list of desired features was fairly long, but the essential ones were as follows:

    - PWM edges from the 8 output channels of the RC receiver have to be accurately timed
    - Output/control of all servos
    - Engine RPM
    - Airspeed
    - Ground logic through the use of a proximity sensor (possibly in future we will use squat switches)
    - RPM synchro using a PID loop to make the aircraft "sing" and not "wah wah wah"
    - Telemetry downlink and voice annunciations on the FrSky X9D Taranis Plus transmitter we use (e.g. "Right engine fail")
    - Execution flow is critical and must not block for any significant time, under any circumstances, even if a sensor fails or physically disconnects
    - Fallback assumptions in the event that one or more sensors fail (e.g. ground proximity)
    - Datalogging of all important data for subsequent analysis

    So I got to work learning and programming as I went along. I fairly quickly transitioned to the Teensy 3.6 as it was becoming apparent we needed more inputs and outputs. I also moved the MicroSD datalogging over to a separate Teensy 3.6 because despite many hours of testing I wasn't able to satisfy myself that the SdFat library wouldn't block execution flow in the event of a card failure or loss of contact under extreme vibration scenarios (these engines produce a lot of vibration, even more if a prop gets damaged!). By early summer 2017 we had a working prototype ready for test flying which (yet untested) satisfied all of the goals above. Here are a couple of pictures of the two Teensy 3.6's shrink wrapped and installed next to the FrSky receiver:

    Early 2017

    Early 2018

    With an open loop controller, the amount of rudder required for an engine failure in this context is a function of:

    - The split in RPM between each engine
    combined with
    - The airspeed of the vehicle

    The more throttle (and therefore RPM) on the live engine, the more rudder is required. However the faster you are going the less rudder you require roughly as a square magnitude. Engine RPM is computed by timing edges from a hall sensor on each side (we use Allegro MicroSystems A1120LUA wired in accordance with the datasheet typical wiring diagram). Airspeed is an analog input from a Freescale MP3V5004G attached to a pitot probe you can see on the end of the right wing in the first image. We selected the MP3V5004G for airspeed sensing because it is affordable, supports 3.3V and works up to 3.92kPa (the aircraft flies up to 125 knots).

    By the end of the summer of 2017 we had reached a point where all of the initial design goals were complete. We could deliberately cut an engine in flight, the rudder was managed automatically and the aircraft was still easy to fly (albeit, from the perspective of an experienced RC'er).

    Improvements and 'Feature Creep' - Winter of 2017/18

    Over the winter of 2017/18 various improvements were made to the airframe and software. It turned out the VL6180X proximity sensor we were using for ground proximity logic wasn't reliable enough in bright sunlight so I wrote in support for the VL53L0X and then ultimately the LeddarOne as a long range solution.

    Support was also added for a dynamically controlled Futaba GY401 gyro to soften up the roll in single-engine mode. You remember I mentioned about getting the rudder 90% right, the gyro takes care of the last 10% in yaw induced roll. It also helps to make the platform feel more stable and stress free when single-engine.

    An MPU6050 accelerometer on the sensors I2C bus was added to record G-load and roll rates (currently just for interest, but useful for diagnosing problems, again - there is naturally a lot of vibration on a reciprocating engine platform)

    Capacitive main tank fuel quantity sensing (sent via the telemetry datalink to the transmitter) using Teensy's Touch sensing

    Various annunciations were added too, e.g. to remind you to put the gear up if you forgot after going around or after takeoff

    As it stands today the pin connections are as follows:

    Software and Downloads

    Disclaimer first:

    I'm not a professional programmer, just a hobbyist! I also know there are a lot of improvements I can make to the structure and code itself and this is an ongoing project. I'm writing this simply because this code controls an airborne vehicle (in my case) that flies at 140mph and weighs 5kg, it's not a toy and must be treated with respect at all times. I want to give this code in the hope it might be useful to the community. The comments in the header of all the code files reminds you this code is distributed under the GNU General Public License. There is no warranty or guarantee, if you want to use it in your twin engine RC plane it's at your own responsibility. Don't blame me if things go wrong :-)

    Right that bit is out of the way, here it is!


    Edit: I forgot to mention which libraries the software uses:

    - SdFat - for the Datalogger
    - FrSky S-Port telemetry library - for FrSky telemetry
    - Bolderflight SBUS - Not currently in use but it's an option to enable with the caveat that testing is required

    Structure of the Code

    Some brief mentions:

    Uses a central dispatch model - tasks are dispatched at timed intervals (roughly between lines 470 to 660)

    Most of the settings are defined here. Eventually I'll get around to reading this off an SD card and developing a Windows program to configure it with

    This class handles most of the day-to-day flight tasks and interacts with most other classes to discover the state of sensors

    This is a wrapper around actual sensors, it attempts to provide a common interface to I2CDatalink regardless of which physical sensor is in use, again work is required here


    (Apologies for the wind noise and cellphone quality video, it should be available in 1080p60 at least)

    The numbers you can hear being read out are the airspeed, in knots, from the telemetry.

    The first one is a normal takeoff and a short clip of flight. This gives you an idea of the aircraft and the performance (yep that's me flying it)

    The second video is a genuine engine failure (hence my friend's excitement). Most engine failures while testing we have had to induce manually, this one was genuine after a glow plug failed. The Teensy and software handle everything smoothly, there is no use input required other than to normally fly the plane and understand there is reduced performance available. You may notice the transmitter announces "right engine fail", this is from the telemetry downlink.

    Example of telemetry data displayed on the receiver

    Prox - millimetres from the ground

    Prop Synchro PID loop

    Here are two examples (taken from the datalogger) of the PID loop back in 2017 when it was somewhat more "un-tuned" than it currently is today!


    If you take an interest to this project and you can identify any parts of the code I can improve upon I would be hugely appreciative. The PID loop in particular, specifically tuning it for the prop synchro. If there are any obvious bugs, issues or bad coding practices you can identify please let me know too.

    Thanks for reading, I hope this was useful
    Last edited by Zaite12; 07-05-2018 at 04:59 PM.

  2. #2
    Join Date
    Jan 2017
    Most excellent
    Thank you for sharing this. The twin engines really do sing.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts