Discussions

Moderator

Uncommanded RTL, but why, there was no failsafe condition...(v2.9)

Posted by Graham Dyer on January 27, 2013 at 3:04am

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?

2013-01-27 08-36-52.tlog

2013-01-27 11-53 28.log

2013-01-27 11-53 28.kmz

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –
Follow

Replies

  • ben February 21, 2013 at 5:31pm
    where would i delete the failsafe ch 3 function. i have ardurover and wen i turn off receiver output 3 throttle turns on and stays on. im jusy wondering where i wd change that in the code?
  • graham newton February 3, 2013 at 7:05am

    Damn I should have looked at this thread earlier...

    expensive mistake.

  • Oliver February 1, 2013 at 4:23pm

    Yesterday I tested RTL on my Hex (APM2, 2.9). I've posted a short video clip on YouTube at https://www.youtube.com/watch?v=Y3HT64dc7bk  titled A Sane and Safe First Test Flight of RTL on a Hexacopter . Maybe it and in particular the written description will help some folks here who have more experience at the bench and on the computer than in the air.

  • Developer
    Randy January 29, 2013 at 7:28am

    Ok, I've found the issue and fixed it in the 2.9 branch and I will be pushing out a 2.9.1 release as soon as we can get it through testing.

     

    The problem is in arducopter.pde's read_radio function.  The value passed back from APM_RC.get_last_update() is the time the last radio frame arrived.  It's possible for that frame to arrive right in the middle of when the line below is being executed and if we're really unlucky it's possible for us to be just crossing the boundary of one millisecond to the next.  In this case the result of the millis() call can be one less than the result from the APM_RC.get_last_update() call.  This makes the result a small number - big number = -ve number.  Because time is an unsigned int, it overflows to a very big number.  So the APM ends up thinking it hasn't received a radio packet in 49 days.

    // turn on throttle failsafe if no update from ppm encoder for 2 seconds
    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);
    }

     

    It's just bad luck if these things all happen at the same time.  I don't think you can protect against it.

    Sorry for the troubles and anxiety over this.

  • Developer
    Randy January 28, 2013 at 7:34am

    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.

  • tangtl January 28, 2013 at 7:17am

    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.

     

     

    2013-01-27 16-30-37.tlog

    https://storage.ning.com/topology/rest/1.0/file/get/3692603404?profile=original
  • Miguel Pereira January 27, 2013 at 9:26am

    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

     

    2013-01-26 15-59-42.tlog

This reply was deleted.

Activity