# Everything but the kitchen sink from macro blocks?

Currently the macros blocks are just averaged to extract lateral distance increment vectors between frames.  Due to the fixed frame rate, these can produce velocity increments.  Both can then be integrated to produce absolutes.  But I suspect there’s even more information available.

Imagine videoing an image like this multi-coloured circle:

Newton Disc

It’s pretty simple to see that if the camera moved laterally between two frames, it’d be pretty straight forward for the video compression algorithm to break the change down into a set of identical macro-block vectors, each showing the direction and distance the camera had shifted between frames.  This is what I’m doing now by simply averaging the macro-blocks.

But imagine the camera doesn’t move laterally, but instead it rotates and the distance between camera and circle increases.  By rotating each macro-block vector by the position it is in the frame compared to the center point and averaging the results, what results is a circumferential component representing yaw change, and an axial component representing height change.

I think the way to approach this is first to get the lateral movement by simply averaging the macro-block vectors as now; the yaw and height components will cancel themselves out.

Then by shifting the contents of the macro-block frame by the averaged lateral movement, the axis is brought to the center of the frame – some macro-blocks will be discarded to ensure the revised macro-block frame is square around the new center point.

Each of the macro-block vectors is then rotated according to the position in the new square frame.The angle of each macro-block in the frame is pretty easy to work out (e.g. a 4×4 square has rotation angles of 45, 135, 225 and 315 degrees, 9×9 square has blocks to be rotated by 0, 45, 90, 135, 180, 225, 270, 315 degrees), so now averaging the X and Y axis of these rotated macro-block vectors gives a measure of yaw and size change (height).  I’d need to include distance from the center when averaging out these rotated blocks.

At a push, even pitch and roll could be obtained because they would distort the circle into an oval.

Yes, there’s calibration to do, and there’s a dependency on textured multicoloured surfaces, and the accuracy will be very dependent on frame size and rate.  Nevertheless, in the perfect world, it should all just work(TM).  How cool would that be to having the Raspberry Pi camera providing this level of information!  No other sensors would be required except for a compass for orientation, GPS for location, and LiDAR for obstacle detection and avoidance.  How cool would that be!

Anyway, enough dreaming for now, back to the real world!

# I ψ with my little eye…

something beginning with Y.  See Beard for why I’ve referred to psi.

Sometimes I amaze myself with how stupid I can be.  I’ve been ignoring yaw for a long time because:

• a quad shouldn’t yaw due to its prop rotations
• if it does, there’s nowt can be done to stop it.

But from another long chat on the Raspberry Pi forum, the completely obvious point finally became obvious to me: although yaw can’t be prevented, it still needs to be accounted for in drift correction.  The fix for forwards drift plus yaw is almost certainly not reverse acceleration, and in the extreme case, with say 180° yaw, it may be forward acceleration needed probably along with some left or right also.

I’ve wasted months on drift control which couldn’t possibly work without including yaw.

For the moment, I’ll just cross my fingers and use the integrated gyro z axis, but I now definitely need a compass for longer flights.

# Back on track

Finally, with the new motors, blades, arm and legs, things are back on track.

3 test flights today aiming to find an average ‘hover’ speed.  Only inner most angular rate PID engaged, so there was drift due to the drift of the integrated gyro.  My first flight was once more scary as it also shot up into the sky because the vertical speed PID tried to undo the excessive vertical power applied my guesstimate of the default hover speed (but note not the manic rise that “Scary, very scary” revealed)

The average hover speed is now about 1550us pulse width suggesting these new 1045 carbon props are much more powerful than the 1150’s I had – they are broader and therefore more aerofoil surface area, so it doesn’t surprise me..

The even better news though was no yaw – the stats show no common sharing of power between pairs (front left + back right) and (front right + back left) which is always the sign of the quad trying to compensate for the yaw.  Whether that’s due to motors, props, or frame fixes, I frankly don’t care!  It now means my future flight diagnostics won’t be swamped by yaw.

The only negative was the the integrated gyro drift caused a diagonal drift landing, and once more, another leg died as it stuck a couple of inches in the mud while the quad drifted on!  I’m more than happy to pay that price!

# Chinook Helicopter

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?

# Back to basics

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.

# Too much test tinkering to do today.

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.

# More test flights, more improvements, more problems to solve

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.

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!

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

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.

# I started singing…

Fly, Fly, little Raspberry Pi
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!

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 🙂