ArduCopter version: 2.0.49 (modified to send data to the osd through telemetry serial port)

osd: diy Arduino Pro Mini + MAX7456 (custom firmware with functions from c-osd)

GoPro video:

osd video:

See attached log (crash starts at line 10,137)

The log shows a throttle in cut, but I didn't reduce the throttle to the minimum. I think that it's something related to ArduCopter code (maybe produced by my modifications...) because AC stopped sending serial messages to the osd just in the moment before the throttle cut (1.8s of data blackout). It's not a battery problem.

Strange things in log:

  • lines 10,141 to 10,157: there is no GPS data (see GPS time).
  • lines 10,142 -> end: yaw is wrong (360º), pitch and roll are wrong too (0º).
  • line 10,104: Throttle in is 0.

Views: 742

Attachments:

Reply to This

Replies to This Discussion

 

Wouldn't it be safer and more standard to implement Mavlink 1.0 inside C-OSD ?

 

http://qgroundcontrol.org/mavlink/start

 

Doing this you will not need to patch Arducopter each time a new version is available.

 

Mavlink is now in version 1.0.0.

I am probably terribly outdated with regard to the stability of the ardupilots and arducopters recent developments, since I did perceive it to be too unstable to fly anywhere nere populated areas since last spring. I do actually not feel comfortable with the practice of letting the customers/users doing all the testing of the software and hardware at the "bleeeding edge".

Hope something will change here, so I can go back to flying what I in other respects regard as a beautiful autopilot and initiative.

Best regards,

brakar

 

This is not fully exact. Only the GIT version is bleading edge and sometimes untested. It is dangerous to use this, except if you know what you do and the associated risks.

 

The version available in Mission Planner is tested by developpers before inclusion and works nicely for most users. Eventually there are still some things to improve, but the basis are here and work.

 

I flew version 2.0.42 to version 2.0.49 without any crash during 7 hours with a custom frame, very different and about three time heavier than the Arducopter frame. I pushed this frame to 20 m/s and 150 meters altitude without trouble.

 

I feel that the actual version is at release candidate status, and that final version will be in the near futur if reports are good.

 

Try it !

 

 

Marc,

 

The logged attitude of 0, 0, 360 is indicative of a bug the dev team recently became aware of and are looking in to....

Marc,

Thanks so much for submitting this. I'm reading over the logs now. Very helpful, but I have some questions for you.

 

In the video I can hear the throttle drop at about 14 seconds. In the log I can see the throttle go from 74.1% to 0%.(current logs at 1hz)

CURR: 741, 1394476, 10.5700, 29.2600, 1327

CURR: 408, 1400981, 10.7200, 19.4800, 1334

CURR: 355, 1406493, 10.8400, 14.3600, 1338

CURR: 319, 1411144, 10.9100, 11.4300, 1342

CURR: 0, 1414884, 11.0100, 8.1900, 1344

CURR: 0, 1414884, 11.1400, 3.5800, 1346

 

 

Your current draw drops (the end #) as well, so this is internally consistent.

At this point did you bring the throttle down manually? Was it fully down like you were coasting with a plane?

 

Within seconds of the crash did you move the Yaw control at all?

 

I'm asking because you managed to re-arm the copter in-air. That could only happen if you disarm, and arm again by throttling to 0 and doing a full left Yaw, then a full right Yaw for more than a second each.

Jason

 

 

I was trying to loose altitude, so I reduced the throttle but I don't think I reduced it to 0 (I'm not sure 100%). It happened too fast, I don't think it was enough time to disarm and arm it, also I don't remember to do a full left/right yaw, but as I say I'm not sure 100%.

When I disarm AC the osd shows statistic info and it didn't show up in-air before the crash.

Oliver, yes the best option is to use Mavlink but it was easier to me to use a custom simple protocol.

What are you powering apm/rx with? BEC or ESC? I had a uninsulated connection problem on my castle 10amp bec that caused several crashes like this before I found the 5v out on the bec had gradually had its insulation pulled down from the terminal that caused the +- to sometimes touch so causing loss of power to apm/Rx. Since it wasn't consistent I didn't notice and assumed it was a rx problem. When I would get the quad from the crash it would always be on normal so it just didn't dawn on me that it was a power problem.

Directly from ESC (next flights I'll use a 3A BEC I've recently bought), but I don't think this is the cause of the crash because APM didn't reboot (at the end the osd gets flight statistics from APM and they show info about the complete flight). Maybe a power drop may cause the AMP malfunction without rebooting it...

Maybe this is related to the I2C bug...

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