Pixhawk fall from the sky in altitude hold mode

Another crash caused by a switch to a different flight mode....

After several good flights with my pixhawk equipped quad, i had a crash soon after take off immediately after switching to alt hold flight mode. The quad immediately rolled over and fell from the sky...

I don't understand the cause, especially because i had several good flights with the same configuration, i didn't change anything since then...

If somebody can give me a hint based on the log file i attach to this thread i will be very grateful.

I also attached the video taken from the go pro on the gimbal.

Thank you in advance...

17.BIN

alt hold crash.mp4

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I also built a Y6 and have similar issues.  Mine seemed to begin with a firmware upgrade last winter.  I have a list of possible causes. Most are power related.  I am getting tired of repairing and I ruined a $500 gopro. 

    Voltage brownout due to under capacity batteries.  I am using 4s 5000 mAh, 50c.  I upgraded with my latest battery to a 60c.

    Power module failure

    Bad power distribution board (I discovered a bade trace.)  The circuitry is not capable of high current, will overheat and burn through.

  • Kiwi, your investigation is excellent! Pity that it's not easy to come to a final conclusion. Anyway now that frame is broken, i've already put most of the electronics on another frame, an Y6, motors and escs are new but exactely of the same kind as on the quad that crashed, hope it's not an issue related to that combination, that gives very nice performance but i know that to some it has caused sync issues (never experienced by me).
    Thank you again for your help!
    • It s a pleasure. By investigating issues, it help me to understand and learn the ardupilot system.

      I wish you good flight with the new frame. 

  • Yes, the gopro is on a gimbal, i also noticed the noise reduction indicating lack of thrust... I will check the power distribution, but it is made with heavy gauge wires and good bullet connectors, i don't think that is the problem, plus it should have been on the 2 left side motors at the same time and this is unlikely. If you stop the video at the point where the fall has begun and the camera shows one arm with the motor, you'll see that the prop is spinning, and i think that is a left side arm. If there was a power disconnection i don't think the prop would be spinning and the airflow wouldn't be sufficient to make the prop spin at speed on its own.
    Anyway the fact that things went bad exactely when i switched to alt hold flight mode is the biggest hint to understand that this was triggering the crash. Just don't still get why.
    Your help in the analysis is very helpful anyway. Thank you again.
    • I agree it's perfectly in sync with the AltHold activation. This tend to tell us that's not a physical failure (e.g. a motor loss).

      We also can see that the Yaw doesn’t move (from the camera and log). The pitch is not really impacted at the beginning, it even come back to few degrees for 1,2s right after the roll start to get crazy and come back to stable pitch from important pitch during Sport mode. 

       The roll got crazy straight away: 45deg in 0,3s, 90deg in 0,5s and 270deg in 0,8s (based on the film and on the log) about 360deg/1s. ChOut2&3 full speed and just after ChOut1&4 to minimum. This should engage a roll with Left going up and right going down (I checked with my quad that with an angle the motor react to go back horizontal). But from the camera, this the left which goes down while the right goes up !!! Are all channels mix up ? It couldn’t not have flew for 20 s with mixed channels. The roll is negative so confirm the turn with left gown down and right going up (just check on my quad), so in line with camera. 2 scenarios: 

      a) Motors engages the copter in a positive roll based on the ChOut, but this is not we see from roll and camera

      b) Copter start to roll on the left (why and why only on the left), then the copter try to recover and engage a roll on the right with the motors but do not manage to stabilize.

      b.1) For what ever reason the ChOut1234 signal are not on the PIN (SW bug, Connector issue,…)

      b.2) Battery issue: Personal log: 16,5V & 4A  before take off and 15,50V & 16A  after with a 4S battery. Here 16,3V & 4A before take off and 15,3V & 18A after. So looks fine and not flying with an empty battery.

      b.3) Power cut: Difficult to believe that if there was a full power cut the copter would behave like that: recover pitch and engage a nearly complete roll. If there was a partial hardware issue like motor failure then why only roll is impacted ?

      b.4) Transition issue in the SW between Sport and AltHold. Delay (no visible in the log), issue with PWN on Out PIN, ESC command change not accepted by ESC,… what else could it be ?

      I thin I reached my limit. Not sure now ho two investigate further more.

      Is there anyone who can simulate with STIL the stabilize, sport, alt hold to see if we can reproduce ? My simulation environnement is installed but I don’t know yet how to use it.

      Funny enough, there is a very similar case at: http://ardupilot.com/forum/viewtopic.php?f=21&t=7057 which trigger after the same during of flight ! Any relation between the 2 ? SW 3.15 for one and SW 3.1.2 for the other. No final conclusion on this thread but issue with one frame and probably not with the other, so HW issue but not confirmed.

      3702530536?profile=original

  • No, in the area of the crash there isn't any radio tower...
  • Hi Kiwi, thank you for spending time analyzing my crash... Yes, RC2 is elevator (pitch).
    The reason the flight mode passes through sport mode before alt hold is that i configured two 3 pos switches of my taranis for the mode change, and to give time to activate both switches to select a mode there's a time lag of 0,5 seconds before ch5 sends the approprate pwm level for the selected mode, the problem is that in that 0,5 seconds the pwm level of ch5 goes to midposition that is the level at wich sport mode is set. This has never caused any problem, but i could even reduce that lag to zero, but this will cause the taranis to voice confirm every flight mode is passed though with the 2 3 pos switches combination before reaching the last selected mode, that is anooying and confusing, with that lag of 0,5 secs the taranis will read only the last position selected.
    • What we can see is that just after the AltHold, RC2out and RC3out went to the max while RC1out and RC4out when to the mean. Could you check that RC2out and RC3out are on the right of the copter and RC1out and RC4out are on the left of the copter. Then only after the Gyro start to detect the turn. At the same time there is no changes on the RC1234in !3702530615?profile=original

      • By checking the motor numbers (2 and 3 are on the left and 1 and 4 on the right based on documentation), which is the opposite of the channels mentioned in the post above. Question, did the roll started before the motors difference of did the motor engage and created the roll. If the roll engaged first, one explanation could be that after the AltHold a hardware issue happened and the motors (1 or 2 of the left side) on the left stopped. To compensate the roll the Pixhawk increased the motor PWM but without response from the motors, so asked more and more up to the max (saturation). But no information about the motors in the logs as we don't have motors sensors to feedback.

        All the rest looks ok for me (not long experience, so perhaps I'm missing a point). In and Out are there and logical. I can't see any bad behavior from the ardupilot.

        Could you confirm RCout1-4 and motors positions on the frame ?

        Thanks

        • The pixhawk configuration is for standard quad, so motors 1 and 4 are on the right side of the frame.

          As you can see from the movie of the crash, the roll is to the left, so you're right saying that it's like the motors on the left failed, what's strange is that this happened with the switch to alt hold, and i don't see any reason for which this flight mode could cause a failure of both motors on one side. Consider also that this quad had several good flights with the same configuration. Moreover i did some ground tests to make sure that the motors/escs combination didn't cause any sync issue, as reported by others with the same setup.

This reply was deleted.

Activity

gotham liked gotham's profile
15 hours ago
DIY Robocars via Twitter
RT @RoboticMasters: Monaco GP Circuit in the Donkey Sim (coming soon). Including buildings, tunnel and all! https://github.com/robotics-masters/sim-donkeycar-f1/tree/f1-tracks @diyr…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: Here are the details of #AWSDeepRacer finals: https://blog.deepracing.io/2020/12/01/aws-deepracer-league-finals-2020-round-1-schedule/ #awsreinvent2020 #AWSreInvent https://t.co/ovqsjp8V…
Wednesday
DIY Robocars via Twitter
RT @breadcentric: #AWSDeepRacer League #awsreinvent2020 Open race is on Dec 1st - Dec 31st in three categories, 15 DeepRacer Evo (with LIDA…
Wednesday
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars It's just something that's easy to track with chroma keying. I ended up using different colors on th…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Nov 23
DIY Robocars via Twitter
Nov 23
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
More…