Hi guys, I’m a new member here and new to flying drones. I’ve just built a hexacopter and twice now while flying it it has suddenly become very difficult to control and felt like I was fighting with it as if it was trying to do one thing and I was trying to do something else. I enjoy learning and figuring these things out for myself but I’m having some difficulty with this one.
In looking at the logs there is one thing that is jumping out, a sudden discrepancy in altitude between the barometer, GPS, and something called POS.Alt that corresponds with the moment I began struggling to control it.
I don’t know what that is and cannot find a complete list of abbreviations used in the logs. The wiki is organized alphabetically and stops at PM.
For anyone to be able to determine the cause or solution to problems you need to supply as much information as possible.
And part of that is posting a flight log for people to look at and analyse.
Flight logs are essential if you want help.
The jump in altitude is related to the “EKF IMU Origin set to GPS” message. It sounds like you acquired a GPS lock while in the air causing the EKF to set a new origin. If you’re flying in Stabilize, this shouldn’t affect how it’s flying, so there might be something else.
Can you upload your .bin log so we can take a look at it? If it’s large, you might need to host it on Google Drive or Dropbox or similar.
Thanks for the responses guys. I can upload the log later when I get home but I really wasn’t expecting someone to wade through them and figure it out for me. What I was mainly looking for was what the heck is POS.Alt ?? It started off tracking exactly with the barometer but then suddenly jumped. Except for that jump all three plot the same and do correspond with my visual recollection of the altitude during the flight.
I have searched but cannot find an explanation of the abbreviations used in the logs, which seems rather odd to me.
Rick is correct. Paul Riseborough has some EKF updates that will prevent this. Those updates are in 3.6-dev, but not currently in Copter 3.5. I’ve been flying Paul’s updates in a custom build of 3.5 for helicopters since last summer and this problem has not ever happened with the custom build. But it did happen all the time prior.
The updates Paul wrote were PR’d to 3.6-dev, but never PR’d to 3.5 because it took some back-porting work to build them on 3.5.
The POS.Alt is the EKF position estimate on altitude.
Yes, it will affect it. I think it was last August or so I was flying section surveys with a helicopter at 27 m/s cruise speed. About a half hour or 40 minutes into the flight I noticed in the FPV feed the heli getting dangerously close to treetops on the turns on the ends of the passes. The heli was about 1,600 meters out at the time and I aborted the flight and took over manually. I flew it home in Stabilize on FPV and when I landed it said it was at 17 meters altitude with the heli sitting on the ground at very spot it took off from.
The EKF altitude estimate, based on GPS, had steadily decayed from the actual baro altitude. GPS is notoriously inaccurate on altitude estimates. Paul’s updates include a new parameter EK2_HGT_ORGN_MASK I think it is, set to zero will force use of the baro for the EKF height origin. Of course baros can drift too, but it gives the user the choice of which he/she wants to use for the EKF Height Origin. I have not had a problem since I built his changes on 3.5 using the baro’s for the height origin.
Ah, yes, I am familiar with the upcoming GPS-not-trimming-EKF-origin changes; I’ve had similar experiences with that issue.
But is this the same problem? From the code, the “EKF IMU Origin set to GPS” message that the OP got in his log is posted when the EKF first initializes (whenever setOrigin() is called), which I suppose means that the GPS checks passed while in flight, causing the EKF to set its initial origin (in the code, it attempts to place the origin on the ground by subtracting HAGL). OP only flew in Stabilize and said the copter started flying weird, but I don’t know why setting or changing the EKF origin might make flight in Stabilize act funny, as even if the EKF Altitude or HAGL estimate changes because of this, Stabilize doesn’t care about altitude or position.
No, it does not affect how it flies as far as the attitude controller. It only affects the EKF altitude estimate, which I recognize that problem from the graphs. I didn’t see an actual log posted here to see if there was a discrepancy between desired vs actual attitude and so on. So no conclusions on that can be drawn until a log is posted.
Ok I think I figured out it was my battery not being able to keep up with the current demand. I was using a 5000mAh 20C battery but it was a couple years old and in viewing the voltage and current in the logs you can see it losing oompf.
I still don’t quite understand the sudden jump in POS.Alt. I flew it again today very cautiously with a new 10000mAh 25C battery and it flew perfectly. That log exhibits the same sudden jump in POS.Alt.
If I’m understanding correctly, EKF is basically the Ai of the FC that analyzes the output from various sensors and uses some algorithm to come up with the most accurate determination of everything. If that is the case I don’t get how POS.Alt would jump like that while neither the barometer or GPS show a sudden change in output. Is there another sensor that EKF uses as well that I should look at?
Okay, now I can explain what happened. But first, to answer your question, yes, the EKF is the algorithm which fuses all of the sensor readings and produces the final estimate of the drone’s attitude and position. See here:
The drone navigates using the EKF’s position and attitude estimate. These data are recorded most accessibly in the CTUN (altitude and throttle-related), NTUN (position and navigation) and ATT (attitude) fields in the logs. The EKF altitude is CTUN.Alt and can be interpreted as “altitude above EKF origin.” Meanwhile, POS.Alt can be understood as “absolute altitude.” In other words, CTUN.Alt is relative to EKF origin, POS.Alt is relative to mean sea level.
The EKF waits until you have a good GPS lock to create its position origin. This origin is just a datum where EKF position and altitude start at 0, and doesn’t actually have any practical effect on the operation of the drone. In this graph, you can see that CTUN.Alt agrees with your barometer reading and stays steady when the GPS lock occurs, but POS.Alt changes. Specifically, POS.Alt increases by 42 meters, which is the GPS altitude at the time the GPS lock is achieved, so the drone used the GPS altitude to create an estimate of absolute altitude. This is visible in the ORGN message - it’s actually just a tiny dot since the message only occurs twice, but you can see from the graph’s legend that ORGN.Alt is 42.
Meanwhile, EKF altitude did not change because as I mentioned earlier, when the EKF origin is created, it is placed on the ground by subtracting drone’s current altitude. The problem that ChrisOlson mentioned is a tendency for the EKF origin to slowly drift in flight, causing the EKF altitude to be incorrect after a long flight.
It is important to note that none of this actually has an effect on flying the drone in Stabilize, as this flight mode is entirely controlled by the pilot. As you said, there seems to be a power-related issue that may have caused your troubles.
Here is the state of your throttle. CTUN.ThO is “throttle out,” a number from 0 to 1 that basically can be read as “percent of available thrust.” Also displayed are your motor PWMs and throttle PWM from your transmitter (your setup is atypical, you are not using motor channels 2 and 3, and your RC throttle is inverted, is this intended?).
You command full throttle, and ThO saturates at 1. Not shown is your altitude and voltage: altitude climbs a bit before slowly sloping downwards until the drone hits the ground. Meanwhile, your voltage sags from 18 volts to 12 volts! I guess with a 23V starting voltage, this is a 6S battery. If that’s true, then yes, the battery was taxed far beyond its ability to deliver the required power.
Rick, I can’t thank you enough for taking the time to explain all this.
With a better understanding of how this all works everything that happened during the flight makes perfect sense now. I was having a hard time controlling it because every time I would try to maneuver it the voltage would sag, to compensate I was giving a little more throttle. That would temporarily stabilize it but as the battery recovered, the V would rise back up and the copter would slowly ascend. This didn’t seem alarming at the time so I went back to seeing how it felt right-left and forward-back. I got in trouble when it drifted above the trees surrounding the park and the wind started slowly pushing it to the right. Slight adjustments didn’t seem to be doing anything so I kept giving it more throttle and left roll. That’s the final drastic V drop in the logs when it crashed into a tree.
With two broken landing skids and a bruised ego I collected the parts and came home. It felt at the time like it was losing power and crashed so the first thing I did was measure the battery. The V by then looked fine so I charged it and the charger only put roughly 1000mAh into it out of 5000. This is why I incorrectly thought the copter was intentionally trying to do something.
As for the odd motor setup. An early mishap while building it sent the copter off the bench and yanked the #3 connection out of the Pixhawk. It yanked the signal pin hard enough to lift the trace off the board and #2 looked suspect. Instead of trying to fix and worry about it I just disabled them and moved the motors to the unused two.
I didn’t remember that I had CH3 reversed. I remember trying to search what the difference is between reversing it in the transmitter or Pixhawk and couldn’t find anything. I’ll have to look at it again to recall why I was reversing it.
