I’m using a PixRacer with ArduPlane 3.8 for a self-built airplane with 2 split elevons—it is basically a flying wing but with a fuselage with a (passive) elevator/horizontal tail for pitch stabilisation.
At the outer half of each wing there is a control surface, together acting as elevons. However, they are split (horizontally) so they can “open up” (top half going up, bottom half going down) to form a “Y” or “V”, producing drag and thus a yawing moment. (Side/chord view of the wing then: -----< )
Flying manually, this works marvellous: enough control authority over pitch/roll and rudder input to keep the nose pointing ahead. (The plane has little inherent yaw stability.)
In FBWA, I’ve had some issues getting the yaw stability to work, but after some tuning it flew rather well (and thus also AUTO was good). However, yesterday I had a rather disastrous flight: the plane kept yawing left and right of its own accord, without stabilising properly (FBWA). Then in AUTO, it seemed drunk: also this yawing; sometimes suddenly pitching up 50° and then (stalling and) falling sideways, then recovering. It circled waypoints (in a tight circle, as though it overshot and had to double back) before continuing to the next, et cetera.
The thing I’m struggling most with is the yaw control. Can anybody give me some pointers on how to stabilise the heading?
I have added a link to the log file, and also some plots of when the plane yawed off. What I see in those plots is for yaw: it slowly veers off from 220° to 270° while I was flying straight ahead, so almost flying sideways at the end…
In the plot of yaw I don’t see much action from the PID controller to correct this slow drift. The D of course only stabilises fast motions, and the I seems too slow… I don’t really understand the P action of the yaw controller—is this the sideslip parameter YAW2SRV_SLIP? Had that set to 0 because I thought I didn’t need “active control over sideslip”—I just want the plane to fly straight ahead.
How are the servos wired? That might help people get more information to help resolve the issue.
I’m suspecting that perhaps the wiring setup is incompatible with elevon setup in Arduplane? I’m not certain if that’s the case, Perhaps other people can chime in…
The servos are connected to channels 1/2 (left) and 4/5 (right). Functions are 1: 16 (DifferentialSpoilerLeft1), 2: 86 (DifferentialSpoilerLeft2), 4: 87 (DiffSpoilRight2), 5: 17 (DiffSpoilerRight1).
The setup is (electrically,control-wise) quite similar to http://ardupilot.org/plane/docs/differential-spoilers.html, with the notable difference that the “braking”->yawing due to differential spoiler effect is much larger, because we get full flap up and down, rather than half flap. For elevon function, they perform similar to the split elevons as shown in the differential-spoilers setup page.
I should add that in ground checks the surfaces all move in the right direction, and quick motions around yaw axis cause the right elevon to “open up” right away.
I’m thinking of 2 possible problems:
According to http://ardupilot.org/plane/docs/roll-pitch-controller-tuning.html the proportional action for yaw is actually YAW2SRV_INT, through integration of the high-pass-filtered yaw rate. Since my plane yaws rather slowly (50° in 5s or so), could this be filtered out by the HPF? (In log, PIDY shows a slowly drifting I term, not responding to 50° error. P term is 0 because this is the YAW2SRV_SLIP acting on measured lateral acceleration, which I haven’t enabled.)
As soon as the error grows larger, also roll and pitch go off. PIDs for roll/pitch/yaw all try to compensate, but full up/rudder/roll will possibly come out as only 1 flap raised, all other 3 flat. For large errors, there might not be enough control authority…
Possible solutions I’ve thought of:
Using YAW2SRV_SLIP, or making YAW2SRV_INT much higher, to correct the slow drift.
Adding a vertical tail fin for inherent/passive yaw stability… though I’d rather avoid this.
Any thoughts?
PS Haven’t been able to test these ideas, as the motor blew out in the last flight. Hot weather combined with high load due to the odd theatrics of auto mode? Something to do with Murphy, surely…
