We discussed this on a different thread but in any case, just for others who may see this, the more concerning issue is the EKF’s yaw being inconsistent by 22 to 55 degrees. We’ve seen a few reports where the 2nd EKF’s heading has started drifting off and never recovers. We suspect that a gyro calibration will fix this but it’s a problem we should get to the bottom of. The problem is there is earlier versions of AP as well and I think it has only shown up in 4.0.x releases because we added the additional pre-arm check.
Thanks Randy. Further analysis with Tridge revealed that the setting of a compass priority around the same time as running offline compass calibration via logs resulted in the ridiculousness associated with Here2’s scaling factor of 1.17 getting applied to the wrong compass. We’ve fixed that mistake on our side as well on this particular copter by re-running the calibration and swapping the scaling factors, but that whole problem along with the HDOP being high and the satellite count being low has made us pretty sour to the Here2 and we’re actively removing them from our systems. Hopefully that plus future enhancements around this pre-arm check help with these Yaw inconsistencies we see.
That is news on what you’re saying about the gyro calibration though, we may dig in to that further with you as well if there is data we can provide that will help.
1 Like
Hi Randy, with the regards to the compass issue you mention. Shouldn’t the loss of a compass reporting a prearm failure be expected behaviour? For example, I have a setup on my bench at the moment with two Here GPSs for redundancy, and I would expect that if one of the compasses wasn’t available that I would get a prearm message and not be able to fly.
Consider the following scenario:
Two GPSs (and therefore two external compasses) are connected and working properly:
Compass 1 is then removed simulating a compass failure prior to flight, which is correctly identified:
If, however, I removed that compass on purpose, I would now no longer expect to look for it on startup. So I reorder the compasses so that the second UAVCAN compass is the last compass in the list, and remove the “external” flag for that compass:
After rebooting, we now only search for one external compass and the prearm check is now gone:
I expect that things are working as intended in the above workflow? It would be a shame for this feature to be removed when it’s such a useful way of determining when an expected compass is missing on startup.
Edit to mention: This is using static UAVCAN nodes. Haven’t checked behaviour with dynamic nodes.
Cheers, Jason
1 Like
Hi @jasclarke308,
Thanks for the detailed feedback. I definitely agree that if a compass goes missing the user should see a pre-arm check. The issue is just about how does a user resolve the pre-arm check. I had actually never thought of going into to prioritisation table and moving the old compass down. My thought was that if you did a compass calibration it should clear out any old compasses. Maybe both methods should work.
@bugobliterator’s PR that makes it do what I was thinking is almost ready and once it is, let’s give it a try and see.
P.S. I think specifically setting the external checkbox probably isn’t necessary. I suspect it also doesn’t hurt though.
1 Like
Hi All
Are there any plans to add CUAV X7 Pro Autopilot Board in the next Release of Copter 4.0.4.
I’ll check with @tridge if we can include it safely into Copter-4.0.4-rc3 that should be out next week.
Thanks for the support.
The current beta has the board supported, that is what I have been using.
Excuse me.
Is this version(copter) contains “AFS_Parameters"?
For example “AFS_RC_FAIL_TIME”,it’s very uesful to me.
I believe there are others who need it.
I hope the parameter will come ture soon with copter.
The parameters are there as soon as you set the AFS_ENABLE parameter to 1
No, I’m afraid the “Advanced Failsafe” is not included in Copter by default so the only way to enable it is to compile the software youself after removing the “//” from this line in APM_Config.h.
I’ve resisted including it in Copter because I worry it will cause more confusion than anything else because it’s not integrated with the standard failsafes.
Thanks,this’s a good news.
Next I will learn how to make source code.
Originally, I wanted to be a pilot,as a result,I became a programmer 
2 Likes
My drone crashed today.
Hi all,
During a routine flight made 20 minutes ago, my drone fell to the ground while spinning uncontrollably on the z-axis, please if anyone can take a look at the log.
https://drive.google.com/file/d/1513nuw3gE6XB2Apfv1lwsVEP657l914Y/view?usp=sharing
It has access request turned on.
Greetings All
I was where I might find the 4.0.4rc2 source code? I can only find the HEX.
I am trying to enable Yaw from GPS would like to have a look at the 4.0.4 code to see how it is done with this specific code.
I can see the functions when looking at the MASTER, but not sure how much of that code is included in 4.0.4.
Thanks very much
The Copter-4.0.x code is here in the Copter-4.0 branch.
For anyone interested in testing GPS-for-Yaw the wiki is here.
1 Like
You mean CUAV X7 arducopter.apj ( Copter 4.0.4 beta) is also compatible with X7 Pro…
Yes sir, the pro version is what I am using in my heli,
Just got back from trying Copter 4.0.4-RC2, was flying 4.1.0 DEV before. Now I am seeing it very jerky (starting and stopping) around the end of my survey pattern. It used to be really nice smooth turns and now it has almost a pause in it at every way point and before it flew smoothly through them. Is this a possible fix for the cutting corners issue at times? I have not changed any of my parameters so just wondering why it might be this way now.
@rmackay9
Thank you.
Thank you very much.