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)
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:
Wouldn't it be safer and more standard to implement Mavlink 1.0 inside C-OSD ?
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.
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 !
The logged attitude of 0, 0, 360 is indicative of a bug the dev team recently became aware of and are looking in to....
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.
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.
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...