Quad drops alt at random on Auto...
Hi guys,
I had quite a scare today, I was testing out my quad on auto, I've done this before but this time I added more waypoints and differences in altitude for the waypoints.
Everything was going well but halfway through the auto flight, the quad started to drop in altitude continually up to a point where it reached the ground. Thankfully I was keeping a close eye on it and managed to swap back to stabalise mode before it completely crashed.
The above is a screen shot of the Tlog showing how the altitude started to drop consistently after way point 5. I have attached the full Tlog, the crash happens at around 34%.
I tried troubleshooting it myself and here's what I have concluded thus far:
1. Shouldn't be a GPS problem, GPS status in the logs seem consistent
2. Shouldn't be a battery problem as I flew the exact same route on the same battery after this crash and the quad flew the whole route without incident.
3. Shouldn't be the wind, flew a few times in different wind conditions at different locations and with different batteries, and 1 out of 2 times this would happen at a random location
4. Shouldn't be a receiver failsafe problem as I was able to swap back to stabalise after it clipped the ground and flew it back without issues.
I'm out of ideas and I'm not too familiar with the different tlog values to fully understand the graphs.
My current setup is as follows:
Stock DJI 450 frame, ESCs, motors and 8" props
AMP2 with Sonar, 3DR telemetry, Castle BEC at 5.3V, uBlox GPS, external LEDs
Zippy Compact 3S 3700mah 35C lipos
ArduCopter V2.7.1
Please advise thanks in advance!
Ervine
Tags: 450, APM2, DJI, altitude, auto, crash, drop, mode, quadcopter
- Attachments:
-
-
2012-08-26 15-34-27.tlog, 1.4 MB
-
Replies to This Discussion
-
DeveloperPermalink Reply by jasonshort on -
Would you have the flash log?
-
Permalink Reply by Ervine Lin on -
Unfortunately I can't access my logs, I'm getting the "No dataflash inserted" similar to http://diydrones.com/group/arducopterusergroup/forum/topics/accessi... but even in CLI>test>logging it says the same thing.
Will see if I can load up 2.7.2b and fly a few rounds again..
-
DeveloperPermalink Reply by jasonshort on -
go to the CLI, "logs", then "dump"
Jason
-
Permalink Reply by Ervine Lin on
-
Hi Jason,
Unfortunately typing "logs" in CLI doesn't do anything at all. It just stops responding to additional commands. Not sure what's wrong, didn't have a problem before.
Is there something else I can test to make sure the hardware is not an issue?
-
Permalink Reply by Graham Proctor on
-
I had the same issue with "No Dataflash Inserted" and the LOGS command hanging the cli. Turned out to be the connections to the daughter board. After reseating it all functionality returned.
-
Permalink Reply by Ervine Lin on
-
Thanks! I had a funny feeling that was a possible reason but I had no way to verify it.
I assume that you are referring to the 3 or was it 4 vertical single pins that connect the main board to the daughter board?
By "reseating" you mean just making sure the soldered connections are sound?
-
Permalink Reply by Ervine Lin on
-
I tried messing around with the soldered points, solder looks ok. Unfortunately still can't access dataflash. I will wait till 2.7.2 is out, seems like there might be a solution for this problem through the new firmware. If it still doesn't work then I'll have to think of something else...
-
Permalink Reply by Graham Proctor on
-
Push down on the board while melting the solder to be sure the connector is seated all the way down.
-
Permalink Reply by Ervine Lin on
-
Many thanks Graham! I upgraded to 2.7.2 but no difference in the dataflash problem.
I did just as you recommended (pushed down on the board while re-melting the solder, the board moved a little) and I got my dataflash to start reading again!!
Now to see if I can figure out what went wrong again...
Thanks once again to everyone for the help!
-
-
Permalink Reply by Ervine Lin on
-
I just realised I used to be able to download logs even with 2.7.1. I am not sure what changed since then but no matter what I do (remove and reinsert, electrical tape thickness thing, erase and reset) CLI says no data flash.
I really hope its a firmware issue and not a hardware one...
-
Permalink Reply by Ervine Lin on
-
I flew 4 batteries yesterday with a mixture of Auto and Manual modes, did 4 different missions repeatedly at different altitudes and couldn't replicate the problem I encountered previously.
Tried with sonar and without, with onboard video and without, new and old batteries, everything flew as it should. I did some very minor changes to the Alt Hold PIDs, I also took everything apart and plugged everything back together, other than that all else equal.
The only thing I can think of now is that it could be the weather. It was a very hot day when the crash occurred, maybe something was on the brink of overheating. Or maybe it just caught a downdraft. Or perhaps the new batteries needed some running in. Or maybe I had a bad connection somewhere.
I don't know, only more testing will find the cause I suppose, thanks for the help nonetheless.
-
Permalink Reply by Crashpilot1000 on -
Hi!
I don't know if this applies to APM 2 as well but the BMP085 baro on my mwii copter is sensitive to sunlight and will produce wrong readings. I don't know if this applies to the MS baro im apm 2 as well. Usually i cover the baro with foam to eliminate turbulences and sunlight but in my apm2 it is hidden under the gps so i have to go without foam or cover the whole thing.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduRover User Group
183 members
-
ArduPlane User Group
673 members
-
ArduCopter User Group
1280 members
-
Moderators
24 members
-
Andropilot Users Group
182 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
