The problem right now is I’m not sure what the paramaters from log really means and would like to confirm my understanding.
As example I made some short flights in Althold, first:
I think GPS[0].lng is clear, just the raw position from GPS messages
Now what’s AHR2.lng? It’s basically same as GPS[0].lng but after some kind of simple filters? What’s doing anyway for autopilot?
For POS.lng I think it’s probably the actual (final) position after all estimators. That’s correct?
This looks really inadequate. This was after trying ublox navigation output filters. But then it seems GPS will send messages in a sparse way, causing GPS glitches and speed variance messages, and estimated position is screwed (if POS.lng really means the final estimated position). Probably not respecting minimal 5Hz for GPS_RATE_MS. Just guessing things here.
My current thinking is: I don’t use RTK and not even able to use SBAS. The practical accuracy for GPS will never be better than <2m in best operational conditions. Why do I need loiter mode trying to fix drone in the cm scale? I don’t need it. So it looked like a good idea to configure navigation output filters for this reallity and expected autopilot to cope (or ‘dilute’ the variances in larger steps) with this but it doesn’t happen.
I think it’s worth adding: Some days ago testing pushing hard output filters like,
piloting in loiter mode, after I realease radio sticks the drone makes a huge straight backward movement (like 10m) and then starts a huge and permanent toilet bowling movent in a near perfect circle (of about 5m radius).
By the other hand now I understand this may be not a trivial thing to fix, having loiter more stable (without fast/agressive twitches in cm scale) considering how autopilot works.
As per that other thread did you complete tuning first before worrying about how well Loiter is holding position?
In the log I looked at there was still some default and tuning work to be done.
Yeah did that already. Actually set to zero. Setting this one (and using extreme values) was a test to see what happens. I think it produce clues that helps me understanding how things works. Did some tests also using low values (like 0.01). I think that my idea is getting the right value that produce outputs where GPS minor wandering (produced by position errors) is filtered out and not conflicting with innertial sensors output at the same time. For now I’m not sure if this makes sense and leaving it to zero until I can sort out other problems and have a better understanding of all things.
I’m really not sure. Ardupilot is quite a huge tunning universe. I’m trying to follow steps from wiki. Initial setup, althold, then autotune, then notch filters. Autotune produced quite agressive results but it works anyway. But agressive for the things I want to do. So I adjusted “Basic tunning” in mission planner to lower values and also lowered Error to Rate for roll and pitch, Autotune produces values >20 for these, I changhed to 12 while testing the drone.
It’s really enjoying to fly it in althold. It does well mission WP and RTL, doing the tasks as expected. I must test it more to confirm this but for now what I see is when satcount >11 (or so), loiter is just fine. When satcount is less drone keeps twitching nervously. For GPS part I’m not sure if I can get it better in practice. My etrex32 seems to agree with drone GPS about the number of “green” sats being used. I think GPS module LNA + patch antenna is a bomb mix for multipath probably. Want to move to alternative LNA + helical antenna, but that’s something for the future.
OK good, I know it’s a big task to get through setup and tuning.
I’m hoping this helps
The GPS signal quality and it’s resulting position feed into the Position Controller in GPS-assisted modes like Loiter.
If the GPS position is wandering, it can appear as (almost) oscillations in Loiter as the position is trying to shift quite frequently and the copter is chasing it.
These are the parameters you would look to for control of how loosely or tight the position controller tries to stick with the GPS position. So if you often have a wandering GPS position you would halve the default values, which is usually enough to settle the copter
or if you fix your GPS issues they can go back to defaults - double the values shown here.
Relaxing those params doesnt mean you are not where you are meant to be, just that the wandering position is not strictly followed as tightly.
Do continue to use Loiter, it’s so much more configurable than PosHold. When you want to get moving AltHold is more like Stabilise.
It might be handy for us to see a log where you are experiencing the
It sure helps as it confirms my understanding about the root cause and points to the right parameters to be tested!
Not sure I was clear enough but that behaviour occurred while testing the high value for Ublox Static Hold Threshold filter in GPS. I will take a look but not sure if I have that log anymore. I can repeat this test If I can’t find the log and If you’re interested, or think it can be useful (for whatever reason). I like it!
