Given that I'm planning a transition to the ESP32-WROOM-32U, I'm going to have way more memory to play with than I had before. That means I can embed calibration surfaces (see the last blog post...) directly into the probe, without having to come up with a fancy curve-fit to save memory!
This weekend, holed up in the house due to COVID-19 and grounded due to rainy and cloudy weather, I have been doing just that. The results (ongoing) live in the airball-probe-esp32 directory of our Github repo. Just one function call that does 3 table interpolations is enough to turn the three pressures, (dp0, dpa, dpb), into the three airdata parameters, (α, β, q).
The calibration tables are currently generated based on potential flow formulae, in Python. Of course a future, and better, implementation would be to derive these from wind-tunnel data. But the beauty of this is that we will have verified the entire stack, execution speed, memory usage, etc., and will just swap in some numbers in place of others.
Stay tuned for some hardware prototyping with the ESP32-WROOM-32U next!
This weekend, holed up in the house due to COVID-19 and grounded due to rainy and cloudy weather, I have been doing just that. The results (ongoing) live in the airball-probe-esp32 directory of our Github repo. Just one function call that does 3 table interpolations is enough to turn the three pressures, (dp0, dpa, dpb), into the three airdata parameters, (α, β, q).
The calibration tables are currently generated based on potential flow formulae, in Python. Of course a future, and better, implementation would be to derive these from wind-tunnel data. But the beauty of this is that we will have verified the entire stack, execution speed, memory usage, etc., and will just swap in some numbers in place of others.
Stay tuned for some hardware prototyping with the ESP32-WROOM-32U next!
No comments :
Post a Comment