On my last flight today (quadcopter with APM2 running v2.9), at one point quite close to me I saw my quad do an uncommanded yaw, climb and start flying toward me. Looking at the tlog later I see it went into RTL but I was in Stabilize at the time and did not switch to RTL!

My Rx is set to go to ~920ms for failsafe but the logs show CH3/THR as normal so no failsafe?

I have 6 modes setup on my Tx via 2 switches, mode 6 is RTL (1877ms), mode 1 & 2 are Stabilize (1074ms & 1274ms), when I realised something was amiss I switched from STB2 to STB1 and it switched out of RTL and back into Stabilize as shown on the attached kmz file, then it flew normally and I landed with no problem.

So why on earth did it do an uncommanded switch to RTL?

Did it detect some kind of failsafe error? If so what?

Views: 2724

Attachments:

Reply to This

Replies to This Discussion

Same happened to me today.

Here is my tlog (accidentally I hited the clear logs button so I only have telemetry file).

I was trimming channels 1 and 2 so I could then use save trim on channel 7 after landing.

While hovering, RTL went on without my command and quad started to go away (notice that I only armed quad after 3d fix).

I only was able to bring quad back because I switched channel 5 to alt hold and regained control.

After looking for mission planner I noticed that I didn't set home location and the quad was actually going in the direction of the default home location (Gulf of Guinea - Africa). It acted like na RTH (Return To Home), not an RTL (Return To Launch).

Hope we find some answers here.

Regards,

Miguel

 

Attachments:

One thing I need to clear up is that the home position on the mission planner is separate from the home position that the copter uses for RTL.  The mission planner's home location is only used for centering the map displayed.

The copter's home position is where you armed the motors.

I definitely wouldn't expect the copter to attempt an RTL to africa unless you actively set the home location from the mission planner (I think there's a button on the MP somewhere to allow you to set-home although I've never used it).

Hello Randy,

Thank you very much for your reply.

My only suspicion then is a PPM enconder failure (maybe because I have the default logs on the APM board plus raw).

Is there a way to replicate a PPM encoder failure in FG simulator (something like pulling off ch3 receiver cable)?

Also, I'm having trouble running FG simulator with Quad 2.9 HIL (sorry for the off-topic, but if anyone knows a fix would be appreciated).

Regards,

Miguel

Same happen to me twice. The attached tlog happened on about 95 % , I flew to around 30 meter height with position hold(but on screen show unknown) mode, it changed to RTL by itself(the ch5-in was still at posisition mode) and climbed up to 180 m , it scared me so I changed it to stabilized mode and descended to ground. My RF receiver is Frysky with telemetry , my Frsky TX LCD panel showed rssi normally.

 

 

Attachments:

tangtl,

    Well, from looking at your logs I imagine that was a bit of a scary situation.

     Did the event happen twice during this one flight?  It appears that around 87% all the radio inputs stop changing but I'm wondering if that actually happened or if you were just holding the controls very still.

     I think your issue is quite different from the others here because it looks like you do not have the throttle failsafe enabled so the ppm encoder check would not happen.

    I notice that it looks like you haven't done the radio calibration in the mission planner?  Did you skip that step?

    Do you think it's possible that you just lost radio contact?  Have you ever tried a bench test in which you turn off your receiver to see how the inputs react?  I.e. have a look at the mission planner's radio configuration page and turn off your receiver to see how the green bars react.  My guess is they stay at their last position.  If that's the case, I wonder if it might be that you lost radio contact and at the moment you lost contact you happened to be giving it some extra throttle and perhaps pushing one of the sticks forward.  in which case the APM would have no way to know that you weren't controlling it anymore and it would just start flying off.  It's interesting that at the same time that it started to fly off, you lost telemetry.  I wonder if perhaps your telemetry and radio are interfering with each other.  Are they very close together?

Hi Randy:

  Thank you for the reply.

1. My board is APM1

2. It happen onece on 1/26, once on 1/27.

3. I held it at position hold till the height is stable.

4. You are right , I did not do the radio calibration in the mission planner, I only did it once at v2.5

5. I have tested all modes with  mission planner , I set my Frysky receiver failsafe with RTL and all stick at middle position.I turned off TX then checked the mode is at RTL.  the mission  planner's radio configuration showed as expected values.

6.  My telemetry is mounted at the motor arm far from radio receiver.

7. It never happen before V2.9,   even I flew high at 300 meter.

tangtl

Graham,

     If you look in your dataflash logs, at line 64965 you had a short lived ppm encoder failure it seems.  That means that the APM believes that it did not receive an update from the ppm encoder for 2 seconds.  Did you notice any loss of control just before it switched into RTL?

    I notice that you have a lot of logging turned on (both RAW and MOTOR messages in particular).  Turning on this much logging does cause performance issues in fact, it's very clear from the PM (performance monitoring) message that 25% of the main loops are running over their alloted time of 10ms.  I strongly suspect with all that logging on your main loop is running well below 100hz.  I don't have any reason to believe this would cause the apparently ppm encoder failure but I strongly recommend you reduce the logging unless you're actively investigating an issue with the motors or gyros/accels.

Randy,

Could you please explain what makes you say that there is a "short lived ppm encoder failure" at line 64965 of Graham's log file?

At that line I only see RAW gyro and accel data (Gyro X -> -0.55 / Gyro Y -> 0.07 ...).

I'm using the log browse tool in Terminal Tab of Mission Planner.

Just trying to learn a little bit :)

Regards,

Miguel

Sorry, typo.  It's line 63959

The error messages are very hard to find in the dataflash logs so my standard procedure when looking at people's log files is to open them in excel as well and filter by the message type column.  I usually check for ERR and it popped out.  ERR, RADIO, 2 means ppm encoder failure (or more precisely "LATE_FRAME".  The full list of error codes are in the defines.h file (although there aren't many others yet).

The FS, 2 that appears right below it is the throttle failsafe but it's triggered by the first error.

The FS, 0 that appears a few rows further down is actually saying that the error is resolved (0 = ok) so it was a very short lived problem.

The thing that doesn't make sense however is that we should not have recieved any updates for roll, pitch, yaw or throttle in the 2 seconds before the event but they do seem to be changing...:-(.  I'm not sure how this is possible so i need to look into this more tomorrow (it's very late now in tokyo).

Please note that the ppm encoder check is enabled/disabled along with the throttle failsafe so you can disable it.

Thanks for that, now we know where to look, (& sorry we're keeping you up :)).

I've asked before and will dig out the thread again for it but can I suggest a visual and audible notification on the Mission Planner when a "recognition of failsafe condition" actually does occur?

Thanks Randy,

And have a good night of sleep :)

Regards,

Miguel

Hello Randy,

I was sniffing the code an I came into this possible issue:

Error registration location. In read_radio() it calls APM_RC.get_last_update()

radio.pde

if ((millis() - APM_RC.get_last_update() >= RADIO_FS_TIMEOUT_MS) && g.failsafe_throttle && motors.armed() && !ap.failsafe)

{

Log_Write_Error(ERROR_SUBSYSTEM_RADIO, ERROR_CODE_RADIO_LATE_FRAME);             set_failsafe(true);

}

 

The call that "allows" the error registration. It says "interrupt safe" in get_last_update().

APM_RC.h

        uint32_t _tmp = _last_update;        

        while( _tmp != _last_update ) _tmp = _last_update;

        return _tmp;     };

The interrupt that changes _last_update APM_RC_APM2.h /**************************************************** *   Input Capture Interrupt ICP5 => PPM signal read ****************************************************/ void APM_RC_APM2::_timer5_capt_cb(void) { (...)             _last_update = millis(); (...) }

 

Imagine if you have a interrupt "avalanche" from ppm enconder (_tmp != _last_update), could while cycle in get_last_update() take too many time (say greater then 2000 milis)?

 

Sorry for the "code avalanche" :S

Regards,

Miguel

RSS

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service