Erratic flight, momentary loss of control. Please help with log analysis.

Hello,

So today I was flying my S800 hex with APM 3.1.3 and pixhawk, I did 3 short flights. The purpose of these flights was to test my new gimbal. For gimbal control, I'm using mission planner, 3DR data radios, and a PS4 controller. For flight i'm using a taranis Tx with dragonlink UHF module and a 12 ch receiver. The Tx and Rx have passed a range check, so I do not think a receiver failsafe was activated. I did not have the battery options properly set on my laptop, and after some flights, after landing I noticed the laptop was asleep. :/ Not sure if thats related, but worth mentioning I guess.

The first flight, I noticed the heli seemed "twitchy".. like it would fly smoothly and suddenly twitch in one direction regardless of my input. I landed.. the motors and esc were all normal temperature.

The second flight went smooth, and without error. I landed a few times to adjust my gimbal.

The third flight.. towards the end of my flight my heli became unresponsive for about 1 second. It began to gain altitude and then control was re-gained and I was able to land safely. 

I've never had problems with APM before, so I've never had a reason to read my log file. Today I am trying to learn to understand the logs but it is very overwhelming for the first time.. I'm not sure what to look for. I notice in log 46, ctun, towards the end of the flight, throttle out becomes very erratic, while throttle in remains the same. I'm not sure why this is... Also, In log 48, the last flight. my log file seems to end before I ever land, like the log stopped recording? Is that right?

Anyway. I'm pretty lost as to why my copter is behaving like it is. Any help would be really appreciated. 

Thanks,

Nick

Views: 775

Attachments:

Reply to This

Replies to This Discussion

If the log stopped before the flight ended, it may be because of a 'brown out'.

My guess would be that the gimbal is drawing excessive power.

Is it connected to the same BEC as the APM?

Maybe try a flight with the gimbal mounted, but NOT connected, to see it's OK.

Hello, I did think it could have been some kind of current issue, but my gimbal is powered from a separate 12v BEC. The gimbal does however share the same BEC as the video Tx. 

Pixhawk has it's own 5v BEC, and the aux rail of pixhawk also has it's own 5v BEC. So that's 3 BEC's...

It might be possible the gimbal is drawing to much power from the 12v BEC, but would that effect pixhawk? I thought it would just effect things on that 12v BEC, and everything else would still be fine.

I've attached a pic of my wiring diagram.. Thanks for your response and time!

Attachments:

After more research, and trying to learn the logs more.. I've realised in log 46, when i click "show map" in the log browser, it shows a map of a flight i made several days ago when everything was fine. But the log file name is "2014-04-24 20-36-09 46.log", so I'm not sure why the date in the filename was yesterday, and the map of the flight was actually one I made several days ago. Maybe that is the wrong log... Everything worked fine for that flight.

On the last log pixhawk recorded, log 48, the log that stopped recording for some reason.. I have tried to do some research on brownouts to see if that's the cause.

http://copter.ardupilot.com/wiki/common-diagnosing-problems-using-l...

Taken from log 48, the last log pixhawk recorded from my flights yesterday, Here is a screenshot of my CURR - VCC graph. It seems to be in the normal range that was shown in the link above, anything look abnormal here to you guys?

OK! I think I am making some progress in figuring this out. 

Maybe the reason my log file ended abruptly was because it got corrupted when I read it from the pixhawk, as stated here. I'm willing to accept this.

I pulled log 48 directly from the SD card of pixhawk, and Voila! The log file is complete. 

The log confirms a RTL was activated very briefly, wich completely explains the momentary altitude gain (set to RTL 200ft) and loss of control. Now my question, is why was RTL activated? Was it an R/C failsafe? My reciever failsafe is indeed set to RTL, but I did a proper range check according to dragonlink manual and everything was good.

Here is a screenshot of my log, showing RTL activated, directly followed by alt_hold mode. I'm not sure what to look for in the log to determine what caused RTL to activate, but I will continue researching.

I have attached the complete log file .bin from my SDcard. Any help with pinpointing this issue is greatly appreciated! 

Thanks,

Nick

Attachments:

After more log analysis I have concluded that my dragonlink receiver did infact briefly failsafe, as it's the only explanation I can come up with.

When RTL was activated, the PWM value was exactly what I set the failsafe RTL value to in the dragonlink reciever. 

Now I have to figure out why my reciever is entering failsafe, especially after it passes a range test. I was also flying with a new radio for the first time yesterday. the FrSky Taranis. Maybe I don't have the radio set up correctly,

I have the Taranis set up as:

"Internal RF: OFF

External RF: ON

Module: PPM

Channel Range: 1-12

PPM Frame: 30.5ms 300u - pulse"

Can anyone confirm if this is correct? Any ideas?

Thanks,

Nick.

Check to see if Vcc dropped below 5 volts at the RTL point. This is what seems to be happening to me see http://diydrones.com/forum/topics/not-sure-if-this-is-the-correct-f...

Regards,

Robert

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service