Fried Pi (again)

I was going  to write of the successful PID tuning pretty much stopping horizontal drift with a video to prove it; it’s true that happened except for the video because Zoe died.  She just doesn’t boot.  That means I need a new Pi Zero – there more chance of a dental extraction in the back garden flock 🙁

I guess I’ll see how Phoebe’s flying now.

White out

I’ve been unable to get Zoe working in WAP mode with the mid-March release of Jessie.  Sometimes the hostapd starts fine, sometimes it doesn’t, and there’s some conflict between configuring the static IP address in the DHCP client config (dhcpcd.conf) and the booting of the DHCP server (udhcpd) – it starts OK according to the boot logs, but by the time I’ve logged in, it’s stopped.

So for now, I’ve dropped back to the end-January image that works, and I’ve stored off a copy of the working pre-WAP mid-March image so I can pick it up another time.

Then I did some tinkering with 0g offsets, measuring them 5 times, then twisting Zoe 90° and measuring again until I had 20 readings.  Here’s what it looks like suggesting an X offset of about 40 and a Y offset of about 200 is about right.

20 0g offsets

20 0g offsets

So I then took her out to fly several 10s flight including 6s of hover.  Some were immaculate, others less so, and the main factors (guess work) are the slope of the ground, and the weight balance, particularly if it shifts in flight because (for example) I’d not got one of the batteries tied down as tightly as possible!  Even for the imperfect flights, it was possible to see her successfully stopping the drift, and then the drift started up again, to be stopped again.  I think some PID tuning is required here as this suggests the correction is using the P part of the PID and it needs some I.

FIFO overflow

The IMU FIFO has a fixed size, so it can fill up if not read frequently; it’s then configurable whether the IMU stops adding to the FIFO or overwrite what’s there already.  Either way, this results in data corruption.  I’d heard, and a quick test confirmed that the FIFO size  is 512 bytes.  The same test also revealed it takes 0.064s to empty a full FIFO byte-by-byte or 0.000125s (1/8000)s to read a single byte or 1.5ms to read the 12 bytes that are a full set of sensor data.

For the FIFO code to work, I need to read the FIFO and update the ESCs often enough in comparison to the sensor sampling rate to ensure the FIFO never overflows.  The rate for updating the ESCs is arbitrary; experience say about 100Hz is a good value.

The other factor is how long the motion processing takes; again experience with the hardware interrupt code suggests this is around 2ms.

A flight loop looks like this:  sleep, empty FIFO, motion_processing.

The question is how long to sleep in order to get the 100Hz ESC update frequency and not allow the FIFO to overflow?

esc_period = 100Hz = 0.01s
read_period = 0.0015s
motion_period = 0.002s
num_samples = sampling_rate * dt

esc_period ≈ sleep_period + n_samples x read_period + motion_period
0.01 ≈ sleep_period + sampling_rate x dt x 0.0015 + 0.002
sleep_period ≈ 0.01 - 0.002 - sampling_rate x dt x 0.0015

I’ve updated the code, and then collapsed it to a simplified version which is now on GitHub.  With some basic PID tuning, flights are back to the equivalent quality Phoebe could do although I need to keep testing for finer tuning and confidence building.


Zoe the Zero – Appendix – Testing and Tuning

I did very little testing before I let Zoe loose – just two pieces:

With the LiPo not plugged in, I ran a flight; this checks that the sensors are working and  tuning data sampling rate to ensure all samples are caught.  Simply run

cd ~/Quadcopter
sudo ./ -f fp.csv

As a result you should see a 20s countdown, a 1.5 second warm-up, ascent (2s), hover (2s), and descent (2s).  Then the length of the flight is shown on screen.  The key here is that the internal timing for the steps through the flight plan is based only on the number of samples captured, and the data ready interrupt frequency; the total time printed at the end is the difference between calls time.time() before and after the flight.  It should read 7.5s with accuracy of 1% or less based upon the above flight plan.  If it is significantly more, then samples are being missed and you need to reduce the dri_frequency.  If it is significantly less, then the data ready interrupt is not working – have you installed the customized GPIO code?

With that passed, the other step is to check the PWM is working, and that the props, motors and ESCs are installed correctly:  the front left and back right props should spin anti-clockwise to match the code’s expectation.  Run

sudo python ./ --tc 1 -h 150

Each prop should spin in turn (front left, front right, back left, back right) for 10s.  Feel the down draft underneath each.  If the props are not turning the right way, swap any two wires on the ESC.  -h specified the PWM pulse size minus 1000 i.e. 150 is 1150us pulse.  This should be enough to get the props spinning but well below the takeoff speed of around 400+.

With those two tests done, she’s ready for a trial flight.  With the motors still powered up run

sudo python ./ -f fp.csv

Be ready with control-C to kill the flight, and I’d strongly recommend running this flight outside on a soft surface (grass).  It should all be fine, but it’s very demoralising to trash your quad in a violent crash on the first flight!

Code update and horizontal flight plan

I’ve just uploaded the latest code up to GitHub.  It only adds some tested tuning and diagnostics to ensure the tightest zero drift yet, perhaps the best it can possibly be.

I have a cunning plan to add a degree of remote control without breaking my ruling of no human in the feedback loop.  But I need to check first Phoebe can walk before I teach her to run.

To that end I’ll add horizontal velocity targets into the configured flight plan along the lines of

  • 2.0 seconds climb at 30cm per second
  • 1.0 seconds hover
  • 2.0 seconds horizontal movements at 30cm per second
  • 1.0 seconds hover
  • 2.0 seconds descent at 30cm per second.

No changes to the code are required, but clearly the test flights will need to happen outside until my confidence builds.

I couldn’t resist taking her out for a flight with intentional lateral movement included in the flight plan. And it just worked – I just inserted 3s of leftwards movement between a second of hover either side. It was cool to watch her climb, hover, then lean left, flattening out once at 0.3m/s, and then leaning right to put the horizontal breaks on as the flight plan swapped back to hover again.

There was a lost of height throughout, but nowhere near as much as I’d expected.  I’ll see if I can get a video to show it.

Travel sickness

I took Phoebe to Cheltenham on Wednesday to check out the new location for the Cotswold Raspberry Jam (tickets still available but going fast).

Yesterday (Thursday), I took her out for a few more ‘confidence building’ test flights, and she was a changed quad – she climbed too fast and continued to climb during hover and she drifted significantly.  Oh sh1t – we have the perfect location to show her off, but somehow she was no longer fit to be shown.

Today (Friday), she’s back to behaving normally again so I’m concerned her accelerometer had drifted in transit to Cheltenham – while carrying the case, her Y axis was pointing down, sensing gravity and her Z axis was not unlike normal – that matches the drift I was seeing.  I hope that’s not the problem as that would ruin the chance of an indoor flight at the Jam – hopefully the weather will be good on the day, so at least an outdoor flight should still be possible.

Anyway, while trying to work out what was going wrong, I reviewed a couple of things I’d not done for a while.

The first is prop balancing – using my Dremel to lightly strim the underside of the props so that they have a matt surface, and they balance well on one of the maglev prop balancers.  The matt surface allows the air to flow over the props smoother which leads to better more efficient air-flow, and reduced turbulence resulting is greater lift.  For that reason, I used P1000 wet and dry sandpaper to matt and smooth both top and underside of the props.

Balanced blade

Balanced blade

The other is (controversially) to re-add 0g calibration but only on the X and Y axis – the primary directions of drift – in such a way it can be done indoors from a relatively flat surface prior to demo flights, but also can be disabled easily without the risk of coding errors with a destructive resultant flight.  Calibration takes half a second, and results are stored to file, and reloaded each flight; if the calibration is not possible, then the calibration file settings can be set to 0 to disable it, thus dropping back to Phoebe’s performance from the last few days.

I don’t think either of these were related to her travel sickness, though now done, there’s no point in undoing them again!

BYOAQ-BAT IX: Testing and tuning

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.

Only one very simple test is required before HoG takes to the air.  With your quad on the ground, and motors and HoG powered up, simply type

sudo python ./ --tc 1 -h 200

Each blade props should spin in turn in the order of front left, front right, back left and back right.  The front left and back right props should spin anti- / counter-clockwise, the front right and back left props clockwise.  If the props don’t spin, increase -h slowly (in tens) until they do.  If any of the props spin the wrong way, swap any pair of the three wires driving the ESC.  If each props is rotating in the right direction, check that each prop is producing a down-draft, not an up-draft.  If there’s an up-draft, then swap the props.

For PID tuning, I’m not going into the details of how to do it from scratch, but here are some guidelines of how you can take my PID gains and tweak them to fit your quad.

First, only the inner PIDs which control stability need proper tuning specific to your quad.  The are the pitch, roll and yaw rate PIDs.  The rest are almost certainly fine for any quad.

In the code, look in CheckCLI at the various i_am_phoebe, i_am_chloe, i_am_zoe and i_am_hog settings:

  • cli_hover_target is not strictly necessary – it’s just used to slowly spin up the motors to roughly hover speed before takeoff.  I general have it set to 500 for 12″ props, 550 for 11″ props and 600 for 10″ props.  This value is the size of the PWM pulse width from the HoG to ESCs in microseconds
  • cli_pr*_gain, cli_rr*_gain and cli_yr*_gain vary with length of arms and power of motors, and the weight distribution of the quad.  The ratio of 2:1:0 for P:I:D seems to work well.  Phoebe has short arms and small props, Zoe had larger props, and HoG has long arms and large props – compare the setting for each to see the effect.  In addition, all my batteries face front to back, so it takes more power to pitch rather than roll, hence the difference between cli_pr*_gains and cli_rr*_gains.
  • finally, cli_vv*_gains are for vertical acceleration, but if you compare Phoebe to Zoe and HoG, you’ll see the setting is inconsistent.  Because of gravity, the only real tuning required is “enough” power; hence small props have larger PID values.

Settle down…

Settling Time

Settling Time

It looks at first glance at this test that simply allowing some settling time would significantly reduce the level of sensor drift. X and Y aren’t 0 due to some very small angle of tilt during the test; what’s looking promising though is that throughout several similar tests, the Z axis measure of g always stabilizes significantly around 10s.  I don’t know whether that’s related to temperature, but I plotted it just in case.

So for indoor flights where the temperature environment is stable, the fix may well be to just allow more time for the temperature and sensors to settle down.

Clearly for outdoor flights mid-winter with cold winds, the sensors are going to need to be wrapped up nice and cosy warm in their own onesie.