HI, i am using arduplane v3.8.4 i am having problem on take off, it overshoots. waypoint altitude is 84 m, but it climbs 160m first , then descent .
this is my log file : https://plot.dron.ee/irZb
i appreciate to anyone’s help, Thanks!
Wow, that’s so excessive that it’s no longer called overshoot. It must have been commanded. Your image is a bit confusing though. Your GPS alt, which is absolute alt, shows you taking off at 105m or so above your relative baro height of zero. That’s all normal. But then that 105m offset somehow guess away during takeoff when the baro goes up and touches it. Very weird. Your offset is not consistent at all. Something funny is going on.
the thing is there was no waypoint over than 85m,another anomaly is barometer shows 85m and gps delta altitude ~40m,also the flight was at -5C,I dont know cold effects it or not
I also had this issue this weekend. I’ll examine the logs and post again later, but it was consistently overshooting. I think my Takeoff height was 60m and the next waypoint was 100m. It would climb to somehting like 120m before descent to 100.
Here my take off altitude 30 m.
@Artem_Skorsky
I took a look at your log:
You’ve set ARMING_CHECK=0 which allows the aircraft to arm when all kinds of craziness can still be happening in the EKF and GPS and MAG and elsewhere. You need to fix whatever is causing problems instead of disabling the checks. They’re there for a reason! Consider yourself flying at your own risk when all the checks are disabled.
Clearly, you were in a cold environment. Also of note, you have some crazy high winds upwards of 25m/s! Your airspeed sensor was saying external temp was -1.5C and all your IMUs and Baro temps were just starting to stabilize as you landed. When flying in cold weather, you reeeeeeally need to let that stuff warm up. Pixhawk/Cube 2.1 includes heaters so this process is relatively fast. I see you had param BRD_IMU_TARGTEMP=45 so I guess you had a heater but the temp was set too low. All the IMUs booted up around 49 and slowly warmed to 55. Since your heater was set to warm a very low level, it was off the whole time (it was considered too hot already). Please change that value to the recommended value of 60. It would have quickly heated to a stable value.
-
the EKF was struggling with yoru altitude, that is clear. Your NKF3.IPD (decoded meaning: Innovation Position Down… aka alt error) quickly climbed from zero to 80 during the takeoff then snapped back to zeroish.
-
GPS: The data from the GPS says it’s stable but it also says you peaked at 50m then went down to 30m for the rest of the flight. The baro and GPS were not agreeing whatsoever… no wonder the EKF was confused. What GPS hardware were you running?
Mission:
Takeoff planning looks good.
For landing I have a suggestion for you. Seems you, like many others, like to spoon feed waypoints down to the ground for landing. You’ll get better performance by simply making a high one, and a LAND one on the ground. When executing a LAND point many of the LAND related params are available to you for tweaking and tuning to give you the best possible landing.
PIDs:
Your aircraft is actually tuned quite good! Congrats!
Takeoff:
Seems the takeoff was complete at 30m as expected, then it climbed higher. So, the additional climbing was not during the takeoff - it was heading towards a waypoint
Here’s some insight as to whats going on. The HPS and Baro don’t agree… and at some point the EKF gives up on the GPS and switches to the baro so there’s an altitude disconnect here:
Also of note, your aircraft does a massive sustained roll on takeoff? All kinds of craziness is going on with this log…
2 Likes
TECS.h is the current height and will typically be noisy as the aircraft is bouncing around and such. This is from the output of the EKF which combines all sensor inputs. So, if the EKF is confused, all systems that depend on it will be confused.
TECS.hdem is the height demand, meaning it’s trying to achieve that. The optimum behavior is .h matches .hdem. So, .hdem is the internally generated ideal path so what the log should show is .h is chasing .hdem. If they diverge, then you know the aircraft has lost i’t mind and it’s not going where it’s trying to go.
Same goes for CTUN.Roll vs CTUN.NavRoll (and pitch) where NAV is the navigation controller demanding a given roll/pitch.
1 Like
GPS i use M8N,
when i throw airplane by hand , i did very bad throw,and it rolled during launch, but luckly autopilot managed to correct. thank you very much, i appreciate for your help.
@MagicRuB, please look at the following log. It has 3 automatic takeoffs that all overshoot by at least 15m… and that’s 35m over the takeoff parameter. TECS looks good otherwise during cruise… maybe I need to adjust the TECS parameters a little better? I was switching props and didn’t update the climb rates and speeds often. https://www.dropbox.com/sh/p4tll7odumaddc2/AACYom1cGMVyiuQSAUhc4mFVa?dl=0
