Jitter on RCOUT signal in FBWA mode with no GPS fix

Archive
1

Hey all,

noticing a very weird situation in my plane running 3.2.1 (also tried some earlier firmware versions up to 2.78 and noticed similar behaviour). My setup is a plane running on a Pixhawk with a Mediatek GPS connected.

Observations:

-When flight mode is MANUAL nothing weird happens, servos respond as expected (no input, no output).

-When flight mode is FBWA something weird happens, the servos start jittering, and when I look in the logs (see attached image) I see that there is still no RC input for both channels, but a RC output is generated.

-The moment the GPS receives a fix the jitter on the RC output disappears.

Image of logged data:
See attachment. A description of what you see is:

Legend: red = RC input, green = RC output, blue = GPS_STATUS

In the part in the graph from 0 to 20.000 the plane is indoors, lying on a table. It does the jitter, as I described before. It becomes worse when I give some input on my RC transmitter (from 12.000 to 18.000 in the graph).
The GPS (blue line) has NO FIX. The plane is in FLY BY WIRE A the entire time.

In the part in the graph around 22.000 I move the plane outdoors (so there’s some small movement there).

Now, from approximately 24.000 and on the GPS has a fix. The jitter is gone.
Even when I again try to give an input with my RC transmitter (this time between 29.000 and 34.000) there is NO jitter.

Troubleshooting steps:

I have verified the following things:

-Reverted back to earlier versions of Arduplane up and until 2.78. Saw similar behaviour.

-Disconnecting and disabling (setting GPS_TYPE to 0) the GPS does not solve the issues strangely. The RC_OUT jitter also appears then.

-The jitter increases when the servo output increases, as seen in the image when I demand a change in angle using my transmitter.

-The moment the GPS_STATUS changes to FIX the jitter instantly disappears.

Attempt for a solution:

-I have dived into the code and searched for possible explanations. However, so far I have been unable to find a link between the RC_OUTPUT in Fly By Wire A mode and the GPS_STATUS. I will continue to work down from the signal send to the servos to the RC_INPUT until I find the point where the jitter is added, however since this is obviously tedious work this could take some time. Therefore I hope this is something people have seen before. Might it be some controller instability induced by bad parameter choice (I don’t expect it is, since I don’t believe GPS_Status influences controller gains and parameters, but I don’t want to exclude anything at this point). Is it noise?

Hoping we can figure this out together!

Thanks.

2

Hi,
This comes up a fair bit, so I’ve added a FAQ entry for it:
plane.ardupilot.com/wiki/fixed-w … the_ground
note that I don’t recommend you keep using the Mediatek GPS. In some testing I’ve done it gives poor and quite laggy velocity data. I’ve seen quite a few crash logs that can be attributed directly to very poor sensor data from a Mediatek GPS.
Cheers, Tridge

3

Dear tridge,
thanks for the response. However, I do have some questions. If the cause is a bad attitude estimation, wouldn’t I then see that same jitter in the attitude data in the log file? Secondly, since my plane has no air speed sensor, I would, based on the logic that the attitude estimation errors are created by bad sensor input, expect that the jitter would not occur when the GPS is disabled, since in that case there is no sensor input other than the IMU data. So why would this change when the GPS reaches a 3DFix?

edit: The proposed solution, enabling the extended Kalman filter, also has not reduced any of the jitter. So I don’t know if this is the ‘generic’ jitter as described in the FAQ, unfortunately.

Thanks for the response

4

If you can upload a dataflash log of the issue then I can see if I can reproduce it with replay and work out the specific cause for your system.
Please get a log with LOG_BITMASK set to 131071. That will enable logging when disarmed, which will capture the startup. Grab the log off the microSD card (a .bin file)
Cheers, Tridge

5

I have figured out what causes the jitter. It is the parameter THR_MIN. On plane.ardupilot.com/wiki/arduplane-parameters/ the parameter is described as: “The minimum throttle setting which the autopilot will apply.”

However, in the Mission Planner, the description is: “The minimum throttle setting to which the autopilot will apply.”.

So my follow up question now would be: what does the THR_MIN parameter do? I read it as, the moment the autopilot takes control over the throttle, it will never apply a throttle lower than THR_MIN%. How the description in the Mission Planner describes it however is that it will never apply the autopilot below THR_MIN%, which obviously is a significant difference (interesting how one word can change the meaning of an entire sentence this drastically). One that could also sort of explain the jittering behaviour.

Some observations that I still made with regards to playing with the parameter:

-If I set it to 50%, if I increase throttle to over 50% the jitter seems to disappear (though its hard to judge since the motors still generate some motion that could cause the plane to slightly move, but it seems to disappear).
-If I set it to 50% and give 0 throttle, and then using the Mission Planner gently lower the THR_MIN percentage by increments of 10, the jitter becomes smaller every increment even though the throttle remains at zero. This seems to imply that it is not a ‘hard boundary’ that is set by THR_MIN in that case, since the difference between THR_MIN and the actual throttle seems to influence the amount of jitter.

I could still provide a log but at this point I don’t think its still usefull seeing how I’ve managed to work it down to this parameter. If you would still like a log let me know and I can easily provide you with one.

Thanks.