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:
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
@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.
I updated my Copter firmware just the day before the (2nd) crash, so I had re-calibrated everything before the test.
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.
-
1
-
2
-
3
-
4
-
5
of 5 Next