PSC_ACCZ_FLTD Function

Now you see how frustrating this problem is :smiley: it’s desperation for me to try everyone elses ideas :smiley:
The term you are looking for is “prop wash” and differential pressure pulses over the Baro - None of which is the problem, Bigger slower props would present a bigger problem Sure, just like a passing thermal or air temp/pressure gradient we occasionally feel ourselves that make Quads drift up and down it’s a problem but that’s not the cause here. In calm Air I have watched the Copter just sink all the way to the ground from 8 feet
I’m happy to accept my baro is poor but a little disheartened the ALtitude controller just does not work well or respond to setting changes on these little Quads - This little Quad is a complete pain as each time I have to take the top frame off to get at the USB connection to make changes so you can imagine how much work it is :frowning:

As I mentioned, we have some other stuff to test on Arducopter which might shed some light on the issue

I see this a lot on my 2.5" quad. It’s really annoying and I haven’t figured out what the problem is. It’s not necessarily tuning - could be a driver problem. This is also the only quad I have with a DPS310

years back, I made a little 5" alt hold in Baseflight without a baro !!! just set all the weighting to ACC and it did a pretty good job :slight_smile:
The ACC is the most accurate sensor we have and we are obviously not using it enough on the ALT controller here :wink:

The Baro on that board is a BMP280. I should be able to join the party soon, with a dave_c rekon 5” & the same frame chris is using.

So maybe more people flying these little quads will help with logs etc.

Looks like it’s the GPS Causing the sinking to me. Here is the Laugh, I turned it OFF !!!

I would like to share my experiences with my 3 inch Copter (MatekH743 Mini - DPS310 baro) in tuning AltHold.

For sure with this little copters prop wash is a concern as can be seen in this plot:

To see if I was able to overcome this problem I put an external MS5611 baro in a plastic box with foam and I fixed it over the battery with a rubber band. The battery in my build is on top of the frame.

In this way I obtained the following plot:

The MS5611 is noisier then DPS310 but mounted away from the prop wash there are no more the deep minimum on the baro measurement on takeoff and landing.

One thing that I don’t understand is the rise of CTUN.DAlt and CTUN.Alt before takeoff with CTUN.BAlt remaining correctly near 0.

Here the logs:
https://drive.google.com/file/d/1kvmWMDMQJ8YOdmcC1O64-ibatXCga0qq/view?usp=sharing
https://drive.google.com/file/d/1XYDDN3MZFi5j_q9CfmXMj05Ey-fpjAp8/view?usp=sharing

Good stuff , thanks
Yes for sure we don’t baffle our baros well enough most of the time.
Arducopter is a very complex stack that seems to either work well for you out of the box or you have a big fight on your hands to get it better, Arduplane is the same and I have learnt how to make the Planes work the way to suite the stack. The same EKF and control loops do give you a smoothness in and out of GPS functions other stacks don’t, so we just have to work at it :smiley:

Looks like PSC_ACCZ_SMAX seems to reduce/stop my hover motor pulsing - now I need to understand it’s effects and how to set it correctly !!

Anyone have a clue what this means ?
PSC_ACCZ_SMAX for position control. The limit should be set to no more than 25% of the actuator’s maximum slew rate to allow for load effects

If you need SMAX then I think you have a bad tune

Interesting, yours is at the top
/home/chris/Pictures/Screenshot from 2021-05-18 13-50-54.png

No doubt, so where do I find “actuator’s maximum slew rate” ?
Any idea?

APM Planner doesn’t distinguish among different instance of sensor in Graph section.

What are you plotting from my log is a combination of the two baro in a single plot.

If you want to see the value of each baro you have to use MP or MAVExplorer.py

Ah, ok :slight_smile:

@Leonardthall sorry, respect to my post above with two plot relative to two baros, I would like to have, if possible, a comment on this:

@anbello

I had a quick look at your log and a picture is below.

The EKF altitude is a blend of barometer and accelerometer so the EKF altitude estimate is often different from the barometer. In this log we see the EKF altitude estimate is climbing from zero after arming but before takeoff, this is probably because the EKF is still learning the accelerometer bias which can change over time and also depending upon the temperature of the IMU.

Another reason the EKF estimate is different from the barometer is the barometer has a relatively long lag (about 0.2 seconds) and is quite noisy so the EKF’s estimate is first based on the accelerometers and then the baro altitude more gently pulls the estimate in one direction or another.

Hope that helps.

1 Like

Thanks @rmackay9 I understood your explanation. Do you think that this could explain also the fact that EKF alt estimate, desired alt and baro alt become close only after a while and only after this I have a stable AltHold? I attach a plot to visualize this.

With other Copter I built I don’t have this “problem” and I have stable AltHold right after takeoff.

1 Like

Logs, 89 and 92 should have fast logging, maybe you can see something?
Thanks
https://mega.nz/folder/2Y4m0RJT#7tb4sWLjWUmcWB1rPHqoCQ

Interesting :slight_smile:

1 Like

@anbello,

Yes, it takes some time for EKF’s altitude estimate to stabilize so this is what you’re seeing. If it was just sitting on the ground a little longer before takeoff then I think they would be together right from the start of the log.

It’s a guess but you could try re-doing the accelerometer calibration but I suspect it is mostly the IMU temperature that is the issue.

1 Like