Servers by jDrones

Copter-4.1.0-beta released for beta testing!

Thanks Randy
Just thought I would ask.

It’s great to see such progress. Looking forward to flying it.


1 Like

Just curious about 4.1. Is it a rework of the total code or some form of off shoot or are the other codes in play today offshoots of 4.1. Just curious how this whole versioning works. It’s not important. Just curious.

It’s an incremental improvement. And it does not concentrate in a single area, almost all areas do get affected.


The way it works is all the developers work off of “latest” (aka “master”, aka “ArduCopter-4.1.0-DEV”) and then for the first few beta versions we just take a copy of “latest” and release it for testing. Eventually the beta versions start becoming more stable (because the developers are focusing on fixing any bugs that turn up) and so each beta is simply built on the previous beta with just bug fixes added. Finally when we go about two weeks without any unexplained crashes and all known critical bugs are fixed we release the stable.

Also at some point we will stop calling them “betas” and start calling them “release candidates”. This is another sign that we are becoming more confident with the quality of the release.


Thanks for that Randy.
I just never understand why some people would talk about things being in or not in or over on this branch or version. Found it confusing, but I get it now.

thanks heaps

Thanks for your excellent work making EKF3 now the default estimator and allowing “GPS for Yaw” in combination with a fallback to magnetometer based yaw!

I am already testing the “GPS for Yaw” since some days and plan to go into the air with it this week as the correlation between real heading and heading shown on map looks really promising.

But currently I am facing the problem, that I get the error message “PreArm: AHRS: EK3_MAG_CAL and EK3_SRC1_YAW inconsistent”, which prevents me from arming the aircraft.

I have configured the compass fallback with EK3_MAG_CAL = 6 and EK3_SRC1_YAW = 3 (“GPS with Compass Fallback”) as described here:

Before adding the second F9P GPS and updating from 4.0.7. to 4.1.0 beta, the compass worked fairly well. It is an externally mounted LIS3MDL.

If you think, I should open a seperate thread for that topic, just give me a hint here.



Thanks for the report. I fixed up the wiki page yesterday and I think you’ll want to set EK3_MAG_CAL to “3” (“After first climb yaw reset”) because “5” and “6” aren’t valid values for 4.1.

Looks like I have a couple other things to fix on that page too.

1 Like

OK - but what exactly does “After first climb yaw reset” (EK3_MAG_CAL = 3)? Which is the minimum height for this yaw reset?

The wiki page says “that the rover GPS module is in fix type 6 (fixed RTK)” is one of the prerequisites, the GPS driver validates in order to decide, that the signal is good enough.

What happens, when the fix type of GPS2 goes down from 6 to 5 (“rtk float”) in between? I saw this several times (may be 5% of the time) but after some seconds it usually went back to “rtk fixed”. Will the copter fall back to “compass yaw” already then or will it keep on using yaw from GPS also with “rtk float”?

As you can see in my screenshot above, also the first GPS has “rtk fixed” because I was using correction messages via NTRIP connection. I assume, this is not a prerequisite for GPS yaw (it seemed to work also when first GPS only had 3D gps fix or rtk float)?

Are there also other parameters on that page, that need to be fixed? I am a bit anxious to go into the air with this new and pretty rare tested functionality with a valuable drone…


In Copter-4.1 the EK3_MAG_CAL controls when the compass calibration is done. So “3” means the heading will be reset to align with the compass when the vehicle first climbs past 2m above home.

According to the wiki, there are three requirements for AP to pull the heading from the GPSs

  • the rover GPS module is in fix type 6 (fixed RTK)
  • the reported distance between the two modules matches the distance given by the GPS position parameters within 20%
  • the reported heights of the two GPS modules match the attitude of the vehicles is within 20% of the distance between the two GPS modules

I’m not aware of any other changes that need to be made but I also have to say that I’ve never personally used GPS-for-yaw.

I think that if the heading appears to be correct on the ground station map (e.g. compare the vehicle’s heading on the map vs reality) and the little EKF label on the Mission Planner HUD is green then it should be OK. Especially if you’re ready to retake control in a more manual mode like AltHold or Stabilize it will probably be fine.

1 Like

Thanks, I saw that you updated the documentation meanwhile.


Now I am facing another problem: When the copter is inside a building where I have no GPS, it is permanently issuing the message “PreArm: EKF attitude is bad”. This prevents me from arming the copter (even in “stabilize” mode) although I would expect that it should fall back to compass now.
I am using the configuration as given in the updated wiki (EK3_MAG_CAL = 3 and EK3_SRC1_YAW = 3).


Thanks for this report. After a quick discussion with Tridge, it seems likely that you’ve hit a real issue with our GPS-for-yaw feature in that it may not use the compass unless it has used the GPS for yaw at least once. i.e. it really is a “fallback” only.

I’ll try and reproduce this in SITL but could you create a new topic for this discussion in this Copter-4.1 category and if possible include an onboard log? You may need to set LOG_DISARMED = 1 to produce a log while the vehicle is disarmed.

Thanks again for the report. I’ve added this to our 4.1 issues list.

1 Like

Thanks for taking it on your issues list.
As requested, I opened a seperate topic and attached an onboard log.
You find the thread here: Issues with "GPS for Yaw" and compass fall-back

EDIT: There was also another strange issue during the first testflight. I opened another thread for that topic here: Unhealthy GPS signal when using "GPS for Yaw"?

Excuse me. I have tried to make use of new HC-SR04 driver (sonar sensor) in beta 2 Copter 4.1.0. I assign BRD_PWM_COUNT to 0, and follow the documentation ( But the sensor readings are not read on the mission planner. How to solve this?. Thank you.

Hi @Galang_Wedana,

Any chance you could upload an onboard log? It may be necessary to set the LOG_DISARMED parameter to 1 in order to produce the log while the vehicle is disarmed.

With a log we can more easily check all the parameters and confirm that the rangefinder isn’t working.

Txs for testing Copter-4.1!

Hi @rmackay9 . Thanks for the fast answer. I already try to set LOG_DISARMED to 1 but the readings still not shown in Flight Data. When i armed the vehicle the readings also not shown. One thing i notice. When I use Arduino to try the sonar sensor, the sensor make a sound when operating, but when i try with my pixhawk1 there was no sound at all. Maybe this information useful to you.

Hi @Galang_Wedana,

OK, thanks for trying that out. The LOG_DISARMED parameter was really just so that an onboard log would be produced during testing. Can you post that log somewhere? Either attach it here or provide a link to it here? Sorry but without a log it is very hard to know what is going on. We often say, “it’s all guesswork without a log”.

I’ve tested my HC-SR04 here and it works for me both on Copter master and the current Copter beta.

By “works” I mean I’m getting RANGEFINDER mavlink messages and the distances seem to be about correct when I’m waving my hand about.

I’d suggest double-checking your wiring and pin parameters.

1 Like


Sorry to dig up an ancient issue but I’m reviewing all our open 4.1 issues to be sure we haven’t missed anything. Do you think the OSD flight time is now working on the iFlight BeastF7?

I do not see this problem, and I believe this isn’t related to a board but to a very low throttle output level. Since that time my copter become slightly heavier. Looks nobody else affected, so I think we can ignore that.

1 Like
Servers by jDrones