Hi,
when I upload a mission, the drone navigates well according to the waypoints, but when switching to pos-hold, the drone just drifts away. It shows in the mission planner that the drone is in pos-hold, and the change in throttle is noticable, however, the XY position feels just like in stabilize. Anyone encountered this issue?
Thanks!
My first guess would be that one of your yaw/pitch/roll sticks is outside of the deadzone while in neutral position. Check your trim tabs and use Mission Planner to see what PWM’s the flight controller is receiving to make sure it is near RCx_TRIM parameter.
Otherwise, upload a flight log here and we can take a look at what the drone is doing.
You will need to post a log file for anyone to determine what might be happening
Hi,
Thanks for the reply!
I am new to this so I just found out about the data logs.
I can see in the logs that when I switch to pos-hold I get the following error:
Error flight mode-16.
What does that mean?
I should also mention that this is not a consistent behaviour - today I flew the drone and it entered pos-hold and worked just fine…
Ah, that would explain why your PosHold didn’t work.
The EKF is the algorithm that the flight controller uses to fuse sensor readings to estimate the drone’s state, including attitude and position. The EKF_CHECK-2 error means that the EKF cannot create a sufficiently reliable estimate, and so it refuses to switch to PosHold mode, which is the FLIGHT_MODE-16 error. If you have a buzzer equipped, you should have heard a unique beep that means that the flight mode switch has failed. You can see at the bottom of the graph that the drone never left Stabilize mode.
Later, the EKF error is cleared (EKF_CHECK-0). If you tried switching to PosHold after that point, it would have worked.
We won’t be able to tell you why the EKF was unhappy until you upload your flight log. Try uploading the .bin file here, or if it is too large, use Google Drive or something to share it so we can take a look.
Thanks for the great explanation!
Could the magnometers be the cause? The Z axis seems to be different.
Is it possible to verify or is it just guess-work?
It’s possible to identify exactly what caused the error, but we will need you to upload the .bin log. The EKF consistency checks and innovations should have what we’re looking for.
The EKF consistency checks are all good, although the velocity innovations are 0 until the EKF_CHECK-0 message. I take this to mean the EKF simply had not finished initializing by the time you took off. It took a while for the EKF to learn the gyro Z bias, which may have contributed to the long initialization time. Generally it does not take so long, was this the first time you flew after setup or calibration?
Anyways, I don’t expect this to be a problem in the future. One thing you might want to check on is your vibrations - they are good for the first half of the flight, but sometimes go quite high.
In case it happens again, this situation can be avoided by trying to arm the copter in a GPS mode such as PosHold. If the EKF isn’t settled yet, it will just refuse to arm. That way, you can know for sure if you’re ready for GPS flight.
Again, thanks for the great and detailed answer!
This was not the first flight after calibration, but it my be the first attempt for pos-hold.
Could you please elaborate regarding the specific things you checked in the log file?
1 - how can you tell that the consistency checks are good?
2 - where do you see velocity innovations?
3 - how can you tell it took a while for the EKF to learn the gyro Z bias?
4 - if it is only a problem of not waiting enough before takeoff, what triggered the EKF error mid flight?
Thanks!!!
There’s some good documentation on the EKF log fields here and here.
I’m going to answer your questions out of order.
4 - The error happened in flight because Stabilize flight mode does not require the EKF, since everything is controlled by the pilot except for stabilization. Any flight mode which relies on the flight controller to control position such as Loiter or PosHold requires the EKF to be initialized. This is why I suggested trying to arm the copter in PosHold, as it will refuse to arm if it’s not ready. As for the annoyingly cryptic error messages, they are defined here. The error message FLIGHT_MODE-16 can be read as “Flight mode change failed due to error code 16,” which is defined as EKFCHECK. You can find EKFCHECK error 2 as “bad variance” and error code 0 as “variance cleared.”
2 - Innovations are contained in the NKF3 field. An innovation is how far off a sensor reading is from what the EKF expects it to be based on its current state estimate. They are recorded in the relevant units for that measurements (e.g., m/s for velocity). The EKF uses a coordinate system of North, East, Down for position and velocity. Here, you can see that the velocity innovations don’t exist for the first half of the flight, which I guess means that the EKF had not settled on a velocity solution yet.
I also show the position innovations. You can see that they are large at the beginning of the flight, but suddenly jump to near 0 once the EKF initializes. The large innovations are caused by the EKF’s inertial measurements not agreeing with the GPS position, I guess because the EKF hadn’t started its inertial estimation yet. The innovations stay near 0 afterwards, which indicates that your EKF may be fine once it’s working.
1 - The consistency checks are contained in the NKF4 field. They are ratios of innovation/threshold, where the threshold is some value that can be configured with parameters (defaults are usually fine). If the ratio ever exceeds 1, the EKF rejects the measurement. If the ratio stays above 1 for a while, the EKF will instead throw out its estimate and re-initialize, and switch to the secondary EKF, if you have it running (you do). This EKF switching means something is wrong, but fortunately this was not the case for you.
Here are the consistency checks. Again, velocity does not appear until after the EKF initializes. They stay in a healthy range of generally <0.10, the spike at the end is probably the copter touching down.
3 - The gyro biases are in NKF1.Gx. The only reason I mentioned this is because it was the only thing I could find that may explain why the EKF took longer than usual to start.
So I think your copter is okay, you just had one instance where EKF took longer than usual and caused something you didn’t expect. My disclaimer is that I am not an expert, so I definitely could have missed or misunderstood something.
Anubis your awesome!
Thanks!
