[posted] Making a Twin Engine RC Airplane Safe (TwinAir Project)

Zaite12

Member
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!

View attachment TwinAir Code.zip

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:

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

GlobalConfig.h
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

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

I2CSensors
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

Videos

(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

ZMlYGLO.jpg


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!

Lrodz4S.jpg


SmTJ5pZ.jpg


Improvements

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:
Back
Top