Had a near miss on the workbench the other day when the Mode was not properly recognized on my APM 2.5. When the APM was started it was in RTL mode despite the fact the transmitter switches corresponded to MANUAL mode and the  PWM value being read was 1823ms (MANUAL MODE). After about 20 seconds the APM went to full throttle on the workbench! Fortunately no damage done to either myself or to anything on the table.

I have the following setup for each of the modes:

Mode 1 PWM      0-1230        11    RTL
Mode 2 PWM 1231-1360         5    FBW-A
Mode 3 PWM 1361-1490       12    LOITER
Mode 4 PWM 1491-1620         2   STABILIZE
Mode 5 PWM 1621-1749         0   MANUAL
Mode 6 PWM 1750+               0   MANUAL

The attached tlog (2012-12-15 12-52-44.tlog) shows the input on CH8 (my mode switch) to clearly be above 1800ms which should respond to the non-adjustable MANUAL mode, instead it has been interpreted as RTL mode as can be seen in the MP. After 20 seconds you can see CH3 go to 100% throttle.

Before I submit an 'issue' for this I wanted to see if anyone else has experienced any unexplained misinterpretations of the mode switch inputs. I'm stumped as to the cause as this appears to be a clear case where the PWM value is well above the 1750ms threshold to be in MANUAL mode (not user changeable) throughout the entire file yet the MP shows that the APM believes it is in RTL mode and after 20 seconds it switches to full throttle.

I am using an APM 2.5 running 2.68, I have a uBlox LEA-6, Airspeed sensor, Attopilot voltage and current sensor, 3DR 900MHz telemetry and a MinimOSD v1.1 running MinimOSD Extra r458. Power is supplied to the APM via a Castle Creations 10 Amp BEC and the Minim OSD is powered in a two stage format with the digital side powered by the APM and the Analog side powered by the vTx and a separate battery.

If anyone has any ideas I'd be happy to check anything out. It's been to windy or cold here to do any actual flight tests yet, and until I find an explanation to this behavior I'm grounded as I don't trust it's behavior. Manual must always mean Manual.


Nathaniel ~KD2DEY

Views: 1479


Reply to This

Replies to This Discussion

Apparently this is happening more than I thought. I found another tlog that shows this same behavior. I'm not sure what firmware version I was running at the time, possibly 2.67 but I must not have had the motor connected at the time. I don't understand whats happening but I am concerned about safety at this point. I can't have it going into RTL when I'm sitting on the ground have it go to full throttle and not be able to switch to Manual.

Anyone have any ideas?


No Solution from me at this stage, but are you logging the PPM inputs as well as the outputs to see if the radio is causing the issue ?


Also, although I have a Futaba T8FG, on another thread it was suggested as setting RTL to Mode 4 as this is what the APM uses as failsafe.


Therefore this is what I have mine set too.


It may be worth posting the .log file instead of the .tlog file to the above.


FLTMODE1  - STAB -           0 Flight mode when Channel 5 pwm is <= 1230
FLTMODE2 - POS HOLD -  8 Flight mode when Channel 5 pwm is >1230, <= 1360
FLTMODE3 - LOIT -             5 Flight mode when Channel 5 pwm is >1360, <= 1490
FLTMODE4 - RTL -              6 Flight mode when Channel 5 pwm is >1490, <= 1620
FLTMODE5 - ALT HOLD -   2 Flight mode when Channel 5 pwm is >1620, <= 1749
FLTMODE6 - CIRCLE -       7 Flight mode when Channel 5 pwm is >=1750


It may be worth swapping Mode 1 from RTL to a different mode such as Stabilise.


I also notice your Mode 11 (RTL) is Mode 6 on my configuration, could this have anything to do with it ?


I'm also using a T8FG with 6 modes. I'm not sure what you mean by

setting RTL to Mode 4 as this is what the APM uses as failsafe.

Are you using ArduCopter code? I'm not familiar with the implementation of the modes in ArduCopter code, but I'm not sure how moving RTL to mode 4 would change anything for ArduPlane. In ArduPlane code Mode 6 is always Manual and it corresponds to a PWM value of 1750ms+. As for the PWM inputs they are all in the tlog I just didn't graph them all. Is there a difference in the log vs. tlog file?


Nathaniel ~KD2DEY

I found another log file from earlier the same day where I cycled through all the modes. Everything seems normal in this graph.

You can clearly see each of the modes and their corresponding PWM values.

Here is a copy of the parameter file I extracted from the above tlog file.


Here is a recording of the MP HUD showing the behavior in the first tlog. The log file doesn't start playing for about 20-30 seconds and only lasts for about 30 seconds. I added 3 user items to the HUD CH 03 IN, CH 04 OUT, Mode Switch (CH 08) IN, and Mode Switch (CH 08) OUT raw PWM values for all. You can clearly see that the Mode switch input and output remain static and that CH 03 IN remains static while CH 03 OUT goes to full throttle about 20 seconds after the log file begins to play.


Someone must have something to contribute here. I'm sure this isn't the expected behavior, if it is it's a real safety problem and I need help figuring it out. So please offer up your 2 cents here.


Nathaniel ~KD2DEY


Looking over the Arducopter docs HERE, it states that the mode input to the APM should be on Chan 5, like in Steven's post notes.

Are you taking Chan 8 of your RX and connecting to APM Input Chan 5?

If so,I guess the APM won't care as long as it sees the PWM values and equates them to your Flight Mode defined settings.

-=Doug ~KB4FEM


Thanks for the reply! Yeah I guess the ArduCopter code and the ArduPlane code differ in this respect. The Arduplane users guide as shown below (except I'm using APM 2.5 not 2.0) has the input on CH8, although if I remember correctly I think you can assign any channel 5-8 to this function.

As you can see in the examples I've posted above (especially the one with the modes labeled) you can see that the APM is reading the various flight modes correctly when I toggle the switch on the transmitter. You can also see in the first two pictures that CH8 remains above 1750ms when CH3 OUT goes to full throttle. Mode 6 in ArduPlane code is fixed as Manual and cannot be changed by the user, a PWM value of 1750 or greater should always equate to Manual except when failsafe is engaged, in which case RTL will be initiated and the parameters that govern the response will kick in. As you can see in the recording of the HUD I made above (link to youtube) after the APM initializes it goes to RTL and remains there despite the fact that the Mode Switch (CH8) PWM value is 1823ms; well above the Mode 6 threshold of 1750ms. I've seen quite a few MultiCopter related posts where people are complaining about unexplained full throttle issues and I'm wondering if there isn't a larger issue here? I was really lucky not to have lost a finger! I was reaching for the tail boom (it's a pusher config much like a Bixler) to disconnect my FPV vTx battery when the full throttle kicked in. It was an exciting few seconds I'll tell you.

I still think it has to be something that I either don't yet understand about my setup as opposed to some fundamental flaw in the code. I would think that if it were something basic in the code more people would have responded to this post with similar stories. But that doesn't help me much.

For the record my inputs are configured as follows:

CH 01 RX > CH 01 IN APM

CH 02 RX > CH 02 IN APM

CH 03 RX > CH 03 IN APM

CH 04 RX > CH 03 IN APM



CH 07 RX > CH 07 IN APM (MinimOSD Panel Select)

CH 08 RX > CH 08 IN APM (Mode Switch)


Nathaniel ~KD2DEY

After re-reading the wiki section on failsafe function setup and operation for the APM 2.x I don't believe that this is truly failsafe related although the timing for RTL mode does match the setup for long failsafe response there isn't a matching response for the default short failsafe response CIRCLE. The thing that really bothers me is that I have found several tlogs where this seems to be happening and the timing appears to be consistent. This would suggest that the behavior is not related to a hardware issue (faulty switch for example) but rather something I don't understand in the code. If Tridge or someone else gets a chance to look at my tlogs and render an opinion I'd appreciate it!

Hope everyone has a Happy Holiday!


Nathaniel ~KD2DEY

Hi Nathaniel,

The first log you posted (20121215125244.tlog) shows that it went into RTL due to GCS failsafe. A GCS failsafe event is when FS_GCS_ENABL is set to 1, and it loses contact with the ground control station, receiving no HEARTBEAT messages for 20 seconds.

Given the timing in the logs, I think your ground station was not successfully sending any messages at all to your APM. Was it configured to send HEARTBEAT messages?

Note that FS_GCS_ENABL defaults to 0, so this behaviour is not the default. It should really only be enabled when you are doing long distance flights and want the plane to return home if it loses contact with the ground station.

I've added a note to the documentation about the dangers of enabling this option.

Cheers, Tridge


Thanks for the reply! Seasons Greetings!! To be honest I don't know how to specifically configure the APM to send Heartbeat messages. Is that something separate from configuring the 3DR radios for telemetry? I'm glad to hear it's not something abnormal. I do intend to fly outside LOS from time to time and I want to be sure I always have telemetry so I can review the logs in the event my plane goes down. Is there something I need to check to make sure I'm getting heartbeat messages?


Nathaniel ~KD2DEY

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service