Scratched record…

To get Zoe or Phoebe any better, I need more sensors.

  1. GPS: I’ve heard that while GPS may only have an accuracy of 10m, the resolution is a lot finer and is stable; that could be good for outdoors but useless for indoors.
  2. My various laser tracking solution should be good for indoors.  My current best idea is 2 down-facing lasers on the frame and one hand held also pointing at the floor; combined with the RaspiCam could give height and and a simple degree of line tracking.  Probably not good enough for use outside in bright sunlight however.
  3. The ultrasonic range finder could provide height indoors and out, but can’t help with horizontal drift
  4. The barometer is a chocolate teapot to me – despite high resolution, indoor air-pressure fluctuations will spoil it
  5. The compass could be useful for yaw, but only becomes worth its weight in gold alongside GPS: orientation and location

Currently, 2 sounds the most viable, useful, simple and cool – imagine taking a quadcopter for a walk indoors following the 3 laser dots on the floor trying to keep them in an equilateral triangle of fixed size.  Except…

Zoe Pi Zero doesn’t have a camera connector so that rules her out.

Phoebe’s A+ is powered solely by the LiPo to make space underneath her for the camera and URF.  That makes it much harder to run the code without also running the motors, so I need to sort that out to test the new idea safely.  Then there’s the issue that I think the laser processing will a separate CPU to process the pictures – i.e. the A3 due for delivery some time this year.

Oh, and then I’ve just found this.

It might be time to take a break?


I2C errors continued

I’m still getting I2C errors logged, and the quality of each flight seems to depend on how many of these I get and when.  They all occur during the warm-up code, and could be anywhere from zero to five or six.  If they occur in the first few seconds of warm up, the impact on the quality of flight is small – later in the sequence and it becomes larger.  That’s due to the fact the 20s warmup is primarily there for filling up the Butterworth filter history – earlier errors are less significant.

I do wonder whether it’s the altimeter also on the same I2C bus that may be causing the problem.  My code doesn’t bother initializing it, so next step is to add code just for that.  Fingers crossed.

I added the few lines of code to just initialize the barometer, but that made no difference whatsoever to the I2C errors so for the moment, I’m out of ideas.

My aversion to more sensors

The PC World mention, along with some recent comments got me thinking about why I lack interest in adding an altimeter / magnetometer / GPS / remote control to HoG.  After all, it’s the obvious next step.

I have the sensors already, and none of the above would add much in the way of overheads to the code processing – perhaps only 1Hz polls of the GPS, compass and altimeter fused with the existing data from the accelerometer and gyro about orientation, direction and speed feeding into the existing flight targets.  All relatively straightforward.

Autonomy vs. remote control was purely a personal decision based upon my ineptness at controlling machines with joysticks.  I stopped computer gaming with Half-Life2 2 when I was within seconds of the end and yet  lacked the hand-eye coordination to win that final battle to stop the launch of the missile / rocket / bomb.

It’s a combination of time and testing that is the biggest problem.  Up to now, all testing happens in the back garden – it now takes me less than 5 minutes to run a flight, and get back indoors to analyze the diagnostics.  Even when the weather is terrible, those 5 minute slots exist virtually every day.  But with GPS movement tracking resolution of 10m, the garden is nowhere near big enough to test autonomous path tracking – just too many high stone walls to crash into.  I could move testing to the village play park a hundred meters down the road, but it’s called a kids play park for a good reason.  I could move into the fields a couple of hundred meters away, but that’s just far enough away that time steps in – to-ing and fro-ing between the fields and the “engineering lab” (home office) would just be too inefficient for the limited time available due to a full-time job and two kids under 7.  Oh, and the farmers probably wouldn’t appreciate HoG scything down their crops or sheering their sheep!

So I settled on short term autonomous flights within the bounds of the back garden.

Having said all that, I’m off to the kids’ play park tomorrow during school time just to see how long HoG can maintain a stable hover with limited drift, and perhaps add some horizontal movement to her flight plan if all goes well.  Weather forecast is good, sunshine and only a gentle breeze so hopefully I’ll be able to get a longer video of what she can do!

Accelerometer drift proof and solutions

These are readings direct from the 3 accelerometers with virtually zero code tinkering – specifically no subtraction of gravity; the only code modifying the sensor data values is fixed calibration values, fixed unit conversion and averaging. None of these three should cause the decline in the Z-axis (yellow) line against the right-hand axis.

Z-axis drift

Z-axis drift

So I need to do something about this, in particular the Z axis which is the cause of my ever climbing flights.  3 approaches:

  1. give in and add an altimeter – but I’m waiting for the next revision of the DroTek board that has the pin spacing I needs – however this wouldn’t be ideal for indoor flights due to air pressure changes as people open doors etc
  2. give in and add ultrasonic range finders – again not perfect for a variety of reasons – firstly it’s I2C is only 100kHz rather than the 400kHz for the MPU6050 so could slow things down without some very careful coding;  secondly it’s tracking distance to ground where as the accelerometer is tracking from takeoff point – so in a lecture theatre, takeoff from a table would give horizontal flight from the accelerometer, but a rapid descent as the quad passes over the edge of the table, also possible causing two of the arms to clip the table; third and finally, I’m not sure how well a URF will perform on grassy rather than hard surfaces.
  3. filter the accelerometer output to smooth the acceleration (the spike at one second in the graph above) but trace the steady drift downwards; simplest would be yet another complementary filter, merging in fractions of latest accelerometer readings into the initial value in the earth axis; better though would probably be a Kalman filter where the prediction it provides may well be able to remove the spikes completely – it’s also easier as there’s just a single source of the data being filtered, unlike the current complementary filters which are used to merge angles from gyro and accelerometer.

So option 3 it is, though as always, I’ll chicken out on the Kalman unless the complementary doesn’t work well!


Every time I threaten to retire Phoebe, she throws a spanner in the works.

I took her out for some horizontal velocity PID tuning this morning.  It’s below freezing point outside and my expectations weren’t high, but her thermostat code still brought her sensors up to the 40° calibrated temperature.  Probably 5 flights consisting of 3 seconds take-off at 0.5m/s, 5 seconds hover, and 3 seconds descent at 0.5m/s.

Of those 5 flights, one was, well, there’s no other word for it, perfect.  A perfect pass of the Ronseal test.  Don’t get me wrong, the other did well wrt drift management and getting to approximate hover over the take-off point but this particular flight just worked: take-off from a sloping ground stabilized up to 1.5m, completely static hover for 5s, and then an elegant descent back to the original take-off point.

The cause: gravity calibration in the Z axis.  Every flight starts with Phoebe peacefully sitting on the ground, measuring gravity in her X, Y, and Z axis.  That then produces a set of Euler angles used to rotate gravity back to earth axes where gravity should read 0, 0, 1 in the X, Y and Z axes respectively.  X and Y always measure zero to 8 decimal places.  Z seems to have a variability of 0.2% still though despite the thermostat – gravity could read between 0.998 and 1.002g and it seems entirely random.

But this particular flight, the sensors said earth gravity was 0, 0, 1.000009g!  That’s 0.001% error in the Z-axis or 0.1mms-2 acceleration error.  That correspond to a maximum drift velocity over the course of the 11s flight of 0.55mms-1!

That has multiple effects, the key two being angles and velocity calculation: with 0.001% error in the Z axes, then all angles and velocities were essentially right for the duration of the flight, hence the fact she rose to the right height and hovered over her takeoff position.

I’d love to know the cause of the random variance of accelerometer values from the Z axis – is it sensor tolerance, or ground vibrations or something else I’ve missed (the motors aren’t running at this stage of initialized before you ask)?

A barometer / altimeter + magnetometer / compass may fix it entirely:

  •  the barometer / altimeter will provide an alternate measure of vertical velocity @ ±10cm resolution
  • the magnetometer with provide orientation, and critically pitch, roll and yaw compared to the earth magnetic core.

A fusion of these sensor readings with their current accelerometer source could well improve matters – “fusion” just being the merging of the sources through a complementary or Kalman filter.

So why don’t I just get on with it?  Because still I cannot find a sensor that meets critical physical properties – none of them provide a double row of pins with 0.1″ pitch in both directions to allow connection to a breadboard or prototype PCB.

I think I need to put my politest head on and see whether DroTek have fixed their pin pitch spacing for their 10 DOF IMU yet.  Wish me luck!