Not sure if you’ve looked at my existing script, above, but it simply asks for pilot input to build speed and decelerate after making a reasonable attempt to align the measurement direction with the wind using guided mode. I don’t know that using a circle would really help that much except with wind estimation via a different means.
So I just watched back the section of the video that goes over how to verify that the calculated value for momentum drag is correct and it seems like we may be able to do something similar to magfit to calculate this value post-flight.
The steps for calculating the momentum drag coeff would be as follows:
- Enable log_replay with correct data being logged (see video)
- Simple flight in alt hold where you start in hover and allow the aircraft to drift with the wind until its flight speed stabilizes (the longer this flight is the better).
- Iterate through values for motor drag coeff (0 to 1) and replay the log to see if estimated wind prediction matches steady state velocity of aircraft in wind.
This doesn’t use circle mode or anything and still all occurs in alt-hold mode - but I think would result in a simpler flight requirement?
That’s almost too easy and would require far less space to accomplish in flight!
Also excellent that it would work for vehicles without scripting enabled/available.
Probably would like @priseborough to review if this idea even has a chance of working before we dive into this.
1 Like
When it comes to the baro compensation parameters (if we get to scripting those as well) - afaik we are going to have to do some sort of auto back and forth mission where the distance is long enough for the aircraft to gain decent airspeed (probably target an airspeed difference of at least 10 m/s from hover).
1 Like
Was the idea with circle mode to reduce the amount of space required for this - or to just make the flight more “controlled” and “predictable” in its nature?
Both, really. It would be irresponsible to actually script a max speed run into the wind, hence my design to use pilot input with the ability to cancel out at any time.
I understand.
I need to dive further into how these parameters actually result in the ability to get wind speed/direction in real-time. I don’t really understand that part - so maybe there is another way to get wind speed and direction that doesn’t require us to compute drag and whatnot.
For what its worth. I think we can do baro compensation tuning without an airspeed estimate (just using ground speed). It definitely won’t be as accurate - but should be a lot better than having no compensation at all. So maybe its worth having this as a middle ground for most users? The baro comp flight data recording is pretty straight forward and we can use circle mode since we don’t care about airspeed.
2 Likes
Definitely a worthwhile venture to capture the needs of most users with the least pain involved.
I don’t know how to capture a synthetic airspeed without knowing physical attributes of the vehicle. And
I think that’s crucial to computing wind, especially in a stable hover. It’s easy when there’s a pitot/static system!
Yup thats the main thing here. All this data collection for drag and whatnot is so that we can get a synthetic airspeed - which is the complicated part. If we simply just use ground speed for baro comp we can probably get a result that is suitable for most flights - but obviously not the best.
Should we start with the simpler task here and start scripting the flight that gets baro compensation? I believe airspeed == groundspeed if you don’t have any wind estimation enabled - so we can just use airspeed estimates for all users (which would actually be using ground speed data for those who haven’t setup wind estimation yet).
1 Like
I’m not opposed to that approach at all. We already essentially demand a calm day for autotune. This would just be an element of that (in a way).
True airspeed equals ground speed when wind velocity is zero. It gets a little more complex if we were to try and back indicated/equivalent airspeeds out of it, but that is likely wholly unnecessary for this case.
1 Like
Theoretically this should work on windy days too - so long that the wind speed/direction is constant.
2 Likes
I should clarify that more - so long that the wind speed/direction is constant relative to the aircraft’s direction of motion. Thus, circle mode wouldn’t work great for this because the actual airspeed of the aircraft would be constantly changing (unless, like you said, we required a calm day).
1 Like
A back and forth auto mission of sufficient distance to build speed should work well - and likely make scripted log analysis a bit easier.
True - we just would only be “tuning” on half of that path. For example, only on the front to back path and not on the back to front path.
We shouldn’t need to do any log analysis for this and can probably do all the tuning in real time. The main thing would be that you keep comparing GPS altitude and barometer altitude until they roughly line up with each other.
One thing to note is that I don’t really know what the code backend does if you enter baro comp parameters without having the drag parameters for wind speed estimate inputted.
If 0 disables - might have to run with 0.00001 for now 
1 Like
I have good drag coefficients for my test copter of choice but can zero them and see what happens with baro comp. Wouldn’t be hard to look up the source, either.
However…I need to replace the ESC (hopefully this week).
Completely grasp the iterative approach for this - I was thinking we might get a little “fancier” with log analysis…but why?!
I don’t want to drive this topic too off-hand but…
If all baro compensation currently does is compare the barometer reported altitude to the GPS reported altitude and applies a static error correction based off of vehicle airspeed - wouldn’t this mean we should just be weighting GPS more when controlling altitude? Obv this wouldn’t work if you don’t have a GPS - but baro comp already doesn’t work if that is the case.