Advice requested for improving altitude hold using baro for indoor flights

Hello,

I have a small build flying indoors with baro and optical flow / lidar. I have been trying to dial in barometer for ALTH when lidar will be unreliable due to cluttered floors. Some of the parameters I have been changing are based on the recommendations here: Extended Kalman Filter Navigation Overview and Tuning — Dev documentation

I am noticing though that as the baro temp reading settles to a consistent temp, the vehicle is able to hold altitude much more reliably. Until then though, the vehicle ascends and descends while the desired altitude remains constant.

That screenshot is from the most recent flight, where I tried to hold altitude in a narrow hallway, approximately 1m wide. I realize that is a tough situation for any build, however, that is a common environment I am expected to be flying. Flying in stabilize mode is fine, but for certain situations, having altitude hold work consistently is the goal.

Nevertheless, the result is similar in open space, where the temperature needs to settle before having reliable altitude. When I say reliable, I will be happy with +/- 0.3 meter variance which is about what I achieved in that narrow hallway. Switching to Loiter was coincidentally aligned with temperature settling and more so I didn’t have to continually correct XY position in a confined space.

Log

I watched Andy Piper’s Pavo20 videos on this but his settings were not helpful for me. Any thoughts on this topic or how to improve are much appreciated, specifically if there is a way to handle temperature values until they settle.

Thank you

you might have better luck with a sonar, they work well over flat surfaces.

I appreciate the comment, though I mentioned in my post that I am wanting a reliable baro when the floor is cluttered. Sonar and lidar are only reliable with flat surfaces. As soon as sonar or lidar encounter objects under the vehicle, the vehicle will rise to maintain the desired altitude. That is behavior even with surface tracking disabled.

Usually, the cause of this is a cheap barometer, which usually have jitter. It can also be caused by having too little damping on the barometer (like a foam).

I’d say you can try to put some foam on it, if not present yet. Else, you can try a better barometer externally.

Not really aware of the best barometers, but I think the ms5611 is a great choice, provided you are able to find a real one, and not the cheaper ma5607 ( often marketed as ms5611)

The problem with barometers indoors is the pressure isn’t stable, so it will start going up and down as pressure changes with the wind or open doors

Unfortunately the baro temp calibration was designed to fix a different problem. What we really need is an equivalent fix for baro as we now have for IMUs

A small amount of jitter is acceptable. I do have foam over the baro. What I’m describing in my post is the temperature variable. Once the board/vtx temperatures settle, the baro holds pretty well.

I am aware of this. The post is really trying to address temperature from the board.

The baro doesnot jitter. It just outputs a noisy signal.

The noise is caused by doors, windows, prop wash and termal noise.
They are all noise . None is jitter

3 Likes

Right. And I’ve set EK3_ALT_M_NSE according to the data from my flights. A value of 0.75 seems to be about right based on what I’m seeing.

And maybe I am mistaken… what I am seeing from EKF4[0].SH shows that I am getting good sensor data.

what about tracking the ceiling rather than the floor?

@geofrancis I appreciate your comments and suggestions, I’d like to stay on topic though… barometer.

But, to answer your question. Yes, I have given thought to ceiling tracking. A lot of thought actually. However, ceiling tracking assumes ceilings are flat through a structure, which is not the case. Ceilings can also have clutter, from fans and light fixtures to lower clearance through doorways.

@andyp1per Just out of curiosity, what does an equivalent fix for baro look like? I just quickly glanced at the code in AP_Baro_SPL06.cpp and it appears that ArduPilot is using the coefficient registers. What else do you think can/should be done?

The problem with the barometer indoors is that it’s only going to be as accurate as the air pressure it can read, and the pressure in a building can change a lot. the aircraft will struggle to hold altitude as it will try and stay in the same pressure air, if the pressure goes up it will climb, if it drops it will descend.

Every gust of wind, every door opening will cause large variations. even just hovering in the room will cause a large vortex to form, causing the aircraft to get pushed into the ground or climb.

@geofrancis I am well aware of problems with barometers. Let’s just say that I fly indoors a lot. I am well aware that pressure changes happen frequently. Your posts in this thread really are not helpful towards advancing the capabilities and reliability of baro indoors. Just because there are variables does not mean there are no solutions. I am aware of alternatives - and yet your alternatives are no better than using a baro indoors.

Every gust of wind, every door opening will cause large variations. even just hovering in the room will cause a large vortex to form, causing the aircraft to get pushed into the ground or climb.

By simply setting a few parameters, I was able to maintain altitude with +/- 0.5m variance in a hallway about 1 meter wide. Look at the data I posted. You want to talk about gust of winds or hovering in rooms… it was very windy in that hallway.

The baro uses a single value which is not enough to get a good curve fit.