Copter-4.1.0-rc1 released for beta testing

@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.

like @andyp1per said, that is normal and you can ignore it.

Just do not download logs while flying. :stuck_out_tongue:

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.

@james33,

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.

@rmackay9 ,

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

@rmackay9 @Leonardthall

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

@james33,

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

@james33,

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

@rmackay9,

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