iNavFlight
Wind Speed Estimator for Multicopters
Current Behavior
The wind speed estimator in iNav doesn't work for Multicopters
Desired Behavior
A horizontal and vertical wind speed estimator
Suggested Solution
It's been specified before that this is not possible for multicopters, e.g. https://github.com/iNavFlight/inav/discussions/6718 However, ardupilot has the facility, and this is how it was implemented: https://ardupilot.org/copter/docs/airspeed-estimation.html Nobody expects wind speed estimation to be perfect. Certain flight modes and stick positions would enable this to be calculated, e.g. POSHOLD or ANGLE with neutral stick positions if a simple approach to it was implemented.
Who does this impact? Who is this for?
Multicopter users, high altitude and long-distance flying. Wind can vary in direction and strength with altitude, and having an idea of these conditions can impact flight times. For example, a flight from A->B->A where A->B has a 40km/h tail wind, the user flies to 50% battery, and then on the B->A flight, they then have a 40km/h head wind and don't have enough capacity to return to A. Having some idea of wind speed would assist the user greatly in determining flight time and result in fewer models lost. A vertical wind speed estimator would assist with the detection of thermals, updrafts, slope lift (whilst flying near mountains/hills) etc.
Additional context
Currently working on a severe weather research project, and this information would be invaluable to major decisions during flight.
INAV doesn't use an EKF for position estimations.
I was working with a guy last year, who modified AP's EKF for INAV use... It worked a bit better than INAV's Kalman and Complementary filters, WHEN the sensor data was poorer. But it placed extremely high processing loads on some flight controllers. Which in-turn required a very low looptime to be ran. With that leading to its own problems for certain aspects of INAV copter performance. So it wasn't implemented, because the advantage didn't really out-weigh the loss, for the type of flight INAV is primarily designed for. (hobby use)
I looked over the way AP estimates wind data for copters... It may work. But it's far from user friendly in its setup. Not at all Plug'n'Play like fixedwing wind estimation.
If you're interested to try. I've found NAV's horizontal wind direction indicator seems to work reasonably well for copter use. It just leaves the wind speed field as zero. I had virtual pitot enabled, which may or may not have been required.
I'd have thought a crude form of wind measurement for a multirotor would just involve letting it hover in Angle. The ground drift should be equal to the wind speed and direction.
I'd have thought a crude form of wind measurement for a multirotor would just involve letting it hover in Angle. The ground drift should be equal to the wind speed and direction.
@breadoven I guess a simple and crude method, if based on reasonable logic, may work okay for INAV support. I also thought about wind heading calculation presently used by the FW wind estimator being applied when the copter is in a navigation mode, travel at a consistent and known Bank angle, Throttle and Ground speed. And that being compared as heading changes are made, over a time period and limited distance.. Because it's even possible for a user to look at the change in ground speed when heading into or with the wind. And calculate from the OSD,; the wind and airspeed with those fixed variables in a WP mission.
When looking at all the parameters AP uses, and the scripts they need for tuning the specific of each model. It makes me wonder how well their system would work for smaller copters like INAV supports.
Yes, Angle approach (with sticks centered) and taking a value whenever that happens would be one approach. Also in Pos Hold mode, monitoring for motor imbalance would be another approach. Also, a position estimator based on tilt maybe an approach too. For example, in Pos Hold mode, the drone will tilt in wind. The amount of tilt and orientation of it compare to the heading will give direction and wind speed with minimal calibration.
The simplest method to calculate approximate wind speed for a quad in motion, is to use bank angle and ground speed.
Fly on a day when there's no wind. with feature THR_VBAT_COMP on by default.
It would require a MC wind tuning mode that maps the ground speed changes at all bank angles up to nav_mc_bank_angle, as you fly around.
The tuning estimator would be required to hold each angle for a time, to provide an accurate ground speed reference for each degree of bank angle increase.
They would be stored for a reference of the quads thrust to drag ratio.
This will provide a base line which can be used to calculate the wind speed. Example: If the quads thrust and drag will only allow it to reach 60km/h with a bank angle of 30° with no wind. Once the wind estimator is tuned. You may see a 50km/h ground speed at that same bank angle. This calculates out as a 10km/h headwind. And the opposite for a tailwind.
I don't see the point of estimating the wind speed and direction when hovering. It has little benefit in improving flight efficiency or safety. It's when traversing distances, it's useful for the pilot or the navigation system to know if you have a headwind, or are approaching a position target too quickly with a tailwind.
I don't see the point of estimating the wind speed and direction when hovering.
Its main point is it's very simple to do and is better than nothing.
Estimating wind speed via bank angle is obviously the better way but much more complicated to do given it requires calibrating the multirotor drag characteristic as you describe.
In ArduPilot, they estimate the drag coefficient by using the mass / estimated area: https://ardupilot.org/copter/docs/airspeed-estimation.html, which could be used for the more complicated method. I think both are good solutions.
It would require a MC wind tuning mode that maps the ground speed changes at all bank angles up to nav_mc_bank_angle, as you fly around. The tuning estimator would be required to hold each angle for a time, to provide an accurate ground speed reference for each degree of bank angle increase. They would be stored for a reference of the quads thrust to drag ratio.
Okay, so the calibration mode would do some specific bank angles. "Hold each angle for a time" - we then have to ask WHICH bank angles it should use for this calibration. This next bit gives some insight:
Example: If the quads thrust and drag will only allow it to reach 60km/h with a bank angle of 30° with no wind. Once the wind estimator is tuned. You may see a 50km/h ground speed at that same bank angle. This calculates out as a 10km/h headwind. And the opposite for a tailwind.
At a high bank angle, the wind if is of course a smaller percentage of the total speed. The main factors are the thrust and drag, so we would need to measure this very accurately in order to get any useful result at high bank angles.
At low bank angles, the wind is a larger factor. So our calibration would have best signal to noise ratio at the lowest possible bank angle.
So the optimal bank angle for wind calibration mode is 0°, which measures the wind directly.
I don't see the point of estimating the wind speed and direction when hovering
If you're going to "hold each bank angle for a time", the optimal angle to hold is 0°. The wind speed doesn't change depending on whether you hold 0° or hold 45°. But the noise in the data sure changes!
As an extra side-benefit, in the formula the drag coefficient is multiplied by the horizontal component of the angle. As the horizontal component reaches zero, the drag component is multiplied by zero, so it drops out of the equation entirely. Meaning you can calculate the wind speed without doing any of the drag coefficient stuff! 😃
@sensei-hacker I did say simple. ;-)
I've read the Ardupilot paper which describes the math and physics based model. And have use the Arducopter wind estimator. I can tell you now, it isn't perfect either! And I very much doubt INAV's inertial navigation system is of the same level as Ardupilots EKF3.
I was simply inferring the way iNAV’s uses pitch bank angle, together with nav_mc-hover_thr to hold altitude when navigating.
The percentage of auto throttle used on-top of nav_mc-hover_thr, for forward flight is applied according to nav_mc_bank_angle.
INAV doesn’t appear to use an active throttle control to reach its ground speed target. It simply allows speed run-out, based on how much throttle is required to hold altitude at a given bank angle. It's that remainder which drives the quad across the ground, until forward speed is overcome by drag.
The forward ground speed achieved for a given quad, with its own specific thrust to drag ratio, will vary a little based on air density. With feature THR_VBAT_COMP doing its part.
But on a windless day. The ground speed a specific quad can achieve at a given pitch bank angle is mostly constant, according to its thrust to drag ratio.
The derived tuning table I referred to in my last post, would have ground speed values relative to requirements of that quad only.
NO WIND :
Bank angle - Max. ground speed run-out
5° - 7 km/h
10° - 14 km/h
15° - 24 km/h
20° - 32 km/h
25° - 48 km/h
30° - 59 km/h
35° - 68 km/h
The differences between these values, and the loss or gain caused by the wind, can be used to calculate air speed when the quad is traveling in forward flight.
If you wonder how I know it works. I use it with the programming framework and custom OSD. With a table derived from each of my individual quads. It isn't perfect. But when comparing to a fixedwing flying next to me using the virtual pitot. The airspeed was only a couple of km/h average difference, in all 4 directions.
If you wonder how I know it works. I use it with the programming framework and custom OSD. With a table derived from each of my individual quads. It isn't perfect.
@rts18 Would it be possible to provide the code changes to do this?
Would it be possible to provide the code changes to do this?
This wasn't done in C.code. I used the PLC framework. You'd need to ask one of the development team who replied in this feature request, if they think the concept is up to their standard. It would require the addition of an air speed tuning mode, for easy data extraction of the reference table.