Copter-4.0.7: Arming causes AHRS values change

teod · September 1, 2021, 11:48am

Good day everyone,

I have been customizing Copter-4.0.7 specifically for my quadcopter (which uses a Pixhawk1 flight controller - original) and today, while testing a new code version, I found what must be a bug and so, I decided to write this on the foruns to see if anyone knows why this is happening/how to solve it or if it is indeed a bug on Copter-4.0.7 - since I have no clue.

I’ll start by saying that I first found this issue when running my code, but it seems that default Copter-4.0.7 as also something similar. I will also apologize for not uploading right away a log, but I’m not being able to extract from my board (I will get into it later) - I’ll have to wait to upload the logs (don’t have a sd card reader here).

For default Copter-4.0.7:
So, I have my quad on the ground, without any propeller and not even any battery connected to the ESCs. Connecting it to mission planner I get a reading of less than 0.1m/s for ground speed (which is constantly shifting), so no problem here. The problem starts to happen when I arm my drone, in Stabilize flight mode. This value of ground speed skyrockets to 0.3-0.4m/s (drone doesn’t even have propellers nor the motors are spinning). Disarming, the value goes down to 0.1m/s again. So, what may be causing this error? For the AHRS, arming the quad as it is, shouldn’t cause any modification on the values. So, why does EKF2 estimates skyrocket like this?

Also, when I tried to get the logs out of the board (first time I tried it), the connection timeouts and, most importantly, it causes a pre arm error: EKF starts changing between instance 0 and instance 1 (instance 1 has a value of ground speed of 0.2m/s and instance 0 has a estimation of more than 0.8m/s) - the board doesn’t get past this.

For my custom code:
The issue is very similar to what is happening with default Copter-4.0.7 but even worse. It behaves in the same way with the data logs extraction. I have a custom mode and arming the drone on it (again, without propellers and not even batteries connected), causes the ground speed to skyrocket to 0.8m/s and causes a permanente pre-arm check error (again, EKF instances constantly shifting between 0 and 1 - and instance 0 has a ground speed estimate of 0.3m/s and instance 1 of 1m/s).

Is this a known issue or has anyone passed through something similar and knows how to solve it? At the moment, the real problem is why EKF is giving this estimates and causing the pre arm check to fail, since arming should alter any of the estimated values, in my view.

Thanks

TLTR:
As soon as stabilize mode is armed, without propellers nor batteries connected, EKF2 estimate for ground speed skyrockets from 0.1m/s to 0.3m/s for a quadcopter which is on the ground, static, without moving. Same happens while trying to download log files but, this time, it skyrockets to 0.8m/s causing pre-arm check error with EKF, besides of a time-out.

PS: Here is the log, just arming the drone and disarming (with default Copter-4.0.7). Please let me know if it contains the information required (never debugged from a ardupilot log before).

https://drive.google.com/file/d/1v52sg0D--nNOV6PRF-Gk42iZklAUaCaw/view?usp=sharing

And what I think is the issue I’m referring to (value abruptly changing on arm/disarm):

And this is the video showing what happens after I try to download log files or even change mode:

Video of EKF failure

sergbokh · September 1, 2021, 4:09pm

I’ve reported something similar btw

teod · September 1, 2021, 5:01pm

I was not using EKF3 but EKF2 since I’m using Copter-4.0.7. Although your log shows something similar (see image), it seems to be more smooth than in my case (which is more close to a step). And yours doesn’t seem to be as persistent as my issue (I have always this climb/down to normal values in EKF estimates in every arm/disarm I do).

Looking at your comments in the foruns, you said that reducing the number of logs reduced this behaviour? Doesn’t the value reach these 0.6m/s as soon as you arm?

sergbokh · September 1, 2021, 6:02pm

Yes, I disabled logging at all on my BeastF7 FC and this solved the issue.
Though in my case there was not a constant VSpeed shift but something like EKF confusion with random errors of estimation.

teod · September 1, 2021, 6:06pm

Yeah, it isn’t the same, as I mentioned. Unfortunately, I can’t disable my logging But thanks for your input.

peterbarker · September 3, 2021, 3:17am

Please try the same test on master - and 4.1.0 beta if that’s fine.

speakerx · September 3, 2021, 8:02am

It seems something wrong with your barometer. BARO.Alt changed by 1m instantly when armed and Copter thinks that it moved

teod · September 3, 2021, 9:25am

At this moment, I will only be able to do that on Monday, so I will update then. Should I test beta with EKF2 or EKF3?

teod · September 3, 2021, 9:28am

I think that the depression in VD must be caused by the buzzer. At the moment, I have the buzzer close to the Pixhawk (less than 7cm). But the change in VE/VN is what is the most strange, IMO.

teod · September 6, 2021, 3:48pm

@peterbarker, Have just tested with EKF3 with latest beta and I get a similar behaviour, as you can see in the graph below. As soon as copter is armed, the velocity estimations start raising and as soon as the copter is disarmed, they lower to the supposed value (a realistic one, considering quad is static). Again, quad batteries weren’t even connected. But comparing with previous estimation, it seems to be better (although this change in arming is what I don’t understand).

During the tests, there was one in which the ardupilot was constantly changing between EKF instances.

For the beta code running EKF2, the same is happening, even though it doesn’t reach the same levels as in copter-4.0.7. As soon as quad is armed, estimated velocitie’s values raise and as soon as it is disarmed, they lower to previous values.

Is there something causing this behaviour? The change of AHRS values during arming/disarming?

Please let me know if more information is needed or what else should I try.