The internal error in the title appeared along with the symptoms described in the initial post. It has come to my attention that the same internal error appeared on the new rover release as well. I got the suggestion to create a new post to bring the attention to this internal error in particular.
To read about the behavior in flight, pleas read the linked post.
This is the initial log file where the issue first appeared (the first flight of 4.3.0)
I switched back to using barometer for altitude. The issue of the repeating jerks is still there and the internal error is still there (the same one) although the jerk movements occur less often.
I also changed PSC_VELXY_FLTD back from 2.5 to 5 (default value)
Also, @xfacta@rmackay9@dkemxr
I saw that you randy posted that this internal error of flow_of_ctr was going to be investigated. What I would like to ask you guys is if there is any value in me doing tests for you, since the issue is so apparent in my case, or if I could go back to 4.2.2 until this is resolved?
If me helping with tests would make it easier to solve this, I can assist with that, but if not, it would be
nice to be able to fly normally again.
What has happened before is a new release has a different level of error detection and there is no real “issue” just a different way, or a more stringent way, of detecting what was always there. I don’t know if this is the case with this message but the Dev’s know about it so we’ll see what happens. Personally I wouldn’t revert back. I would probably load the latest Dev version on a craft and see what happens
Case in point is the “failure to level, manual tune may be required” for Auto Tune. I think some asked if this was a Bug because it wasn’t seen in the previous release when run on the same craft. Well, no…
I’ll stick to the latest than. I thaught there was no dev versions yet. I thaught that you guys worked on 4.3 untill it was ready, than moved to make 4.3.x beta firmwares
I’ll look if there is any beta avalible.
Also, if this is a timeing error, does that mean my fc it too old? Or not precise/exact enough, so that I will have to get a new one? I’m running a cube black at the moment
The Dev/Master version is 4.4.0-dev. New features are untested by users, that happens at the Beta level. But it’s available in the “Latest” directory for the non risk averse.
I haven’t got tested on 4.4.0 yet, but I wanted to ask you about the beta firmware button.
If I press it i get 4.3.0 beta. I’ve read about, see below, 4.3.1 beta1 for example. How do I get that one? And if I press the beta firmware button, what does it really do? Since ctrl+Q gets me the dev beta?
I’ve been reading a bit on github about the issues related to 4.3.0. I can see that the resolved issues has a note that says that on for example is resolved in 4.3.0 beta2 and another in 4.3.1 beta1. What does that really mean?
Are both this issues resolved in 4.4.0 than? And is the one in 4.3.0 beta2 resolves in 4.3.0 stable?
There is Beta and there is dev or Master, they are not the same. dev/Master is the development release, not really for common use by users. Developers play in this ballpark to add and test new features. Beta is generally safe to fly but that’s a personal choice. Sometimes new boards or desired features are added to Beta or dev/master and you have no choice.
Here is the best way to get the release you want:
Go here and select Stable, Beta, or Latest (which is yet another term for dev or Master) Copter Firmware
Then let’s say you picked Beta and you have a Cube Orange and select that: Cube Orange
Open the “git-version.txt” file and see what Beta version it is. In this case today it shows the Stable version so there is no Beta version available. But, say you want to install this anyway. Download the .apj file and then use Mission Planners “load custom firmware” option to flash the board.
I see no evidence the issue(s) has been resolved in any release.
You can monitor the Discord channel also. It can be messy with people posting in the wrong threads but the Development> #general_dev or dev-team (which the rabble can’t post to) can offer some interesting dialog. There is some chatter about this issue.
This is a CubeBlack running three EKF. You are getting lots of long loops and this error happens when we detect that the position controller has not been run for 5 times the normal loop time. If you disable the third IMU I think you will get enough processing time back to keep up.
This error has a number of causes. The main one we see is during start up where initialisation processors run long and the position controller has been started already, this is just annoying but should be fixed. We would also see this error if some process was running very slowly for some reason, this could be a serious issue.
In your case I suspect it is simply you are overloading the processor on the autopilot. Every release we make things better but also increase the memory and processor usage. I think the features you have turned on are just pushing things just a little too hard.
So this error isn’t a problem with the position controller, it is a problem with other areas that is detected by the position controller.
I hope that by going from 3 EKF to 2 EKF you will have the extra processing time to keep up.
