Any chance you could provide an onboard log? A parameter file gives us the setup but doesn’t gives us an information on the issue you’re seeing. My off-the-cuff guess without a log is that the RC transmitter’s throttle stick is slightly too low. You might find that by increasing RC3_DZ from 30 to 50 the issue goes away.
BTW, it’s normally not a good idea to set EK3_SRC1_POSZ = 2 (RangeFinder). I’m pretty sure we have some wording on the wiki recommending against using rangefinder. If not, please tell me which wiki page you’re looking at and I’ll update it. The only place where setting the POSZ source to rangefinder is indoors with a completely flat floor with no “ground clutter” (e.g. tables, chairs, boxes, etc). If that’s the environment then it may be OK.
In Loiter mode Surface Tracking should keep the vehicle at a constant height above the ground.
Thanks for your response. I linked a few logs below.
As for EK3_SRC1_POSZ = 2, it was from my own troubleshooting rather than wiki. My logic was trying to force EK3 into looking at only rangefinder and barometer–like putting blinders on a horse haha. The reasoning for that is that I’m not using GPS at all as I’ve had multiple flyaways from multiple platforms in our environment. M600, S1000, Mavick Zoom, Parrot Thermal, etc…
So far, Arkflow has been dependable enough to hold x and y in varying terrain. I’m still building confidence with it but so far, so good.
I’m glad you mentioned the deadzone in throttle. My next step was to look at joystick calibration, PWM values and perhaps even change out the GCS.
Edit: Here’s a fresh log with bringing the throttle dead zone from 30 to 50.
As per log 179, I’m looking at the delta in CTUN’s BAlt (baroalt), DAlt (desired alt) and Alt (inertial nav alt estimate):
Mot_Thrst is at .2. I’m kicking it up to .3 for the next flight but shouldn’t the Arkflow override Mot_thrst in loiter mode? Or should I increase mot_thrst such that it’s less of a delta?
Just did a flight with Mot_Thrst set to .3 and no change.
I’m reviewing the optical flow logs x vs x body and y vs y body now. Perhaps if I can clean that up a bit, range finder will be used? Perhaps there’s too much of a delta between x,y and body x,y, for EK3 to use the data and engage Arkflow’s lidar? Just going through my thought process out loud so future readers can see what I’m trying.
So I cleaned up the x and y scaling and still having an issue with holding altitude.
Considering how an EKF works, mathematically, I’m wondering if the data between the barometer and range finder is too inconsistent to properly fuse the two into a meaningful signal, causing the drone to revert to barometer, hence the identical rate of descent I experienced before optical flow was added?
I never use the rangefinder for height that comes with the optical flow, I always use an additional external rangefinder for height (parallel process). Also, the range is higher. onboard to me is like serial processing.
Are you referring to this? It only appears at Hereflow.
To use the onboard lidar (not recommended).
I have a few drones for outdoor (GPS) and setting POSZ to the rangefinder with barometers covered up, superb height holding with the wind.
EK3_RNG_USE_HGT,63
EK3_RNG_USE_SPD,6
EK3_SRC1_POSZ,2
EK3_SRC2_POSZ,2
EK3_SRC3_POSZ,2
SURFTRAK_MODE,0
Thanks. I’ll this as well tomorrow morning. I see you’re really forcing the drone to use the rangefinder and I’m starting to think the same way. It’s like putting blinders on a drone, forcing it to stay focused on a specific source. haha
Worst case, I’ll add a dedicated lidar tomorrow. I’m super happy with the x and y stabilization but the z just doesn’t change.
In the log provided above the pilot’s throttle input keeps changing so it is a bit hard to see a moment where the vehicle should be trying to maintain a stable altitude.
In the graph below the pilot’s throttle input is in red. The desired “sonar” alti is in green and the actual is in blue. We see the desired and actual are fairly consistent albeit with a bit of oveshoot and lag.
If you’ve got time maybe you could do a flight where the vehicle just takes off and then you hold the throttle in the middle? If it descends that’s OK, we can hopefully see why.
If this vehicle is being flown outdoors please do not use EK3_SRC1_POSZ=2 (rangefinder). It should be 1 (Baro).
By the way, there is about 2m of barometer error when the vehicle takes off. This could be reduced by perhaps lengthening the vehicle’s legs.
Here’s three logs from just now. I tried to give a larger time period when I’m center stick. I also armed from 12" off the ground rather than 3".
I’m also using a GCS that has a scroll wheel, allowing me to adjust the PWM range of my flight. Similar to cinematic, regular, and sport modes, I can choose between 5 different settings that scale the aggressiveness. I don’t see how this could impact holding altitude but it’s something to mention at least.
My guess is you’re not using a traditional RC transmitter but instead something like the Herelink that is running QGC and perhaps you’ve selected “zero throttle at mid stick”.
Have you verified with MP’s RC view, I noticed RC3 (Throttle) I need to set reverse at the Herelink RC side, then throttle stick up bar up. throttle center 0 uncheck.
I haven’t tried that on herelink (yet), only with the other GCS. Oddly enough, during calibration in QGC and joystick view, I see 1500 as center stick on C3/Z/Throttle.
So somewhere between calibration and actually flying, the GCS is sending out a signal less than 1500 at center stick. However, I expanded the dead zone on throttle as high as Mission Planner will allow and I’m still seeing the same descent.
And yet, the logs do show a throttle output of less than 1500 at center stick–despite 1500 being shown as center stick in both QGC and Mission planner.
Perhaps looking at the raw pwm signal on some PWM analyzer would be a good 3rd perspective?
