Replies to This Discussion

ModeratorPermalink Reply by Graham Dyer on January 28, 2013 at 9:10am

I didn't notice any loss of control but at the time it was a mix of hovering and a bit of free flight, I was flying only about 10-15m away from me.

I don't need MOTORS but had left the logging of them on trying to diagnose an ESC issue, I'll turn them off now, RAW was checking for vibration but likewise I'll turn it off.

The RTL condition (or Recognition Of a Failsafe Condition - hey, made my own acronym - ROFC) is great as it will tell us users something is wrong and react accordingly, it would be fairly important of course to eliminate any false alarms but if not a false alarm I/we need to figure out what's causing it.

• ▶ Reply

Permalink Reply by Jiro Hattori on January 29, 2013 at 4:55am

I would like to know you guys using what  kind of RX and TX just for my curiosity. 

In other word, I am still scare to fly my bird with the serious issue.

Randy told this issue in other thread that is coming from combination of PPM signal loss and RTL setting.

Is that all for the explanation and reasonable ?

 ( Please do not misunderstand me by my poor English.)

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on January 29, 2013 at 5:11am

Hitec Aurora 9 & Optima 7 Rx

• ▶ Reply

Permalink Reply by Miguel Pereira on January 29, 2013 at 5:12am

Hello Jiro,

My TX is a Futaba 6EX 2.4ghz

My RX is a OrangeRx Futaba FASST Compatible 8Ch 2.4GHz Receiver

What the program "says" is that the PPM encoder didn't send data to APM within a 2000 miliseconds timelapse.

So something is making APM see that the timelapse between last full PPM frame read and current time is greater than 2000 miliseconds.

That's what we are trying to debug.

The best way to recover from this event is to have a flight mode switch.

That's what I have done to recover: In stabilize mode I lost control (RTL triggered) and then I've changed channel 5 switch to alt hold so I regained control. Then I changed to stabilize and landed.

Regards,

Miguel

PS: For the devs, Could the PPM encoder send a sync pulse width so close to the 8000 miliseconds of pulse width that trigger the full frame that "some times it's skiped"? (I should read the ppm encoder firmeware code...).

• ▶ Reply

Permalink Reply by Jiro Hattori on January 29, 2013 at 5:36am

@ Graham

Thank you for quick response.

Mine is both Futaba T8FG TX and 617F RX.

@Miguel

Much better now by detail explanation. I can fly my bird:-)

Actually, stabilized mode might be a life line in many occasion.

• ▶ Reply

Permalink Reply by Miguel Pereira on January 29, 2013 at 6:00am

Jiro,

You're right about stabilize. Nontheless, I would force a mode change with the mode switch: something like alt hold/stabilize or loitter/stabilize.

I'm not familiar with mode switching part of the code, so this is just to be sure that there is a forced mode change.

Keep also in mind that accidents can occur so we have to keep our mind out of "now nothing bad gona happen". Be confident but think fast. Last weekend that RTL was a death scare but thinking fast allowed me to try a mode that I never tried (alt hold), and that just saved my quad.

Like in general aviation after crash procedures, next step is trying to recreate the condition and debug code/functionalities.

Regards,

Miguel

• ▶ Reply

Permalink Reply by Tim Green on January 29, 2013 at 5:46am

Can enabling all the logging unduly affect performance in any way?

• ▶ Reply

Permalink Reply by Miguel Pereira on January 29, 2013 at 6:10am

Hello Tim,

APM program has to take time to write to dataflash. That said it necessarily affetcs performance (longer loops, interrupt handling, ...)

How that interferes with the radio interrupt functionality? That's a good question.

Regards,

Miguel

PS: By the way, is dataflash writing using some kind of interrupts (I presume yes)?

If so, it can be confliting with ppm interrupts (one more code zone to explore ...) :)

• ▶ Reply

DeveloperPermalink Reply by Randy on January 29, 2013 at 8: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.

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on January 29, 2013 at 8:41am

49 days...LOL

Thank you for finding it Randy, just glad it's found and will be fixed, every step forward is fantastic!

• ▶ Reply

Permalink Reply by Miguel Pereira on January 29, 2013 at 8:42am

Nice catch Randy!

" I don't think you can protect against it."

What about a fix like this (not right sintax):

unsigned long time_lapse = millis() - APM_RC.get_last_update();

unsigned long MAX_TIME_LAPSE = 423600000; //The ppm failure couldn't last longer than 49 days :)

if (((time_lapse >= RADIO_FS_TIMEOUT_MS) && (time_lapse <= MAX_TIME_LAPSE)) (...)

Regards,

Miguel

• ▶ Reply

Permalink Reply by Kevin B on January 29, 2013 at 1:55pm

Nice Miguel, I see your idea was (more or less) added in the branch. I also looked in to Marc's post regarding an alternative fix using abs() to force the "+" sign:

http://diydrones.com/forum/topics/arducopter-2-9-released?commentId...

Seems it should work, but I'm not smart enough to know all the potential side effects of doing it one way or the other. I just wanted to bring Marc's idea to this thread to make sure the devs have everything on the table before committing. Although, I wouldn't mind a quick lesson on why one way is more/less elegant than the other.

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• Next ›
• Page