Baro - alt hold issue

[3djc]

I've been trying to adjust my alt hold on SPF3 Mini, but I'm facing s strange issue. Blackbox log is here : http://users.skynet.be/fa565566/LOG00001.TXT

Ignore the first half of the log, it is in my garden with trees all allround, needed to fing a safe spot. I'm iddling at arround 16/17m, all seems fine, then suddenly, it starts gradually loosing altitude with no appararent reason, nor reaction to the alt loss. Baro reads match what I saw
VEL PID : 5
ALT PID : 9 - 0 - 1

Does anybody know how to log debug1 to 3 values on blackbox ? I could compile an hex with ALT_HOLD_DEBUG

[Arakon]

Did you actually cover the baro with foam?

[3djc]

Yes, and protected from light, Baro reads as seen on the logs are very accurate

[mehmetyldz87]

same issue with NAZE32 & firmware v1.12

[lainchir]

Same here.. Naze32 Rev 6, 1.12. MW-rewrite. ALT hold is not good. I was fairly close with 1.11, but this one is not good

[lainchir]

Just out of interest, this evening, I set all my ALT PID values to 0. Set up stable hover, then flicked my ALT-HOLD switch.

At first, it began to drop slowly, then climbed rapidly to roughly where hover was. Then I got a blip and it shot up a couple of feet. Then a long burst of throttle, so I switched the baro off.

I was under the impression that at 0 PID values, switching the baro on would essentially do nothing?

[lainchir]

blackbox_log_BARO_15-10-8.TXT

Tried again on stock ALT / VEL PID's I switch the Baro on, and I'm sure I don't touch the throttle, but if you check RCcommand (Thr) it's all over the place until baro's turned off.

I'll try again as soon as I get some daylight

[calvarez]

I have the same issue with altitude hold on mine. It starts to erratically jump/fall all the time. I've got a plastic cover over the Naze32 with a big piece of open-cell black foam over the barometer. So I think it's well shielded from light and wind.

[lainchir]

It's totally erratic. Mine is in a 3D printed housing with foam on the baro, and (I think) the black box shows very little noise on the baro trace. As soon as I throw the switch, my rccommand trace goes wild. Is that actually "rc input" or what the flight controller is sending to compensate?

[ledvinap]

Probably ACC noise problem. Balancing props may help.

You may try setting baro_cf_vel to higher value and decreasing accz_lpf_cutoff, but it will probably cause even more problems

[3djc]

Ok, first day in a long time I've been able to properly test fligh, bad luck I only one one lipo ready (weather forecast was SO wrong).

1. the default for ALT-P seems to be 5. This means that at 1m distance from the target alt, it is targeting a 20cm/sec v-speed, In other words, it will take more than 5secs to make this meter (because target v-speed will reduce even further as it gets closer). It also means that the max v-speed of 3 m/s is only targeted with errors over 20m in altitude. Basicaly, this is not suitable for a quad, way to low. So I doubled it to 10

2. Because it would now try to achieve faster v-speed, I have reduced VEL-P to 3 (I:0 D:0), just to be on the safe side, a lot of obstacles where I was

All in all, this was way better, and certainly can be qualified as working, but I intend to do much more test tomorow

[ledvinap]

https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/altitudehold.c#L193

IMO it's 35cm/s for 100cm altitude delta

Main problem is that noise in accZ is almost 5G peak-peak. No filtering will remove it and estimated vertical speed is way off.

Another strange thing is that acc data are updated only at 100Hz, remaining positions are somehow interpolated:

red - accZ ( divided by 40.96, 100 = 1G), cyan is gyro for reference.

[lainchir]

I've been comparing my two dumps... 1.11 and 1.12.

These fields are different...

set rc_smoothing = ON (Set as OFF in 1.12)
set gyro_lpf = 42HZ (set as 188Hz in 1.12)

I can see the below acc_lpf in the manual for 1.11 and 1.12. There is no entry in the 1.12 manual for acc_cut_hz?? Has this replaced lpf factor?

set acc_lpf_factor = 4 (1.11 value. Doesn't exist in the 1.12 dump)
set acc_cut_hz = 15 (1.12 but doesn't exist in 1.11)

I might restore 1.11 and try my ALT hold.
Many thanks for your time looking into this.

[ledvinap]

Main problem is that TASK_ACCEL is run at 100Hz. This will cause aliasing of any ACC frequency over 50Hz.
Any filter (with reasonable delay) applied after this won't help (much). (filter is applied at 1kHz, wasting cycles)

LEVEL and HORIZON modes are probably affected too, but most samples are discarded (only 0.9-1.1G is used for leveling reference), so time constant is probably much longer than expected.

You may try recompiling with higher ACC update (https://github.com/cleanflight/cleanflight/blob/master/src/main/scheduler_tasks.c#L62), try 1000 or 2000.

[lainchir]

Hi Ledvinap,

I'm not able to compile sadly. I did however do a test by using stock ALT PID's at CF 1.11 and here is my blackbox. ALT hold works, albeit needs tuning slightly. Flight hardware is exactly the same... motors, props (same - they're well balanced) and battery.

Something changed in 1.12 to affect this?

blackbox_log_2016-03-13_122612.TXT

[ghostsharp]

Hi,

I use Naze32 full and i tried to configure PIDs for ALT Hold too, and... was impossible, i have foam covering naze32 and i tried a lot of combinations of ALT and VEL pids, but i havent luck, teorically ALT is for configure Baro and Vel is for vertical speed.

Anyone know how to configure correctly or is impossible in 1.12?

[lainchir]

Related to Issues #1946 and #1949 ?
If these are performance (racing type) enhancements, maybe having the separate profiles as discussed in issue #1893? To specify what CF is to be used for? For me personally, as a beginner to CF, and quad flying in general, would just like a stable platform, without full on race performance. One 450 quad I use is for camera use, the other is to learn FPV.

[digitalentity]

@lainchir yes, it appears that CF is going down the road of becoming a racing-oriented firmware. Sometimes this leads to favoring acro-mode performance and sacrificing quality of self-leveling, altitude hold etc.

[lainchir]

That would be a real shame if that was the case.

[ghostsharp]

digitalentity your firmware is based in cleanflight, have the same problem actually or we can migrate to your firmware?

In my city there is a lot of people that have naze32 and sp racing f3, but look for more relaxed flight. For races often use betaflight.

[digitalentity]

@ghostsharp
Althold in iNav is much more stable and requires much less tuning. You are welcome to join the thread on RCG and #inavflight IRC channel!

[hydra]

Hi All, after some very important internal code changes that really need doing for 1.13.0 we can turn our attention back to the non-miniquad racing scene. Yes, there has been a certain drive in that area recently, mainly due to @borisbstyle recent developer availability however I am keenly aware that people want to more than just fly FPV mini quads.

Merging the iNav code back into cleanflight will be a priority.

[digitalentity]

Hi, I was afraid you took Cleanflight towards being a race-only platform. Good to know I was wrong! Thanks for the access! 😃 Regarding this issue. In iNav this issue is not existent as the whole position in 3D space is estimated with great accuracy. I don't think we should concentrate on fixing the piece of code that's going to be replaced altogether. After 1.13 I'll start merging small things of iNav to CF, but we'll need to consider the ways of freeing up space for main part.

[MJ666]

May be we should really focus on the more capable targets for the NAV features. It does not make sense in my view to limit main functionally to fit this into the F1 MCU's. May be the F1 should keep good flight performance and will be even good for racing but navigation and may be autonomous flying will be done on F3 and F4 targets only. They will provide more memory and CPU power for this to sture all the additional code/configuration and run more complex algorithms. Adding and removing features specific for individual targets work quite well in my view.

[digitalentity]

@MJ666 it depends on the definition of main functionality.
If main functionality is "racing top performance" - why bother with navigation at all?
But I don't think this is the case and I would rather cripple features that are not needed/not used/are confusing from UX perspective - i.e. having a zillion different PID controllers with different behavior.

[digitalentity]

The solution may be having an online firmware building environment. You select what features you need and get the customised firmware.

[lechak]

Have issue with BMP280 in AltHold mode. In AltHold my quad start "jumping" up and down +-5 meters. PIDs changes had no effect. In Cleanflight Configurator i see smoothed altitude data but looks like in flight controller used RAW data from sensor. I'am connected with EZ-GUI from my phone. It shows me raw data from baro and spikes in graph look like quad jumps.
But when i'am flashed Baseflight firmware althold start work perfect.
I think Cleanflight take raw data instead of smoothed recalculated data for AltHold with BMP280.

Flight controller: Naze32 rev.6
260mm quad.
DSM2 satellite reciever
Transmitter TGY9x with DSM2 module.

[ledvinap]

@lechak : see #1946

[AirwolfFPV]

@lechak Could you try with Cleanflight 1.13.0? The accelerometer issue has been fixed there
Althold works quite decent with my BMP280.

@digitalentity good to hear that, I would love to see RTH with Althold and auto landing in Cleanflight 1.14, never quite managed to set up throttle landing (probably because throttle controls acceleration force and not velocity)
As a side note, MultiWii also has althold and auto land with auto disarm on RTH

[lechak]

Baro issues was fixed since 1.13 RC1. Now i'am fly on 3862_a645e2c_travis build. No time to reflash to stable release. But all fine now.