Looks like the “PreArm: EKF attitude is bad” issue, that I described here and here is still open. This means, a copter configured for GPS-for-Yaw still can not be armed (e.g. for motor test) inside a building without GPS as compass is only a fallback after GPS-for-yaw has initialized yaw at least once.
Yes, the issue of not being able to initialise the yaw from GPS-for-yaw is still on the issues list and is unlikely to be resolved before 4.1.0 is released. I’ve added it to the GPS-for-yaw improvements issue but I suspect this is one that @tridge will need to help us with.
@Leonardthall
I guess, you mean a test for the “PreArm: EKF attitude is bad” issue when trying to arm without having a GPS for Yaw initialization before?
I mention this, because I also had these “Error pos vert variance” messages when the EKF3 position estimate was going mad which caused a crash with beta5 (you still have that in your issue list).
May be, this has something to do with the communication going on when using GPS for Yaw with two ublox F9P relaying RTCM messages through the Pixhawk.
Sure - BUT when I also see these messages on the ground or even in-flight when there was no download active, it may be an indicator that the CPU is heavily pegged, right?
You haven’t had a chance to test the binary from @Leonardthall have you? Sorry to be pushy but “scary guided” (as we are calling it) is the final blocker for the 4.1.0 release so I’m quite keen that we get to the bottom of it.
By the way, we’ve modified Guided mode’s behaviour after takeoff has completed and I suspect this will mean that the issue cannot be reproduced using 4.1.0-rc3 but I would like to be sure. Because it is difficult to prove something doesn’t happen ideally we’d like you to try and reproduce the issue with the binary that Leonard has provided.
If you can easily reproduce it with Leonard’s binary but cannot reproduce it with -rc3 that would also be good to know but I understand this would be a bit more testing than you may have time to do.
My apologies, I have not had a chance to test it yet, we had to roll back to 4.0.7 to work towards a deadline for a demo.
I will endeavor to test as soon as we can, but the weather here is forecast for rain for the next 5 days at least, so it will probably be about a week till we could test this.
I also have no idea if I will be able to reproduce the issue, as we had many successful flights on 4.1.0 without this issue until one day we had it happen twice in a row. I will be loading the same parameters and flying in the same location to give best chance of reproducing.
If I manage to reproduce the issue I will flash with rc3 and try that.
Found a break in the weather and did this test just now.
With the firmware Leonard provided, managed to reproduce this issue on 3/3 takeoffs.
Then we flashed rc3 and did 4 takeoffs without the error occuring.
Hope the logs are useful, looks like the problem is fixed.
Two logs from the PSC firmware showing the issue, and two logs from rc3 with normal takeoffs.
Thanks for that. As @Leonardthall says your testing was very helpful and allowed us to figure out what the issue was. Copter-4.1.0-rc4 will be released today or tomorrow with a fix.
We’ve released -rc4 so if you have time could you re-test and confirm you don’t see the issue? It is pretty much guaranteed that you won’t because it sounds like you didn’t see it with -rc3 either but it seems like you are in the best place of anyone to confirm.
Thanks again for your help with this, your report was very valuable.
The jerk was set to a very low number due to a missing conversion from m/s^3 to cm/s^3. You have relatively high vibration levels so this meant it took time to bring it back to zero. This meant that you moved a long way.