Arkflow and Z drop

Ah right, I cleaned it up a bit. I’m at -650 now.

Still, altitude isn’t holding.

I changed the parameters you mentioned:

“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”

No change… still dropping altitude when sticks are center.

I also played with offsetting the barometers data to closely match the OF altitude (barometer consistently showed -1.5 to -2 meters on initial boot).

Hi @RT22,

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.

Thank you. I’ll do another flight right now, climb to maybe 5 meters and let it drop. I’ll activate landing mode about 1.5 meters.

It seems to descend about 1 meter per second at center stick.

1 Like

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.

Hi @RT22,

Thanks for the logs. So it looks to me like the pilot input throttle (see the blue line) is being held low.

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”.

Correct. I switch between herelink and an older, discontinued GCS.

Increase throttle dead zone and/or recalibrate throttle?

Edit: Just did another flight with the dead zone C3 set to 200 and throttle dead zone set to 250.

No change.

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?

Do you think you have a cross-channel setup accidentally? meaning two hardware buttons or stick set to channel 3? Have you done a hardware RC calibration on the Herelink side? I do not experience that in my Herelink. My Herelink firmware build is BRU01211104. In the past, we have had trouble upgrading it to a newer version and we have given up upgrading.

Hi @RT22,

In this case increasing the deadzone won’t help I think so I’d return RC3_DZ back to 30 or 50.

This is all outside of AP now so I’m just guessing but I think it would be good to look at MP’s RC Calibration page and make sure that around 1500 is output when the throttle stick is in the middle position. This appears to be the issue. From AP’s point of view, the pilot is pulling the throttle down.

While I wish it was a simple parameter to adjust, this is a solid start point. I have multiple GCS’s so I’ll change those out tomorrow and see if that changes anything.

Solid thanks!

I’ll update the thread when I get this sorted.

1 Like

This isn’t on the herelink controller actually. It’s on a GCS that was discontinued a few years ago but I have multiples to test.

Tomorrow I’ll switch to herelink and see if the situation persists.

1 Like

Data from the ARK Flow rangefinder in the logs looks good. It is a 30m sensor, so the only reason to use a separate rangefinder would be if you wanted more range.

1 Like

I changed ground control stations to herelink and it’s the same rate of descent.

So it’s not the GCS.

Arkflow is sending good data.

I’ve been warned against doing this but I’m going to fuze velocities and give it a shot.

Ordered some extra props… haha

Check with Ark Flow to see if the sensor can configure to support higher transfer rate or higher sampling time. In my additional height sensor case, I use 921600 bps serial speed.

If I remember your log correctly, you haven’t Autotune the drone yet. Of course, a low noise and low vibration drone result in a better tune.

1 Like

Hi @RT22,

Feel free to send on a new log but I just want to reiterate that from the previous log that was posted above the issue was very clearly that the pilot throttle stick was pulled low.

The issue was not the rangefinder, not vibration, not tuning.

I’m happy to look at a new log of course.

1 Like

Ok, here’s another log from today.

What catches my eye the most is the delta between CTUN Alt vs Salt (achieved altitude vs achieved rangefinder altitude or DAlt vs DSalt.

This is with a new ground control station (Herelink). Terrain is my back yard with minor obstacles (picnic table etc). Bright, sunny day. I also did a few attempts over a concrete slab and had the same experience.

Hi @RT22,

Thanks for the log.

Re the Alt vs SAlt different. The “Alt” field is not actually the altitude above home but instead the altitude above EKF origin. We could change this to be altitude above home but internally the controllers are all based on offsets from the EKF origin.

In general one wouldn’t compare DAlt and DSalt because one of the altitudes is an altitude above home while the other is desired altitude above terrain (aka desired sonar alt). Instead, if we want to judge whether the altitude controllers are performing correctly or not we compare DAlt vs Alt (desired vs actual altitude above home) or DSalt vs SAlt (desired vs actual altitude above terrain).

So here is the DAlt vs Alt and the two match quite well.

Here is DSalt vs Salt and it also looks quite good with the two matching each other (the actual should slightly follow the desired).

Again in this log when we look at the RC input for channel 3 (throttle) we see that the pilot is just jamming the throttle completely up and then completely down. I’m pretty sure that if you try other modes like Brake and Guided you’ll find the vehicle holds altitude. So the issue is with the RC.

Have you checked MP’s RC calibration screen to ensure that when you release the throttle stick the throttle goes to the middle position?

When I connect with my herelink and then open MP (which automatically connects to the vehicle through the herelink because I’ve enabled my Herelink to connect to my local Wifi) then I see this.

Thank you.

I’ll look at RC calibration again but I’ve changed 3 different ground control stations and I’ve had the same consistent issue. 2 Herelink and 1 joystick.

Strangely enough, the drone begins to descend as soon as I reduce throttle input from from 100% to, say, 80%. It’s falling when I do anything less than full throttle. One might suspect the thrust/weight ratio is off but that’s definitely not the case since the actual thrust/weight ratio is about 3:1 without payload.

To give a clear signal in the logs, I release to center stick so we at least have a nice contrast in input. However, anything less than 90% and we’re falling.

I’ll recalibrate the GCS’s again though and update new logs.

Thanks again for your patience!