Repeated question: relation pressure sensor & altitude hold

[HeliHenkie]

Hi all,

I'm still trying to get a grip on altitude hold, but didn't get a usefull reply on my previous request for help.
When engaging altitude hold my quadcopter slowly drops to the ground, even with 3D gps fix and stick output around 700. I'm using AQ 6.6 rev37 for board #2.

Somehow I think the 'malfunctioning' of altitude hold has something to do with my pressure sensor.
I assume the AQ board uses the high resolution of the pressure sensor to determine the height and differences in height.

For analysis I made a short testflight where I hovered three times about 2 m above the ground. In the period between the hovering the quadcopter stood on the ground. When I plot [log_ukf_alt_pres] the result is a line that rises with time.
See attached image. For further analyses the download link to the logfile is:


I'd expect the controller to return the same value when standing on the ground.
There seems to be a drift in the output of the pressuresensor values that is so large it seems to correspond with the droprate of my quadcopter.

I'd really like to make a step with the development, but don't know where to start.
So this is my repeated request for help.
Hope someone can help me.

Best regards,

Jan Willem

[kinderkram]

Sorry that we missed your request, Jan Willem.
I see your graph for the first time and I only can say that it doesn't look good. This is surely the root of your alt hold problems. Did you check your other log files, i.e. from the static calibration?

Either the baro itself or the code is messing up there - it could even be a combination of both.
Anyway something is adding up there. In your run it obviously thinks it's higher up that it is. I guess it will still rise if you'd continue to fly.

Please perform 2 simple logs: once on the ground just letting the motors run for a while at low speed.

For the other test you need to reset the board between short runs to get 3-4 different log files. If the starting altitude is the same in all files then there's something wrong in the code.

[HeliHenkie]

Hi Norbert (and other contributers),

This morning I produced the logfiles you requested.
The first logfile is with my quadcopter on the ground and slow running motors.
A graph of [log_ukf_pres_alt] is attached.
The download link to the logfile is:

The next 4 logfiles are with my quadcopter starting on the ground, hovering for about 10-20 seconds and landing on the same sport. Two graphs of [log_ukf_pres_alt] are attached.
The download link to the logfiles are:

Hope you can help me finding the solution.

Best regards,

Jan Willem

Slow running motors on ground

Flight 1 of 4

Flight 4 of 4

[Kisssys]

Hi Jan,

I hope these screen shots might help you troubleshoot your problem, I took my quad and placed it on the ground for a few minutes and let the GPS get a 3d lock. I then plugged in my microSD card and recorded for a minute while I let it sit on the ground 5 seconds and then raise it up about 2 meters for 5 seconds. These should represent a good GPS signal and good pressure sensor response. You might also notice how over time the GPS accuracy is slowly improving.

As you see the pressure sensor sees a 2 meter change as a pretty suttle movement with some noise. It also has some drift. Its the combination of Good GPS and a pressure sensor protected from sudden air movements with something like a piece of open cell foam.

I have 2 pressure sensors, you probably only have one. I only use one so it doesn't make any difference in AQ's ability.

If these look good, then PID's and vibration can be looked at.

Cheers
Steve

[HeliHenkie]

Hi Steve and others,

Here are my plots of the logging variables [log_voltage11] and [log_adc_pressure1].

With my quad standing on the ground with slow running motors for about one and a half minute I would expect these lines to be absolutely flat. When you look at the attached images you can see falling lines. The [log_adc_pressure1] value drops from 997 hPa to 996.7 hPa, this translates to a difference in altitude of about 2.4 m. Is this what you can expect? What am I missing? It looks like there's drift in the output of my pressure sensor.
Can this be the result of a bad calibration procedure? Or ..... is something wrong with my pressure sensor?
Can someone prescribe more tests for me to conduct to eliminate my problem?

Please comment.

Best regards,

Jan Willem

[bn999]

Pressure sensed altitude is not absolute, that is why it is fused with the other sensors. The sort of drift you are seeing is to be expected. Some of it comes from changing atmospheric pressure and some comes from changes in temperature of the sensor. This drift is not the cause of your altitude hold problems.

[afernan]

I did a small test, leaving in the floor the copter recording 30 min (motors off)

Below are the plots. It can be seen a drift in pressure and altitude (2 m along 30 min). Is the temperature the reason for the drifting, as Bill said?.

If it is the case I guess it could be statically calibrated, but looking to the temperature plot, both curves (temperature and UKF_ALT) don´t show any clear relationship.

Really no idea.

[bluuu]

Pressure is not a constans value in time.

[afernan]

@bluu:

obviously pressure depends on time (due to meteorological reasons mainly) but this is not the case we are taking about. Our AQ sensor always measure same drift behaviour (altitude drop, presure grows) along time. Try it by yourself.

Angel