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.
Replies
Maybe this is related to the I2C bug...
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
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....
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
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.