Plane: handle Twin Engine motor failures

[iskess]

This was originally posted on DronesDiscuss but I never got a reply, I apologize for the cross post.

Is there any interest in code to support a twin motor airplane? I have flown the Twinstar for years, and now I'm considering the new My Twin Dream, which is a similar but larger version.
A twin has the opportunity to provide redundancy, but without proper pilot training, or in this case autopilot code, it can actually increase the likelihood of a catastrophic crash.
A remote pilot is unable to quickly identify a motor failure because he lacks the benefit of feeling the sudden yaw. Also his reaction is likely to be to correct with aileron rather than rudder. An autopilot could identify the failure nearly instantly. Assuming the sideslip Controller were activated, the autopilot would add rudder to counteract the asymmetrical thrust. Once the rudder is nearly at full deflection, the throttle on the remaining engine would be reduced to maintain directional control. The new Stall Prevention code would come into play keeping the bank angles reduced at slow speeds, and adding a pitch down bias to keep the speed up.
It would also be helpful to allow for a second throttle channel. This could be used to inhibit current to motor that has been developing no thrust for a period of time. This might prevent a fire. Randy's motor failure test code could be used to test inflight failures. The Asymmetrical thrust could also be used to synchronize the motors (manually), or provide better ground (or sea) handling.

Here is a recent video of the MyTwinDream suffering a loss of one propeller in flight. The MyFlyDream autopilot handled the situation quite well and the pilot didn't even identify the problem until after landing.
https://www.youtube.com/watch?v=nscyn5uTVhM
It could have been a differnt story if the failure occurred at slow speed, high power (ie, takeoff). A windmilling prop would have hurt too.

Thoughts?

I volunteer to beta test, it sounds like fun.

[tridge]

yes, I think it would be very nice to support twin engine planes like this. It will be quite a large change, so may not come soon, but thanks for opening an issue for it!

[iskess]

Here is another interesting twin on the market:
http://www.rcgroups.com/forums/showthread.php?t=2349770

[Jman841]

I am very interested in this as well. I have just setup a My Twin Dream with a pixhawk and want to have support individually for the motors. Currently I am using a Y cable off the same throttle input, but, +1 for support for twins! There are quite a few great twin platforms out now.

Thank you!

[splenkingforth]

+1 for support for twins
Some basic yaw control by sync power would be a good start.

[AndWik]

As I have written before:

I have a sea plane with two motors. One on each wing. In all situations, except one, they can run at the same setting but:
Before takeoff and after landing it is very difficult to navigate.

Adding support for dual motors for Ground Steering or Always would be highly appreciated

Another issue is that the PixHawk is unable to drive two Multistar Esc from one RC port. It took my some time to discover why the motors refused to start after arming.

The work around, for me, is to make a small PCB that is able to drive the two Escs.

Thanks
Anders

[mikemonti968]

+1 for twin support, Differential thrust would be great to have, as my twin has a castor front wheel no nose gear servo for ground steering.
Thanks
Michael

[Drone-Nerd]

One more needs support for twins!

[ktraglin]

I'm very interested in this, as well. Since quadcopters, etc. essentially use differential thrust for yaw control, I imagine using some of that code could make it happen... but I don't know nearly as much about it as I'd like to.

[iskess]

So there are two different proposals here. Mine is to code the rudder (and other control surfaces) to handle asymmetrical thrust with just one motor for redundancy.
The other idea that has been proposed is the opposite, to use the available asymmetrical thrust of two motors to replace the need for a rudder.
I guess this could safe a little weight and building complexity, but if one motor fails the plane will not be able to continue flight.
I prefer the conventional approach with a rudder, but perhaps with the added benefit of improved ground handling for sea planes.

[oktanio]

I have two identical pairs of ESC & brushless motor combinations. But both of these motors have different speed (Asymmetrical Thrust). How do I fix this?

Thanks.

I use AeroStar Advance 120A ESC Opto and i have ardupilot.
And for now, i use for manual mode flight

[ktraglin]

I would start with making sure the motor bearings are clean and properly lubricated, in addition to using your radio to calibrate the ESCs. Beyond that would probaly require some microcontroller programming for further calibration/synchronization, (like with an arduino, rasberry pi, etc.) but I haven't done that, yet.

[oktanio]

thanks bro..

if i have trying to calibrate the ESCs using my radio but obtained the same results, is there another way for calibrate/synchronize the motor?

[R5fan]

I was a little surprised to find no support for dual motors. Any updates on this? Is this possible using custom mixers and if so, any pointers on how to do that ? Ive been reading the docs but frankly, its over my head.

[marvinlange]

I am running twin engine 10 foot wing this would be very helpful for ground steering as well as some yaw control wile flying as spoilers are nice but a waste of resources. I also have twin p-38 no rudder

[jeffstreet]

+1 for twin-engine support. BormaTec has a twin-engine plane (Explorer) and is working on a new one.

[tridge]

support for twin-engine with differential thrust for yaw is in PR #5708, and should (I hope!) make it into 3.8

[iskess]

That's great news @tridge. I'll leave this open since this issue was originally more about handling a motor failure than differential thrust.

[ktraglin]

This is awesome news. Thanks so much.

…

On Tue, Feb 14, 2017 at 7:03 PM, Andrew Tridgell ***@***.***> wrote: support for twin-engine with differential thrust for yaw is in PR #5708 <#5708>, and should (I hope!) make it into 3.8 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1861 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOVt_aDvrojlB6QJTHOopsRcJl0GPKA6ks5rckDmgaJpZM4Ddait> .

[marcmerlin]

@iskess do we know that AP does not automagically handle this?
Once I took off with a branch attached to one side of the plane. I was crazy asymmetric drag and AP just flew the plane beautifully. Things only got ugly once I switched to manual mode and realized how much correction AP had applied.
My point is that if you lost a motor you probably want close to full trust on the remaining motor to keep flying speed, Again, AP would detect the loss of airspeed and increase trust as needed, and once it sees the yaw, it would use rudder and then (probably) ailerons to correct.
In other words, I think it may "just" work.
I don't know how to setup the simulator to try this virtually, but if not, you could setup your twin with an RC controlled servo that cuts the signal line to one of the 2 motors. Then you go at high altitude to give time to recover, you go to FBWA or FBWB, cut the motor, and see what happens. Of course, be ready to re-enable the motor right away if things look bad.

[iskess]

Marc,
I think you are a pilot, but perhaps you don't have your multi yet. The autopilot would behave just like a pilot who doesn't have his multi engine rating. Engine fails, pilot feels a roll and loss of thrust so he feeds in aileron and adds more throttle to the good engine. If this pilot is skilled he will know to add rudder, not just aileron. This is analogous to the autopilot having been tuned in yaw. Most users haven't turned on the yaw controller, and this would help but still is not enough.
If the plane has plenty of thrust to maintain airspeed on one engine, and plenty of rudder to counteract the asymmetrical thrust, the autopilot might succeed in bringing the plane in safely. However things go bad really fast if the plane gets slow. The autopilot will add max throttle, the increased asymmetrical thrust requires more rudder, but the rudder is less effective at slow speeds. There is a speed called Vmc where the thrust on the remaining engine exceeds the rudder's ability to maintain heading, and the plane will quickly roll inverted. This has killed many pilots and requires special training (or coding) to make some counter intuitive countermeasures. The pilot must reduce the throttle and lower the nose to regain airspeed and directional control, then carefully feed the throttle back in to stop the descent. The autopilot needs be coded to know that it must reduce the throttle and accept the altitude error when the rudder servo approaches its maximum deflection.

The difference with your experience of the branch on your wing is that the autopilot only had the asymmetrical drag to deal with. When you add in the element of losing half the power, the likelihood of getting too slow to keep the rudder effective gets very likely, especially if the autopilot is hell bent on maintaining its altitude at all costs. Add in the effects of torque, P-factor, spiraling slipstream, and induced lift over the wing and the matter gets much more critical.

[marcmerlin]

@iskess you are correct that I don't have my multi rating :)
Thanks for describing in more details how indeed asymmetric trust can be superior to what the rudder can counteract, but can't you then use the ailerons to counteract the roll? (I guess it depends on the airframe)
That said, taking better optimal measures requires a lot of steps that are very airframe dependent (assuming that airframe even needs them) but more specifically also requires for AP to actually know that more motor died (more than sensing a yaw/roll to correct). Technically AP has 2 RPM meters given an ESC that gives the right signal, but I never got it working on my castle ESC. Then, it would take a lot of specialized coding and testing for honestly something that almost never happens.
Given that there already isn't developer time to write features that are much more needed than this very uncommon case on an uncommon airframe (how many people fly multis with AP? I'm not saying 0, but let's be honest that it's a very small number).
That said, if there is already yaw control via differential motor yaw that got checked in, you can also hope that when the plane tries to correct yaw, it would use both rudder, and also lower power on the good motor, the one creating the yaw, helping further, right?
So, I'm still hopeful that it would probably just work in many/most cases without motor death detection and custom, probably mostly untested code.

[iskess]

Marc,
Aileron won't stop the Vmc roll for the reasons I hinted at in the last sentence of my last post. Once it starts there is no stopping it without reducing the thrust.
The needed logic isn't as complicated as you are making it out to be. The autopilot doesn't need to detect the motor failure, and it better that it doesn't because it might be a prop that came loose. The autopilot simply needs to identify when it cannot correct a yaw divergence with the rudder any more, and reduce the throttle and lower the nose to maintain speed regardless of altitude error. That's it.

You have an interesting point about using the new twin motor yaw support to automatically reduce thrust on the remaining motor. The problem is leaving enough power available to maintain flight. If it could be prioritized to use differential thrust only after the rudder fails to control the yaw, that would assure that you have all the power available as long as the rudder can handle it.

[magicrub]

I'll leave this open since this issue was originally more about handling a motor failure than differential thrust.

I've updated the issue topic to reflect the discussion of motor failure mitigation instead of adding the twin-engine support.

[marcmerlin]

@iskess I'll have to do some reading up on twin flying, I have a problem figuring out how a plane with dihedral can't stop a roll with ailerons unless the wings are stalled.
As for "leaving enough power to maintain flight", I don't think it's how things work. The logic would reduce power until directional control is regained. After that, whether it's enough power to maintain level flight is a separate issue, but ardupilot will pitch down to maintain flying airspeed and then try to pitch back up to the stall limit speed. If there isn't enough thrust to maintain altitude, so be it. It will maintain controlled flight up to the ground (although in my last single motor , motor failure, apparently it maintained flight until it hit the water and sunk, and missed dry ground by only a very short margin :( )
I understand you said that after regaining directional control and airspeed you can slowly raise the motor power again to a limit related to the airspeed and rudder effectiveness. I'm sure the current code does not handle this but it may just be able to fly the plane without that extra logic if the differential thrust control and the motor power control somehow manage to work together correctly and do this already (it would have to be tested of course).

[iskess]

Marc,
I think you'll enjoy reading about multi engine aerodynamics, it was my favorite rating to get. Without detailing it, the overall point is that you can not maintain a stable flight attitude if any of the 3 axis are not in balance. Roll is coupled to yaw (especially with dihedral) so if you can't stop the yaw rotation you won't be able to stop the roll, even with ailerons. Maybe on an aerobatic airframe with oversized ailerons, but then it would appear like a flat spin which isn't very useful for getting home.

In the rest of your post it is not clear to me whether you are talking about what the code can already do or what we are proposing. I agree that we need it to "reduce power until directional control is regained". As it is, the code will continue to use differential throttle to maintain yaw since the asymmetry remains. We need the rudder to do all the work, and only use the differential throttle when the rudder approaches its limit.

[marcmerlin]

@iskess sorry that my last post was not very clear.
I was mostly trying to say, without knowing what the code does, that there are 2 control loops linked to the motor:

1. control power to maintain target speed (and if speed is too low, AP will also pitch down)
2. control power to each motor to affect yaw

So if one tells you you need more power for airspeed/altitude and the other one tells you to decrease power for yaw control, I don't know which one wins or whether they get overlayed in a way that things kind of just work out in most cases.
So basically maybe not extra code is needed and maybe yaw control via differential power already decreases power to the last known engine (the one that takes you to the crash site :) ) in a way that indeed you can resume normal flight.

[magicrub]

Sounds like if there is enough rudder authority available then the yaw PID Integrator will compensate for the induced yaw as-is. It only gets really complicated of you Max or the rudder. Problem is as airspeed goes down from lack of thrust, the throttle Integrator will learn to go up too and the throttle revving will make for a very sloppy ride.. but I think it will still fly.

Major premise: if there is enough/unlimited rudder available, none of this matters. Please confirm.

[iskess]

Yes, if you have unlimited rudder, but as airspeed drops the asymmetrical thrust increases and the airflow over the rudder decreases. So there is always a speed (Vmc) at which you lose control. If the rudder is big enough that speed can be low enough that it's safely below the autopilot's min speed. Most model airplanes are overpowered and have small rudders as they are not designed with a single motor failure in mind.
If you have a giant rudder, I wonder if the yaw PID will need to be tuned down for normal flight, making it not effective enough in single engine flight. Maybe someone can play with this in SITL.

[magicrub]

during a motor failure, there will be a huge yaw bias. The Yaw PID.Integrator is designed to detect and compensate for such things. If it maxes out then you're a goner anyway

[iskess]

Well that's the whole point of this request, so you won't be a goner. We need simple code that detect when the rudder is approaching max. Then it just needs to reduce the thrust a bit and pitch down for airspeed. This might mean that the plane cannot hold altitude and that has to be allowable.

[knudj]

Dear all,

happy that I found your issue.

I am a dedicated twin model pilot (Robbe Commander, Conzelmann Partenavia, Guan Li / Hobby King Canadair CL 415) and experienced some explainable and less explainable crashes with these planes. Specifically the last crash was recorded by a GoPro and clearly revealed what I guessed already before: the asynchronous shut-down of the engines in case of failure or low battery is a challenge if you are a model pilot and need to guess what is going wrong with the model some hundred meters away from you.

I can see the following options (some already discussed) which should resolve different issues:

1. Standard auto pilot acting on the rudder => should resolve asynchronuous motors or motor failure at reduced throttle
2. Extended auto pilot acting on the ESCs in case of max. rudder => should resolve all kind of failures, even lost props
3. ESCs communicating with each other => also should resolve all kind of failures, since volts, amps and rpms are measured internally by the ESCs
4. Extra controller (e.g. Arduino) in between the receiver and the ESCs, measuring volts, amps, prop speeds (e.g. by photo diodes) and acting on the PWM signals to the ESCs => also should resolve all kind of failures

Now option 3 is not available yet (at least I do not know these ESCs) and option 4 asks for an extra controller with some sopisticated programming.

Thus option 2 (as already proposed by Iskess) might be the most feasible option, however asks for someone, who is familiar with the Ardu Pilot code as well as for a platform for fixed wing models featuring a multiple motor port.

Is there some idea who could be the programmer and which could be the platform?

Happy to hear from you :-)

[Naterater]

Also would highly recommend this, and the new BL_Heli32 ESC's could make it really easy to support. Cause it to trigger a failsafe and limit the maximum bank angle. When twins suffer an ESC failure, they will usually fly alright, but they can't turn as aggressively, otherwise they enter death spirals.

[Naterater]

@WickedShell, maybe this could be handled as a "battery failsafe" for telemetry ESC's that have current/voltage/RPM sensing.

[knudj]

Dear all,

last year found myself tinkering with ArduPilot and HKPilot32 (from Hobbyking) mounted inside a Volantex Ranger 1600 – thus no issues with twin engines ;-)

Now our model air field was closed down due to the corona pandemia and I unintentionally spent more time in the work shop tinkering about twin engine models. Since I am not familiar with the ArduPilot code I decided to follow my option 4 from above and have an Arduino board in between the receiver and the ESCs and come up with a stategy to act on the signals to the ESCs in case of engine failures.

Engine failures will be detected either by comparing the amps or the rpms of the brushless motors. I deceided to do both for the sake of redundancy. So, which sensors to be used?

I am quite happy for some time using RC by FrSky (Horus X12S, X8R), and I did not feel the need to change from the FrOS to OpenTX up to now. However, there are some annoying limitations regarding dual sensors. Dual sensors can be configured and visualized, however can not be addressed by dedicated variables inside the TX. Dedicated variables (e.g. Current1 and Current 2), however would be needed to do some alarming and failure acting inside the TX. I already addressed the issue of dual sensors to FrSky, but they seem not to be willing to extend the variable list of FrOS for dual sensors (OpenTX possibly would do better, however at the moment I want to stick to FrOS).

I found another way to overcome the limitations from above. Some bright people came up with telemetry code for the FrSky system (e.g. OpenXsensor, or the telemetry code of Pawelsy) that brings in the freedom to use custom sensors and allocate them to different variables inside the TX. At the moment I only want to use the telemetry for alarming purposes, however signal processing inside the TX would also be possible then.

My „Twin Engine Monitor“ now encompasses:

• FrSky X8R for RC and telemetry (via S-Port)
• Arduino Uno R3 for signal processing (X8R, ESCs and sensors)
• ACS712-30A (AZ Delivery) for current measurement (hall sensor, low cost, small size)
• HW-SM824DUL-RPM Sensor (Hobbywing) for rpm measurement (low cost, no optics required, rpm signal is deduced from the phase signal of the ESC)

I broke down the Arduino program into pieces for testing, and each of the pieces already worked as intended. I had some concern about the processing time, however I found that the clock time of the ATmega 328 (16 MHz) allows for ample Arduino code lines without impacting the real time performance of the RC system.

After a proof of concept it should be possible to extend the ArduPilot code respectively and get rid of the Arduino board. Also new ESCs with telemetry output could be used instead of individual sensors.

For now I like to add a photo of my test rig (Hobbyking Bushmule, Owon Mixed Signal Oscilloscope, Uni-T Tachometer) and will keep you informed about new findings.