Ok that’s what i was wondering if it was merged yet that explains why.
OSD Flight Time item does not work for me on iFlight BeastF7
Please check https://www.youtube.com/watch?v=JYFzID5rUBk
Flight Time is on bottom right; Throttle level is on bottom center.
Cannot do anything for next few weeks cause of covid situation in Delhi, India @amilcarlucas no, we are using custom build omnibusf4pro clone, it doesn’t have any heater, also temperature at my place does varies quite significantly
Any news on whether this beta is going gold and when.
I hope to release -beta2 within the next week but I think we are still a long way from releasing Copter-4.1.0 as the stable version. My rough guess is it will be 2 months but it really depends upon how much help we get from the community with the beta testing and how long it takes us to resolve any issues found.
Just thought I would ask.
It’s great to see such progress. Looking forward to flying it.
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 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: https://ardupilot.org/copter/docs/common-gps-for-yaw.html#common-gps-for-yaw
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.
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.
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.
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 (https://ardupilot.org/copter/docs/common-rangefinder-hcsr04.html). But the sensor readings are not read on the mission planner. How to solve this?. Thank you.
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!