I was testing AC3.4-rc6.
It seems that EKF 2 lead my copter to land itself.
The only thing I know is that the copter start to drift a bit in PosHold, and then Mission Planner tell me something about EKF 2 Failsafe and the copter land itself.
I can reproduce the issue for (at least) 4 time in a row.
Attached some logs.
https://drive.google.com/file/d/0ByiQ-PFiGc1MX3pNS2N1QmlERVk/view?usp=sharing
https://drive.google.com/file/d/0ByiQ-PFiGc1MN0Y1WTV2c09sZkE/view?usp=sharing
When I had similar issues in Auto missions it was from high vibration. I addressed that and the problem went away.
In your opinion my problem is due to high vibration?
I ask this because I have already read the log, but to me the vibrations don’t seems so high.
It is possible that I am misreading? or maybe that the vibration need to be more low than this?
Sorry, I was making an assumption because the symptoms sounded familiar. Upon closer inspection your vibes look OK at the time of the Land event. But there were GPS glitch events coinciding with each Land event in both logs.
Thank you very much for the analysis.
Now I have to understand why it have GPS glitches.
In your opinion why?
Question:
-Why only EKF2 failsafe? Mission planner was saying EKF 2 failsafe.
To verify:
-I have to verify if I was flying on a day with high solar interference (high Kp index).
So, I have to fly the copter some other days to understand better.
I’ve had a quick look at the logs and it’s not actually a “glitch” but rather a loss of contact between the flight controller (i.e Pixhawk) and the GPS. The reason I say that is because it instantly and completely loses updates from the GPS. If it was a glitch then we would continue to get updates from the GPS but the position and velocity information would be bad.
This means, that when looking for the cause, we need to either look at some kind of physical problem (like the serial cable connecting the flight controller and GPS is bad).
If you’re using a Ublox, I think it might be a good idea to set the GPS_TYPE to “2”. This ensures tells the code that you’re always using a UBlox so if it does lose contact it should recover more quickly… I think.
I’ve changed the title of this thread to more clearly say what’s going on.
Randy,
thank you very much for looking at my logs, and thank you for your reply.
Sorry for the trouble. I was wondering that I had found a AC3.4 bug. Fortunately there is no bug: again, sorry for the trouble.
Tomorrow I will fly again.
I will set GPS_TYPE to 2, since I am using UBlox M8N.
And before the flight I try to look if physically it is all right.
Maybe I can try to fly with a different GPS cable or a different GPS (maybe the cable or the GPS are broken).
I will do some test and I will take a closer look on the physical side.
Thank you again!
same here, also EKF2 M8N gps, any ideas?
thanks!
@mpircher You are using ArduCopter 3.3, so thats a fairly significant firmware difference. Still looking at the logs otherwise.
@Andrea25 I’m still looking through the log for some more explanation on this one.
Hello Everyone,
I have done some other tests.
I have replaced GPS cable and I have checked all cable connection on the drone. To be sure that everything is all right.
I don’t remember if I was flying with AC3.4 stable or AC3.4-rc6.
1)I was having some problems related to IMU1 (Mission planner display something about IMU1).
It seems that it was triggered the EKF failsafe after some problems on IMU1.
Of course after failsafe event my copter was forced to land.
That’s strange. Since I didn’t have any problem on the IMU1 with AC 3.3.3.
2)I had a look on this new logs, and it seems that I do not only have problems on IMU1 like the mission planner says, but I have also some problems on the GPS. The same ones that Randy have alredy seen.
I know that it can be some physical problem.
I know that very well, but I have check all the connection and I have replaced the GPS cable.
So, at my eyes it seems strange that it is a phsyical problem.
By the way. I have already ordered a new pixfalcon and a new M8N. When the new pixfalcon and the new M8N arrive at my office I will retry the test with the new hardware.
Can you confirm to me that it is a physical problem?
3)Can someone look at my logs? Just to be sure.
https://drive.google.com/file/d/0ByiQ-PFiGc1MUDhnUk5vVExPak0/view?usp=sharing
https://drive.google.com/file/d/0ByiQ-PFiGc1MSllucVFiSW5Ha00/view?usp=sharing
Andrea,
I’ve had a look at the first log and it shows the same problem which looks like a loss of communication with the GPS. I’m not sure if it’s a physical problem or a software detection issue. I suspect it’s software related actually.
Michael DeBreuil is working on improving the speed of detection but until then you might try setting GPS_SAVE_CFG to “1”, then turn on the board/GPS and give it a few minutes. If the GPS is all running correctly then you should be able to set the GPS_SAVE_CFG parameter back to zero. The idea here is that it should save the desired GPS configuration permanently so that the GPS comes up properly configured.
Randy,
yes, also in my opinion is a software issue.
Of course I can not understand exactly what it is or why it show this problem.
I have already set GPS_TYPE for Ublox, since I’am flying with M8N.
Of course I have done the GPS_TYPE change before the two log that I had posted here yesterday.
By the way, I have to give back this hexacopter. So I have to work in this way:
-Go back to 3.3.3
-Deattach the buzzer in a physical way (On 3.4 I was using the option to silence the buzzer, like you suggested)
-Use alt hold and pos hold as a flight mode (and not loiter)
I am thinking that this can be the best course of action to bring back this hexacopter in a safe and fast way.
If you have to suggest anything else tell me. I am open to new opinion.
Sorry fot not testing GPS_SAVE_CFG on 3.4. 
I have really short time for bring back this hexacopter. So I need to minimize the configuration changes.
I have some news.
I have changed the PixFalcon. Now I have the new hardware. And I have seen that I have time to do some tests.
Tomorrow I will fly AC3.4.2 rc2 and I also will try GPS_SAVE_CFG.
I will let you know if with the new hardware I have no problem.
In this way is quick to figure if it was hardware fault or software fault.
I will report here tomorrow (=
I have finished to test-fly about one hour ago. I have already reported my opinion about the flight in another thread.
I flew with AC3.4.2-rc2.
I flew with a brand new Pixfalcon.
Before flight I had used the Randy suggestion about GPS_SAVE_CFG.
Everything is all right.
With the new Pixfalcon I have zero problem. Not a single time I had seen any problem.
So I suspect that the GPS thing and the IMU1 thing was hardware problem.
So I declare this case closed: hardware problem and not software problem.
Thank you very much to everyone that helped me (=
