# Trampoline testing and virtual reality

With a little thought, I have a better idea of what’s required from the trampoline. Consider the following:

Height, Speed, and Acceleration

The top ‘picture’ shows flight – plotting height over time. The quad sits on the ground, then rises at fixed speed for a bit, hovers for a bit, descends for a bit. and sits back on the ground again – this is the external set of targets for the quad – what the human wants it to do.

The middle ‘picture’ shows the same, but plotting vertical speed over time. The sitting quad starts with 0 speed; a pulse of linear speed integrates over time to produce the sloped rise in height in the first picture. Descent is clearly the opposite. This is what the outer PID does – it takes the target set by the first picture to produce and output to achieve the desired vertical speed

The final ‘picture’ shows the same but from the acceleration point of view. Violent spikes of power are applied to the drone to change it speed as per picture two; momentum maintains that power to change it’s height as per picture one. This is what the inner PID does – it takes the output of the output PID as it’s target acceleration, and combined that with the gyro inputs to control the acceleration.

OK, in the real world, all the sharp corners will be rounded or wobbly depending on how well the PIDs are tuned. But the sharp diagrams provide excellent PID ‘targets’ for simulation – and that’s the next direction I’m going: using these targets, and some basic math(s) and a spreadsheet, it should be possible to tune the PID in simulation alone except for one missing link, and that’s where the trampoline steps in: I need a mapping between the blade PWM inputs, and the net acceleration that produces. That simply means that I do several runs at various PWM inputs, and use the accelerometer to measure the resultant acceleration.

Don’t think I’ll need it, but the drone currently weighs 1509g (1.5kg) currently:

Drone weight

That’s with the new case and corresponding diet Model A RPi, micro-USB adapter, carbon legs and the golf ball feet!

# What’s up, Doc?

Don’t ask me, I haven’t the faintest idea, but when I run the drone in simulation mode (without power to the rotor blades, but otherwise identical), all works fine as per yesterday’s spreadsheets, yet once I have power to the blades, I get this mess, and yet there is no direct feedback from the blade motors to the Python code.  The only direct connection between the two is the power supply, but if there were problems there, I should see a lot worse symptoms than this spreadsheet shows (like a reboot!).

It’s clearly the z PID outputs that are collapsing catastrophically, yet there is no reason why. Currently, I am flummoxed!

# Logging stopped the drone headstand

So I think I’ve found and fixed the cause of the drone headstand.

“You think you’ve found it”, I hear you say? Yes, well, this is through simulation as I don’t want to turn on the motors again without understanding what went wrong.

“Who cares, cuts to the chase!”

The problem is (I suspect) that when the drone tilts by a small amount, the z axis accelerometer starts reading less than the 1g down force set as its PID target on the vertical axis. That’s because the vertical axis and the z accelerometer axis are no longer aligned. So the z PID which takes the z accelerometer as it’s input ups the power to all blades to meet the current vertical axis target. That sets the drone scootling across the floor at an angle and the first impact then triggers the flip into a headstand.

The cause is that the target for the z PID is 1.0g absolute vertical, whereas the input to the PID is < 1g but critically that accelerometer is no longer vertical. But if I use the math(s) I’d found earlier, I have now “normalized” the z-accelerometer output to vertical and am using that as the z input. That was the main cause of the problem.

The noise I mentioned previously is probably not caused by the motors as the accelerometers do fluctuate even when the motors aren’t engaged. That’s not really a problem as long as the PID accounts for it. In this cause, the Z axis PID has too much emphasis on its proportional component (the P in PID) in comparison with the integral component (the I in PID). On the vertical axis, it’s the I component which needs to dominate, since it’s that which will power takeoff and vertical stability at a given height. The X and Y PIDs are the ones handling front / back /left / right tilt balancing.

Having realized that, my simulations are showing much more stable performance, and the few niggles I have are due (I hope) down to flawed simulation, rather than flawed PIDs.

I really am running out of excuses to not just set this thing loose!

“Well get on with it then!”

Not until I can have the largest, tallest room of the house emptied to provide a safe take-off site.

“What’s that room used for normally?”

The kids playroom! Think I’m going to have to take another off work while the kids are at school / nursery!

P.S. Processing the simulation results was greatly improved by adding a second handler to my logging. Now each diagnostic log can be written both the file and console. All that’s written to file are diagnostic stats, which then are fed into Excel LibreOffice spreadsheet to churn out some graphs. Compare and contrast the starting, and ending position of these this test. Notice the chaos ending in flat-lining on the before run? (The four lines on each graph represent the power (in PWM ratio units) applied to each motor).

Before PID tweaking

After PID tweaking