Chinook dual-rotor ‘copter
The Chinook helicopter has two sets of rotors which rotate in the same direction, leading to 0 yaw. A quadcopter takes the same approach – diagonally opposite blades rotate in the same direction, so both pairs result in 0 yaw.
So how does my bloomin’ quadcopter have yaw problems? I’m bringing this up again as it was a problem in the PID testing; during the first few tests, although the 2 motors started at full hover speed, they slowed down dramatically during the test.
The cause was the yaw PID which I’d forgotten to take out, and once I did, the tests ran consistently at hover speed.
Yet physically there was not yaw to correct – only one diagonal pair of motors was operating and due to the step-ladder, there was no way the quad could rotate around its z axis. And that suggests the yaw sensor is seriously duff.
Next time she’s flying outside, I think I’ll set the yaw rate PID gains to 0 and see what happens – something must have suggested to me I needed them in the first place?
First step on tracking down the yaw problems is to check that all the blades are spinning in the right direction and at the same speed for a given PWM pulse width. So I added it little test to the code to step through each motor in turn, spinning them up to well under take-off speed. I started off with 10% and one motor did sound a little underpowered, but once I’d upped this to 20%, all motors were humming the same tune. They were also all spinning in the correct direction (CW or CCW) for their given location, and they are all using the same props, and were all blowing air downwards, so I really struggle to see how the yaw can be caused by any of these parts. Hmmm – I think I’ll have to put this on the back-burner until I come up with another great idea.
I managed to squeeze in 10 or 12 test flights (3s take-off, 3s hover, 3s land). Phoebe’s new legs are holding up beautifully – nutlock + a multitude of washers has definitely given her extra strength.
I’m convinced now I have my anti-drift / non-flat ground take-off code right – just the fact I made so many flights without damage means things are heading in the right direction, but they also raised several issues.
- DLPF vs tau – low Digital Low Pass Filter (5Hz) gives stable take-off from vertical speed PID, but gives inaccurate angles due to valid data being filtered out. Upping DLPF to 20 or 40Hz lets in more accelerometer accuracy but also noise, leading to bumpier take-offs and a need for the complementary filter for angle accuracy to be upped from 10Hz to 5Hz to keep the noise out of the angles. Hmmm, not sure what to do here yet if anything.
- YAW is still plaguing power distribution – the anti-YAW pid is working well, but it’s clear on landing that one pair of blades (front right and back-left I think) are spinning very much faster than the other pair to suppress the yaw. All the blades are new, well balanced, and attached firmly to their motors, so perhaps I have a duff-motor. Hmmm, I wonder which one?
- Intermediate PID tuning – horizontal speed P-gain at between 0.25 and 0.3 is having the right effect, but is sluggish. I suspect the problem is I need to tweak the PID gains of the angle PID to make sure we get higher angular acceleration targets for faster self correction.
YAW is the priority – the whole point of setting up the quadcopter with different spin direction is to suppress yaw so I shouldn’t have to be dealing with it, and yet it’s the dominant factor now, smothering some of the more subtle motor spin PIDs’ effects.
After YAW, the DLPF / complementary filter conflict comes next – essentially we want the highest DLPF frequency and also the highest complementary filter frequency. To make that work, noise needs to be removed from the system. I’ve already got rubber standoffs supporting the sensor breadboard, but now I’ve also removed all PID D-gains – they provide super fast reaction to problems but at the expense of noise – fast reaction = fast acceleration = noise that registers as the DLPF frequency is increased. We shall see (hopefully) tomorrow the effect this has.
3 more test flights today with the new legs / landing skids.
The PID tuning has pretty much sorted out the take-off yaw, so now stayed facing the fence as she drifted backwards diagonally due to the breeze. She managed to cover nearly 10 meters risking hitting the house (kill switch necessary) in one of the flights, and a wendy house in another (again kill switch used). In the final flight, it was the kid’s slide and swings at risk – again kill switch.
This time, I had Phoebe’s video running to track the flights – here’s probably the best one clearly showing reverse rather than diagonal flight – Phoebe’s view remains pointing at the fence, just drifting away from it. The video is very short as her kill switch (Ctrl-C in ssh) kills the video as it’s a child process, whereas Phoebe catches it, and uses it as a trigger to move to the next phase – in this case from hovering to landing.
Phoebe’s YAW free flight from Andy Baker on Vimeo.
As always, I have stats to analyse also showing her take-off, and hovering – the blue (height) line is better – it shows no slow height oscillations due to the vertical PID integral, but I may have to tweak an internal constant to stop that drop….
Vertical accleration, speed and height stats
…and also the movement in the x and y directions, primarily backwards but with some drift to the left – I’m hoping this was primarily due to the wind as I’m hoping to move to a new test site (the garage), but before I do, I really need to kill any none-wind driven drifting as there’s too many hard things in the garage for Phoebe to hurt herself with!
Horizontal drift stats
Phoebe, yaw free, fly free! from Andy Baker on Vimeo.
Smooth takeoff, yaw free flight (PID tuning worked), drifting backwards due to not quite vertical takeoff, bouncy landing, all videoed by Phoebe’s own PiCam! I’m bloomin’ delighted!
Yeah, so there’s plenty of work left to do, but for now, I’m going to enjoy the moment knowing I can now trust her for more exciting test flights!
Keep Calm and Carry On
The short version: not only can I not remember my left from my right, it seems clockwise and anti / counter-clockwise trouble me too leading to a couple of unexpected crashes this morning during my yaw tuning. But finally I think I’ve got it right. Here’s the correct comment from my code controlling yaw:
# Over enthusiastic CW rotation of the front-right and back-left
# (FR & BL) blades results in an ACW rotation of the quadcopter
# body. The z gyro produces a positive output as a result. This then
# leads to the PID error (target - gyro) being negative, meaning PID
# output is negative (assuming positive gains). Since the PID output
# needs to reduce the over-enthusiastic CW rotation of the FR & BL
# blades, the PID output needs to be added to those blades (thus slowing
# their rotation) and subtracted from the ACW FL & BR blades (thus
# speeding them up) to compensate for the yaw.
The long version is that I did some additional yaw and take-off testing this morning – I did two flights with calamitous results: the first flight few as high as the trampoline top and then got caught on the edge; the second span into the sidewall, and the propellers sliced through the netting (they’re not called blades for nothing). Neither were helped by me controlling the flights via my iPad WebSSH client, which lacks an easily accessible Ctrl key meaning it’s nigh on impossible for me to hammer away on the panic button (Ctrl-C) when a calamitous cataclysm starts showing it’s face.
In both cases, with the yaw code included, the flights suffered significantly more yaw, and the take-off speeds were up too. Hence my review (for probably the 4th time) of the yaw logic. And the first sentence of the comment above were critical and missing! Meaning so was the code! That then lead to the yaw PID made things worse, and in doing so, also upped the average blade speed across all four, leading to the over-enthusiastic launch.
Once more, d’oh.
Fly, Fly, little Raspberry Pi
Reading sensors, driving motors
Spinning propellers thereby…
Lifting you up, soaring into the sky
While the camera really proves you can fly,
The camera really proves you can fly!
First untethered, successful, safe take-off, hover and landing from Andy Baker on Vimeo.
With my sincere apologies to Don McLean for corrupting his original far superior lyrics
If you ignore the yaw, this represents a successful take-off, hover and land. It’s programmed to be a 9s flight, 3s takeoff, 3s hover, and 3s land. The drift is just due to the trampoline not being completely horizontal, and I’m not at all worried about the bouncing as that’s what trampolines do when something lands on them.
The yaw was unsurprising as I’d turned off it PID for this testing. And now I have a safe secure test platform, and code to get the drone in a good position for yaw testing (i.e. off the ground!), I’m now relishing the chance to tune the yaw PID.
Finally I also have some cracking stats to look at too to allow the drone to this autonomously – in this test, the spin speeds for take-off, hover, and landing were all hard coded during the testing so I could get an idea of acceleration produced by them.
And no crashes 🙂
It’s not as bad as it looks, I promise, and combined with the matching stats, diagnosing the problems is quite easy…
From the video, it’s clear this is an anti-clockwise spin, yet the yaw PID is increasing the ACW- and decreasing the CW-power as a result. Oops, got them the wrong way round!
Second pitch and roll PIDs:
Pitch and Roll stats
From the video, it’s clear pitch / roll oscillations are setting in and increasing;
there are one of two causes, either P gain is too big, or (more likely given the stats) D is too big and the wrong way round. It’s the latter I’ll be trying next. Scratch that: a closer look makes me think D is the right way round, providing a quicker reaction to errors as they start; the problem is that P is too high.
Finally, the crash is just because the drone tried to break free from it’s tethers and failed, but no harm done.
So overall, oddly, I’m quite happy with this, and it just goes to show that however much simulated PID tuning you do, there’s nothing like live flight testing to make sure you’ve got it right!
Yaw PID testing
This is the only way I’ve found to tune the YAW PID – indoors, surounded by sofa cushions, with ~1m tethers so it won’t fly outside of the scope of the cushions. The drone, takes off and hovers, during which time I can see the YAW, and have another guess what needs to be tweaked.
It has thrown up a couple of code bugs too because the YAW rate could be ~250 degrees per second which was the upper limit the gyro was configured to cope with, so I’ve double that to 500. At the same time, there was clipping code in the PID integral progcessing to ensure the I didn’t get to dominant – I’ve refined that clipping now to take the gain into account as it varies significantly depending on the PID owner.
You must be getting bored waiting for me to get this drone off the ground safely? I know I am!
I was hoping today would be my first successful untethered stable flight. But no. On the plus side, I do have autonomous take-off solved – both the ‘just about on the ground’ speed, and the vertical speed PID I gain to then control the take off at 20cm per second. And that’s what it did. And then it span like a ballerina, twisting its 2m ground tethers strings in a spiral, and at that point I hit ctrl-C and the drone crashed to the ground – completely undamaged this time due to me doing the testing on the back lawn (now possible due to the working WAP).
Anyway, here’s the yaw graph – I though I could get away without any YAW PID gains set for this, but I was wrong. Testing PID gains for this is a little more troubling as the only real way to do it is in flight! Better make sure I get it right or we’re going to end up with a very dizzy ballerina!
I think (though I can’t be certain due being more focussed on stopping the imminent crash) the drone was yawing anti-clockwise, which is the direction of the front-left and back-right blades; given the gyro YAW output (fgz in the graph) was positive, I have a reasonable idea of what needs doing. In addition, since no gravity is involved, there’s much less risk of oscillation. Fingers crossed!
P.S. The YAW code was already present so I turned it on, and made a reasonable guess at it’s PID gains. I think they weren’t far off either had I not applied them in the wrong direction. The ‘ballerina’ span faster and faster until she got so dizzy she fell down and twister her ankles. More are already on their way from Poland.