Actually wouldn't worry about the motor speed at any given moment since it's always compensating using either the accelerometer (if in angle or horizon mode) or using the gyro (if in "acro" mode, really just no mode selected in BF modes, acro is default).
If it seems it's always compensating too much with one set of motors or another when in angle or horizon mode then the accelerometer probably needs calibrating. If it is drifting in acro mode that is somewhat expected, in either case you'll have to do some throttle management to keep it from flying up too high or down too low but eventually you can get the throttle fairly well "locked" by adjusting your rates to some degree making it easier to find the "correct" position to have a solid hover that said like you indicated using sensors is ultimately/ideally the best way to get the quad to really lock it's altitude.
All that said, as far as I know Betaflight only supports return to home type functionality with GPS/compass currently (and I think really relies on the GPS and might just ignore the compass). Basically the configuration for this will block you from taking off without GPS lock (by default can be overridden) and if you have GPS lock before arming/take off then if you enable Return to Home as a failsafe and/or make a switch/mode activate Return to Home (RTH) activate at which point the quad flies up to a preset height (or max height seen during flight) and returns to the home position and attempts to bring itself near the ground (lowers throttle to some set percentage).
Peering under the hood on BF firmware can see what sensors are "supported" or at least there is some code for:
Open Source Flight Controller Firmware. Contribute to betaflight/betaflight development by creating an account on GitHub.
github.com
Open Source Flight Controller Firmware. Contribute to betaflight/betaflight development by creating an account on GitHub.
github.com
Regarding features supported using those sensors though again I don't think there's a ton of that in betaflight itself.
What you want is broadly called "altitude hold" or "GPS hold" in the iNav world from the little I've dipped into that. Many modern FCs that support Betaflight I think can also support iNav so long as someone has taken the time to setup the "resource mapping" basically telling betaflight which pins on the MCU go to what things on the PCB (or pin holes). Long story short though you might have more luck using more advanced sensor features on a DIY thing if using iNav firmware.
Also I have played with a few of those ping sensors.
Tap to view!
photos.app.goo.gl
They come in a few varieties the one you have there I think uses one "can" as an ultrasonic speaker and the other "can" as a receiver/mic. They would probably work pretty well for this application (not good under a foot but get pretty accurate readings from 1ft to about 10ft) although I'm not sure how much vibration dampening you'd need to do to avoid getting bad data from the sensors (in general filtering of junk data is just something you have to do but being on a flying vibrating thing makes it harder than usual). For the "PING" style sensors you have basically power to them then a bidirectional data line that is used for first telling the PING sensor to send out/measure a ping time then that data is sent down the same line back to the MCU that asked it to ping something (by raising the line high or low I forget)... some code/sample here is clearer than my explanation
Detect objects with an ultrasonic range finder.
www.arduino.cc
There are other ones that are "simpler" you can see dangling on the left and right of my bot above. The "simpler" ones will just ping so long as they have power going to them and will output an analog signal which you can use an analog to digital converter (in Arduino world analogRead() function does this pretty sure) to "read" the distance and then translate that into some actual distance value (calibrate using a measuring stick or known distance and do some map() call in Arduino again).
All of the BF code is targeting STM32/ARM chips whereas Arduino is AVR architecture and much slower in general so not all of my knowledge of Arduino things is directly portable but it's all C code so I can at least understand BF unfortunately haven't gotten to the point of building my own custom firmwares yet though :| maybe one day
