@Hacky Could you repeat the test using this firmware. It has additional logging.
https://drive.google.com/file/d/1GtOoBU2NNJCH4cvGjiA49ORV9E3ZOS8t/view?usp=sharing
@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?
Here is the log recorded with your V4.1.0-rc2-PSC firmware:
https://drive.google.com/file/d/1lj0C0A70wfCS_2_iWpLfQhQQO83CdUbC/view?usp=sharing
@rmackay9
I recognized another issue with rc1 as well as with rc2:
During the download of a bin logfile from the Cube Orange, I get messages like
āError pos vert varianceā
ā¦andā¦
EKF3 IMU0 forced reset
EKF3 IMU0 initialised
EKF3 IMU1 forced reset
EKF3 IMU1 initialised
EKF3 IMU2 forced reset
EKF3 IMU2 initialised
I have enabled LOG_DISARMED: 1 and LOG_REPLAY: 1, so the download of an older log takes place during a newer one is recorded.
You do not find the error message in the new bin log written during the download process but you can see / hear it, when replaying the tlog.
You can find the bin log and the tlog here:
bin: https://drive.google.com/file/d/1EYR7qotZNY2xWHd9pdEV568MdvzZUvWR/view?usp=sharing
tlog: https://drive.google.com/file/d/1fp3MXQyCORDyKmD01NILvZsz_RdsWqi8/view?usp=sharing (messages start at about 95%)
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.
Log file download pegs the CPU and nothing else can run which is why you see the errors you do. Itās a known issue and will not affect you in flight.
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?
It is a good idea to limit the amount of constellations the F9P listens to in order to reduce GPS communication traffic, yes.
How many bytes per second is your RTCM injection doing? Should be bellow 4Kbytes/s?
Could you repeat the test using this firmware. It has additional logging.
https://drive.google.com/file/d/1GtOoBU2NNJCH4cvGjiA49ORV9E3ZOS8t/view?usp=sharing
1 Like
Sorry, that was supposed to be James.
1 Like
Yes, this firmware from @Leonardthall is for @james33 so that we can hopefully get to the bottom of the āscary guidedā issue.
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.
Thanks again for the report.
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.
Sorry for the delay.
1 Like
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.
Sorry this took so long
1 Like
Thanks a lot James, this will be very helpful!
It is also good to know this is reproducible at your end!
2 Likes
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.
1 Like
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.
1 Like
Good to hear the fix is in!
I should be able to test this sometime in the coming week if the weather relents.
Iād be interested to know what the issue was and where the drone was trying to fly to?
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.
1 Like