Hey. I have a quadrotor with Pixhawk, APM:Copter V3.3.3 (acf2e10c). I have tested it in Stabilize & AltHold modes, works fine. Also tried switching to Land mode from Stabilize & AltHold, and the drone lands perfectly.

I wanted to try AUTO mode, as a first test I defined this mission based on the tutorials here:

1. Takeoff to 10 meters

2. Loiter there for 5 seconds

3. Land

I went out for a test, as soon as I raised the throttle in AUTO mode, the copter started climbing VERY quickly, and it kept climbing up until it was about 60 meters above the ground. I waited for like 10 seconds and it kept climbing, so I panicked & switched to AltHold mode. I'm a newbie pilot so I could not control it properly at that altitude and...crash!

I thought maybe it was a bug in my planned mission or a gps glitch or something, so I fixed the copter and tried agian. This time with this mission:

1. Takeoff to 3 meters

2. Land

Again, same thing happened. This time, I switched to Land mode, but it kept climbing like crazy. Switched to stabilize and eventually...another crash.

I reviewed the logs, DAlt (desired altitude) does not match my planned mission altitude (figure below). I have attached the log, can someone please help me with this?

DAlt Plot:

3691281226?profile=original

2016-03-10 08-28-02.bin

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

Join diydrones

Replies

      • @Alireza,

        it's clear you should autotune and calibrate  IMU first, especially 

        IMU1.  IMU2.AccZ mean value is around -9

        and Kalman filter failed to reject apparently incorrect IMU1. IMU.AccZ

        negative data value input, pushing Throttle on and on

        to prevent your drone to "fall down",  since AccZ value read is negative (around -9)

        Since your airframe vibrates in Z axis at resonant frequency, which I can calculate

        if necessary, try to damp your Pixhawk controller board to damp IMU generated data

        and autotune, calibrate IMU1. IMU2.AccZ to set -9 offset to 0.

        "

        Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 2.10, WARN: 0.75, FAIL: 1.50)

        Autotune = NA - 

        "

        Could you attach GPS charts ?

        Pixhawk is highly intelligent machine, running really fast processor.Due to hypersensitivity to IMU Acc data sine wave modulated, control over your drone can easily get lost in case airframe starts to vibrate at resonant frequency.

        Manual control is smart, flexible and fuzzy logic based, since IMU Acc data are not real-time processed by an operator.

        Wish you happy flying.

        • I have attached the GPS charts.

          About the IMU.AccZ, I think the correct value is around -9.8, which is the acceleration of gravity, and negative because it's downward. So the mean value being -9 does not look so bad, does it? An accelerometer showing 0 acceleration in Z direction means free-falling.

          But I had calibrated the acceletometer several times before, it was calibrated & working well. I don't think re-calibration is going to fix anything here.

          I am definitely gonna damp the vibrations first before trying to autotune or change the controller gains. Thanks so much for your suggestions Darius!

          GPS.PNG

          https://storage.ning.com/topology/rest/1.0/file/get/3702809693?profile=original
          • @Alireza,

            there are misconceptions about IMU accelerometer.

            For a static object, your drone put on your desk,  acceleration due to gravity is exactly 1g.

            But this a gravitational force  g = -9.8

            At the same time, we calculate accelaration of an object as the rate of change of velocity of an object.

            So if your drone stays still on your desk, so what is its acceleration

            in X, Y, Z axis ?

            You can apply equation for acceleration:

            a = deltaV/deltaT

            a = (final velocity - initial velocity) / (ending time - starting time)
            a = ( V1 - V0) / (T1 - T0)

             so what is the acceleration of your drone put on your desk and kept still ?

            since its speed in X, Y, Z axis is always 0 m/s

            so a = (0 - 0 ) / delta T = 0 m/s2

            If your drone is climbing in Z axis at fixed speed, so what is its acceleration

            in Z axis ?

            a = (V1 - V0) / (t1 - t0) 

            since V1 = V0 ( speed is constant)

            a = (V1 - V1)/ delta t = 0/delta T = 0

            Since your fixed wing , copter flies in mid air and g force is exerted on it

            so its potential energy is calculated as 

            Ep = mgh    (potential energy Ep = m x g = weight   x height)

            To keep your FW afloat in AltHold mode motors + propellers need to

            supply energy to counteract Earth's gravity force acting permanently on your drone.

            But if you put your drone on your desk, you can safely set motors off,

            since your drone is protected against free fall at g force, since it is supported

            by your desk against free fall.

            So I prefer to calculate acceleration from the equation 

            a = (V1 - V0)/ (t1 - t0)

            since in AltHold mode I get a  value calculated as 0 m/s2

            as opposite to 1g by IMU.AccZ

            Pls attach GPS.Alt against  Baro.Alt

            since GPS.lat, GPS.long don't matter

            Acceleration, in physics, is the rate of change of velocity of an object. 

            So I offset  IMU.AccZ data against g to get  real +- a data, calculated as above.

            If initial speed is known, starting time is known, g offset a is known

            I can calculate drone's climbing speed and potential energy can be measured to match mechanical energy of motor + propeller spent ( energy consumption

            current x voltage).

            I you know power drawn from battery in AltHold  at 0 Z-axis acceleration

            (a + g) and set as constant,

            you can be assured your drone stays at the same Alt if there is no

            change in energy consumption, power drawn from battery.

            If energy consumption sinks, you can be assured in advance of

            the change in altitude to a lower one and the opposite.

            • Um, the accelerometers DO measure gravity.  Z should be about -9.8 when at rest.  They couldn't separate acceleration due to gravity from acceleration due to motion, even if they wanted to.

  • Thanks for taking the time to respond, Andre. I have done plenty of searching about this indeed, and I have seen on many pages or forum discussions that vibrations could cause climbing up in AltHold mode. Sorry, I didn't mean to repeat a question with an obvious answer. What I want to verify exactly is that if vibrations can cause the DAlt (desired altitude) parameter to go up or not.

    I think the vibrations should be causing the copter to climb through the distorted Z acceleration numbers, which can make the flight controller detect falling and try to counteract it by increasing throttle. But I can't figure out how a constantly increasing "desired altitude" could be caused by distorted acceleration data.

    I just wanted to make sure that high vibration is the only cause here, before I go out and crash for the 3rd time just to find out there were also other problems causing this rapid climbing thing.

    Again, sorry if my question is stupid, or already answered. I could not find anything about this specific question.

    • What you're describing does sound like Z-accel problems.  It can as you say detect falling and try and counteract it, and because it tends to do this at full throttle will then exacerbate the problem - so DAlt can look to be chasing itself.  Have you re-calibrated your accelerometers?  And try different anti-vibration/dampening for the pixhawk, this is a common problem and either over or under dampening can cause what you're describing.  I've had precisely the behaviour you've described when I moved my pixhawk to a different foam mounting that invoked high z-accel.  It's a simple thing to diagnose, just change the pixhawk mounting, even try without mounting - it looks like your props are reasonably balanced from xy-accel.

      • Have you re-calibrated your accelerometers?

        I updated my Copter firmware just the day before the (2nd) crash, so I had re-calibrated everything before the test.

        And try different anti-vibration/dampening for the pixhawk, this is a common problem and either over or under dampening can cause what you're describing.

        I am going to try this, but I'm a little afraid because if the vibration damping does not fix this (or if the new mounting is not effective enough), the crazy climbing is going to happen again and I might crash again. But all I can do is to hope that this time it won't happen again!

        Thanks Fnoop!

  • I looked at the log and it shows that you have high vibrations at full throttle.  Also the desired altitude is lower than the altitude but it keeps climbing.  There is a similar post with the opposite problem where the copter will not climb but will fall to the waypoint.

    I would like to see the logs from a flight in Alt-Hold to see what it looks like.

    • Thanks for your response Michael. Unfortunately, after the second crash my copter has been damaged and I need to do some repairs before I can fly it again. I will post a log as soon as I can get it back in the air.

      As a comment: a strange behavior that I observed in AltHold mode was that when I raised the throttle above the middle zone to increase the altitude, the motors immediately started spinning faster & it went up, but when I decreased the throttle it took a few seconds to decrease the motor speeds & stop climbing up.

      Do you think the vibrations could be causing the increase in the desired altitude?

  • BTW This is the result from Log Analyzer:

    Autotune = NA -
    Test: Balance/Twist = NA -
    Test: Brownout = FAIL - Truncated Log? Ends while armed at altitude 5.69m
    Test: Compass = GOOD - mag_field interference within limits (7.13%)

    Test: Dupe Log Data = GOOD -
    Test: Empty = GOOD -
    Test: Event/Failsafe = GOOD -
    Test: GPS = GOOD -
    Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 2.10, WARN: 0.75, FAIL: 1.50)
    Test: Parameters = GOOD -
    Test: PM = NA -
    Test: Pitch/Roll = NA -
    Test: Thrust = NA -
    Test: VCC = GOOD -

    I searched about the problem a little more, some people have suggested that vibrations distorting the Accel data could be causing this issue. But I am not sure if this is the case here, because Pixhawk is increasing the "desired altitude", that does not look like a problem with IMU data being noisy.

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
yesterday
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Wednesday
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Wednesday
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Wednesday
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23
More…