As part of a setup test, I had my TBS Discovery hovering in Loiter mode with a storage level battery until failsafe landing. After appr. 6 minutes, the quad turned slowly around the yaw axis, like half a round. After that, I tuned it manually and let it continue until the failsafe landing kicked in.
At first, I thought it might be a compass error, but the log shows ATT.Yaw and ATT.DesYaw follows along in the yaw rotation, so the change in yaw seems “on purpose” by arducopter.
Can anyone tell me why the quad turned?
Unfortunately, the log file is to big to upload, so here goes by a share service: https://we.tl/t-rePkWA5YJf
I haven’t looked at the log but the normal cause is motor saturation. Perhaps the battery was getting low and one of the motors hit it’s upper limit. when this happens the controllers have to make a prioritisation decision and they will first give up yaw control.
If this is the cause then graphing the RCOU message should show one of the motors hitting it’s upper limit.
RCOU shows not much change in motor output at the event, other than what would normally be needed to perform a slow rotation. And the battery was not under pressure; 4 cell, steady around 14V at the time. The cells where still well balanced at the end after appr one more minutes of hovering.
Instead of looking at RCOUT, look at RCIN C4(yaw command from the radio.) At about the 5 minute mark RCIN C4 shows a slight, varying stick movement with a “negative peak” of 1444 followed by a quick return to 1493 followed by some “noise” and then a steady “flat line”.
Thanks @OldGazer, but I think the event at 5 minutes is probably just me adjusting position and heading. There are input in RCIN.C1, C2, C3 and C4.
The event that puzzles me is the one shortly after 6 minutes, where the quad slowly changes its yaw from 35 to 270 without any input from RCIN. Right after that, I manually change its yaw - in RCIN.C4 - further around until I got the same heading.
Thanks @dkemxr, but wouldn’t the MAG changes be excactly what to expect, when the quad turns? I mean, if the MAG values did NOT change, when the actual heading DID change, that could be a sign of a compass problem.
It’s a real puzzle. I plotted the inputs for Yaw control but it doesn’t shed any light on why it was commanded to Yaw.
Desired Yaw
Yaw
IMU Gyro Z
Mag (X or Y)
RCin 4
In this plot the timing indicates it starts to Yaw and everything else follows as a result. Well, your yaw input was deliberate I realize.
Desired values can be dragged around by real values. This is a safety feature that prevents large discrepancies from causing dramatic corrections. You can see from your graph that the actual yaw is leading the desired, which means this maneuver was not intended by the flight controller. This is corroborated more clearly by the rate outputs:
You have it configured as a V-frame. It looks like the motor outputs are backwards; motors 1 and 3 should produce right yaw for V and X frames, but they power down when the FC is trying to turn left, and power up when you command a yaw right. Do you have a non-standard motor assignment?
That’s an interesting observation about the Frame Class. I had a frame with geometry similar to the Discovery and I used X-frame configuration. Yaw authority wasn’t the greatest on that quad but it behaved properly.
And I assume you have the motor order as it is to suit the Omnibus F7 FC orientation and output pads? I have to do something similar with a Omni Nano V6.
Brilliant! Thanks for pointing that out. We are closing in now…
Thanks! I wasn’t aware of that. I actually at some point noted that Yaw was ahead of DesYaw, but didn’t accept the fact because I blindly assumed the opposite.
Thanks a lot, @Anubis, for your analysis. I didn’t even think of mentioning that the test was performed on a quite windy day and the quad was in a place with a lot of turbulence. So, probably the wind turned the quad little by little while the autopilot resisted but lost the fight.
I guess there must be an I-term (in a PID controller) somewhere that could be tuned to give the autopilot more yaw power.
Exactly. I switched motor order around for better wiring for a particuar orientation of the Omnibus F7 FC. I dont remember the exact pattern, but it must be clear from the parameters in the log.
Ah yes that makes sense; the motors weren’t saturated, but the attitude controller probably was. You can see from the rate graph that the FC was only requesting a maximum of -45 yaw rate. If you had PID logging enabled, we might have seen the I term maxing out at the configured value, which is ATC_RAT_YAW_IMAX
Thanks a lot. Very interesting. I will try fiddling with the IMAX parameter with PID logging. Perhaps pushing the quad on an arm to see the autopilot fight. Or maybe lower the parameter to observe the troubles it gets in the wind.
