Thanks for your reply. @rmackay9
Is it safe to use this version or is too soon? Becouse I have a 10kg hexa and I dont want crash it.
Hello.
With F9P GPS i have beautiful GPS_alt readings. I would like to use it as altsource.
BUT
With EK2 we had parameter EK2_Altsource.(or similar)
With EK3 i see no such parameter.
Is there any possibility to do it with ek3?
Thank you.
EK3_SRC_POSZ I think
1 Like
Thank you! I guess that´s it!
I think even if you do that, the barometer still has influence over altitude.
After upgrading to 4.1 I have noticed 3 small issues
-
In previous versions I used GPS a the main altitude device, To make this change in 4.1 I need to amend the EK3_SRCx_ parameter but donât have it in the full parameter list.
-
Sometimes the copter fails to enable loiter mode. In the log files it shows. Err-Flight_Mode-5. I have recalibrated the compass just incase it was an issue.
-
When flying forward in loiter mode there is a high frequency buzz almost like the copter is over tuned But in Alt hold mode flying at the same speed there is no buzz
Below is a log file with the problems. Might need to do few more flights to better demonstrate the third issue.
You have 3 baros, 1 and 2 are tracking closely to each other, 0 is a little bit off. EKFâs job is to combine that data with GPS Alt and defaults are usually OK. Be aware that GPS Altitude could be inaccurate and varies a lot. These are the EKF params you are after, I see them fine in full parameter tree:
EK3_ALT_M_NSE 2 - Increasing it reduces the weighting of the baro measurement and will make the filter respond more slowly to baro measurement errors, but will make it more sensitive to GPS
and EK3_SRC*Z params.
I would not be inclined to change the EK3_SRC params but maybe try adjusting EK3_ALT_M_NSE and see how that affects things.
Itâs not changing into loiter because
Mode change to LOITER failed: requires position
The GPA Delta is all over the place even though number of sats and HDOP are generally acceptable.
Try setting GPS_GNSS_MODE,65 or GPS_GNSS_MODE,5 and see which gives more consistent GPA delta. The GPA delta is the update rate from the GPS. When they get overwhelmed with too much data from more constellations the update rate slows or varies a lot. Limiting the number of consellations usually helps. Most regular GPS units only handle two constellations at once.
If you set FENCE_ENABLE,1 then you wont be able to arm and fly until thereâs an acceptable 3D fix and you will avoid these issues - even though it seems to take ages to get a fix, you get used to it.
Tuning seems good in that pitch and roll are following desired quite well. I suspect that if you check and change the things I list below then run Autotune youâll end up with higher ATC_ANG P values and lower ATC_RAT PIDs. That might take care of your odd motor noise. RCout values are a bit noisy looking even though stability is good.
Use the Alt A plug-in to set the rest of you battery params and make sure your existing params match what they should be for initial settings. Gyro and filter settings look good though.
Set these:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
Your MOT_SPIN_ARM is quite high and almost the same as MOT_SPIN_MIN, normally it would be a few more points lower. This is not a critical thing at all, usually MOT_SPIN_ARM just needs to spin the props enough that you can see they are working.
You could adjust the Harmonic Notch Filter a bit, it wont make a lot of difference but just to get it closer
INS_HNTCH_ATT,40
INS_HNTCH_BW,45
INS_HNTCH_FREQ,90
INS_HNTCH_REF,0.25
2 Likes
Thanks for trying out Copter-4.1.0.
I had a quick look at the log and I think if the EK3_SRC1_POSZ parameter is set to 3 (âGPSâ) then the vehicle should use the GPS for altitude. I see the parameter so hopefully it should show up in the full parameter list. Iâm sure it will show up in Mission Planner although Iâm a little less sure about QGC.
It is failing to enter Loiter mode (probably) because the EKF doesnât yet have a good position estimate. It looks like the vehicle was armed and flow initially in Stabilize and AltHold which donât require a position estimate. This issue can be avoided by arming and taking off in Loiter or by at least leaving the vehicle in Loiter until the LEDs indicate it can be armed and then takeoff in Stabilize, AltHold, etc. This will ensure the EKF has a position estimate before takeoff. You probably already know this but just in case.
I might leave the âbuzzâ question to @Leonardthall âŚ
Update to the latest Mission Planner Beta? All the EK3 parameters are in your Parameter file.
Still not showing is this the latest beta 
David Ardis
Yes. Itâs what I updated to today. I donât know why the all the EK3 parameters are not shown.
In MissionPlanner main screen press Control-F and try Param gen
Hello.
By the time i upgraded to 4.1.0, i also changed gps from M8N to F9P (without base correction).
When i looked at the older logs with 4.0.7 and M8N (here3) (EKF2)the gps altitude looked horribly (jumping up and down 2 meters.)
however when i look at the logs now with 4.1.0 and F9P (drotek) (EKF3) the GPS_ alt readings are unbelieveably good.
Is it because F9P does so good corrections? or is it shomehow corrected with other sensors by cube and they are not raw data from drotek?
I am asking, because from the first time, they look like they could be used as good altsource (without drift cause by pressure) with multirotor.
And one more question about 4.1.0. Is it somehow possible to have lidar connected only for IR-lock calculations, but dissable terrain follow for multirotor altsource set as (Baro/GPS)?
I dont like that drone is following ground, while i use ir-lock only for landing.
Thank you
Shawn
Got that sorted and can now see all EK3 messages
David Ardis
I have done the changes as advised by @xfacta and the vehicle now arms and loiter works then enabled and after adjusting EK3_ALT_M_NSE the altitude is more consistent. I am still not sure what to do about the buzzing during forward flight in loiter.
Below is a link to the the latest log file
David Ardis
A couple things you could try. Set PSC_ACCZ_P equal to MOT_THST_HOVER and PSC_ACCZ_I equal to 2X this value. If no help try setting INS_ACCEL_FILTER to 10Hz
Set TUNE=0 if you are finished with transmitter-based tuning or it could interfere by accident.
You have what I would consider high Z axis vibrations, I would try to improve that.
Change INS_HNTCH_REF,0.25 to 0.20 , or even a bit less like 0.18 and see what difference that makes. The HNOTCH wont work below that value (throttle level), and your hover is 0.2 so at lower throttle settings you wouldnt be getting any harmonic notch filtering.
EDIT:
Actually Iâm checking my HNOTCH assumptions with Andy, but I think according to the wiki and the equation for setting INS_HNTCH_REF when using throttle-based HNOTCH, your value should be INS_HNTCH_REF,0.1764
I based that on INS_HNTCH_REF = hover_thrust * SQUAREROOT(min_freq / hover_freq) when I take a stab at your lower frequency in your FFT in that log.
At worst you would have to do a new test flight with INS_LOG_BAT_MASK,1 , check over the FFT and HNOTCH settings, then set INS_LOG_BAT_MASK,2 and check FFT after more flights.
Iâll let you know if Andy tells me Iâm wrong - which could happen! He points out that REF and FREQ values are not something to be just randomly changed without testing properly
I also meant to say you can set ATC_THR_MIX_MAN,0.5 too.
So far the tuning looks very good.
Donât know if something major was made to have the RM3100 work nice in 4.1 but i am pleased to confirm that i have never had a mag working as great as the RM3100 on 4.1