Fecking rangefinders

  • SRF02 can’t run at 400kbps I2C baudrate necessary for reading maximum data from the MPU-9250 IMU.
  • TeraRanger needs a 12V power supply and provides 5V serial or I2C meaning level shifting to interface with the Raspberry Pi serial / I2C pins
  • LEDDAR uses weird and slow modbus protocol over serial meaning the IMU FIFO overflows if I’m sampling it above 500Hz – 1kHz works perfectly without LEDDAR.  Essentially, it’s wasting time I’m going to need for Camera, GPS, and Scanse Sweep processing,
  • Garmin LiDAR-Lite supports the necessary 400kbps I2C baudrate at 3.3V, but requires low level I2C access requiring a 20ms gap between sending the read request, and reading the response data.  Arduino provides this low level access, higher level smbus I2C via Python does not.  There are also comments around suggesting no other I2C activity can take place during that 20ms i.e. can’t access IMU during the 20ms!

All the sensors work, it’s just the API to access the data that’s non-standard in every one of these.  Did nobody on the design teams consider using a standard API for modern interface technology?  FFS!

P.S. Yes, I know there’s a URF that supports 400kbps I2C baudrate at 3.3V, but it has a bloody great potentiometer on the underside meaning it’s nigh on impossible to attach it ground-facing under a quadcopter.

P.P.S.  I know I could use the PX4FLOW; I actually have 3 but only one of these (the original) works; the clones both do not.  And anyway, where’s the fun in that compared to a vertical rangefinder, the Raspberry Pi Camera and the MPU-9250 gyro i.e. the three components that make up the PX4FLOW?

Flight of the body snatcher

Body snatcher flight from Andy Baker on Vimeo.

So this is the first flight of Chloe’s HoG running on Hermione’s frame.

She drifts right as Chloe always has but more so, and she doesn’t have LEDDAR installed, so the hover height is wrong. She’s seriously underpowered with the T-motor 1240 props, but the X8 configuration will fix that, but will require new PCBs.

Due to the lack of LEDDAR, she’s running the velocity rather than distance as the outer PID; combined with the lower power, that means she doesn’t get as high as she should.

Finally, you’ll notice significant yaw that eventually corrects as the yaw rate PID i-gain kicks in; again that due to the size of the props and X8 will resolve that.

Next steps are to

  • add code for PX4FLOW
  • get legs to allow underside sensors
  • add PIX4FLOW – LEDDAR is going into (permanent?) retirement as long as the PIX4FLOW provides good vertical height data with it’s URF.
  • bodge up the current PCB to add another 5V output pin for PIX4FLOW
  • bodge up the PX4FLOW I2C wiring for 0.1″ pitch connection to PCB
  • get the PCBs for X8.

Plenty to keep me busy for a while!

Σ some sensors

So far, I’ve been looking at LiDAR sensors

  • the LEDDAR One gives me quadframe z-axis height and with differentiation, velocity
  • the Scanse sweep gives a 360° quadframe x- and y-axis plot of the borders of the flight area; to turn that into something useful is going to require more processing; something along the lines of using the known pitch, roll and yaw gyros to rotate the previous scan into the current scan frame, and then compare the misalignment between the two to guesstimate movement direction and speed.  It’s not clear yet how much of this will be provided by the Scance processing and how much I’ll have to do, but a 360° scan feels like a lot of data to process.

My friend in China is using the equivalent of a PX4FLOW optical flow sensor: a downward facing low resolution camera with gyro and URF.  Like I described above, with the height and the incremental angles from the gyro, they process picture frame changes to come up with horizontal velocities – critically, the PX4FLOW is doing this, and spitting out velocities over I2C.  Follow the link and page down to the “Accuracy” section to see how well the tracking works for a manually controlled flight; the integrated-velocities distance / direction plot of the flight path overlayed on the satellite image is a very convincing match.

A long time ago, in a galaxy far far away, I’d seen the PX4FLOW, seen its price and moved on.  But now, I’m starting to wonder whether I should think again.

Having said that, perhaps with scanse, I could do the same, but much simplified by only matching the outline of the flight space rather 2 photos of the same space.  And perhaps I can break this down into small enough pieces that a whole outline can be processed in pieces during 100 motion periods (i.e. 1s).  This is starting to feel viable and is a lot more aligned with my DIY desire rather than buying a PX4FLOW that does it all for me.



The new Pi Zero with camera requires the latest Raspian version from the 10th May.  The RPIO.PWM code throws an obscure error with this kernel.  The RPIO.PWM library appears to not be managed by the original author, and currently, I don’t understand this error so cant’ fix it.  Deadlock.

Using Zoe’s SD card on Phoebe’s A+ also shows the same problem so it’s a change in the kernel, meaning further development on Phoebe can no longer pick up the latest code.  I’m worried that when the A3 is released later this year, I’ll be forced to use the latest kernel for it and the same RPIO.PWM problem will rear it’s ugly head and prevent further kernel upgrades on Phoebe too.

The only plus for the moment is that I can continue current development on Phoebe based on the January jessie to add the LEDDAR and compass function; in addition, by disconnecting the motors from the ESCs, Phoebe stops whining when there’s no PWM signal meaning I can do development / testing indoors.  Next stop is replace the ground facing camera and URF with the LEDDAR.

Snow White

Just sharing a couple of photos.

The first is my new prototype Pi with a discrete level shifter used to drive the URF I2C at 5V, while using 3.3V over the RPi I2C interface.  The type of MOSFET is not critical as long as its Vgs is much less than 3.3V – many use the BSS138 or 2N7000 – I just used a couple from my stash which fit breadboards better.  The next step is yet another PCB for Phoebe*:

Discrete I2C level shifter

Discrete I2C level shifter

The second is Zoe who I’m in the process of upgrading to the latest Raspian Jessie Lite – this is a start-from-scratch ‘update’ so I’ll blog the step next.

Zoe litening

Zoe litening

Zoe’s upgrade has so far gone pretty smoothly except for one minor glitch with updating to the new networking interface model and not having a GUI.  The one thing that’s made it a lot easier is that I’ve not had to dismantle her at all.  Also, in the past I’ve used a 10-port powered USB hub for WiFi, keyboard and mouse, but here I have a 2-port USB hub attached to Zoe’s OTG USB connector.  In all, that’s made the upgrade process much less painful than I was expecting.

*Nope, this URF won’t work with Phoebe – even with the level shifter, when I updated the I2C baudrate to 400kbps, the simple test program blocked, just like Phoebe’s own URF does on 3.3V. I also ran Zoe at 100kbps by mistake during her litening transformation, and that proved 100kbps is not fast enough to empty the IMU FIFO as fast as it is being filled.


Progress report

Although the blog’s been quiet, I am still tinkering with both Zoe and Phoebe.

Zoe’s drift is better with 3 changes:

  • I’ve changed my 0g offset calibration so that it’s now done standing on her feet, and an average of 4 readings are taken with her rotated 90° each time and an average used
  • I’ve changed the double sided foam sticking her HoG to the frame – it’s all a bit of a balancing act between having her held down firmly, and yet also providing buffering against vertical prop vibrations
  • I’ve change the code which controls how many samples are per motion processing – there was a minor bug in the timing I knew of, but until now had not thought it worth the effort fixing it.

Here’s the result.

I don’t think it’s going to be possible to get things much better – my guess is the 0g offsets are the dominant contributor to the reduced drift, and they vary. Here’s the output from three runs – the first with her resting on her props, and the other two on her feet; the entries with the Z axis set to 0 are the averages of the preceding 4 calibration test entries. 8000 is roughly 1g to give you an idea of the size of these offsets.

0g calibration results

0g calibration results

The progress with Phoebe is less positive; with the SRF02 rangefinder installed, the code blocks during initializion; i2cdetect can see the sensor so I presume it’s because the sensor is only rated to 100kbps I2C baudrate.  There is a similar URF from a different manufacturer which does support 400kbps, but only if the I2C master (the Raspberry Pi) supports clock stretching; sadly the RPi I2C driver does not, although that may be fixed soon apparently.  However, until that happens, height control using the URF is blocked.

Without the sensor, she’s flying, but occasionally seems to decide to drift; it’s not a steady drift, it suddenly kicks in as though she gets a dodgy reading from the sensors.  I then have to kill the flight before she gains too much height.  It’s not clear to me yet what, if anything I can do about this.

Phoebe’s sensitive under belly*

Phoebe's delicate underside

Phoebe’s delicate underside

Phoebe has got the PiCamera and the SRF02 Ultrasonic Range Finder installed on her underside; legs are back in place to achieve both camera focus and URF minimum range on the ground.

Camera’s working fine though the software is proving tricky for using the camera to do laser dot following or motion tracking MP4 encoding.

URF isn’t working; i2cdetect -y 1 sees the sensor, but a write to send an ultrasonic ping just blocks.  There’s a couple of possible causes: the URF is running on 3.3V not the 5V as defined by the spec, and the I2C bus is running at 400kbps instead of the URF’s supported 100kbps.

I can’t drop the I2C baudrate – I have 1000 batches of 12 byte samples to read each second from the IMU FIFO and even ignoring the I2C overhead that requires 96kbps – not a cat in hell’s chance of running the IMU and the URF together at that baudrate.

The voltage is fixable with some 2-way level adjustors like these, but these are going to need a PCB rework.

Stuck again for the moment.

*much like a hedgehog

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?


Zero to Hero

Dusk Devil Daemon Dragon? from Andy Baker on Vimeo.

This is about as good as it gets – 10s with minimal horizontal drift, but a slow steady climb, and hence the 20cm drop landing.  Previous flights showed a horizontal drift of about the same amount but with no vertical drift – it’s a bit of a lucky dip.

This is with the IMU filling the FIFO at 1kHz with 12 byte batches of sensor data with minimum accelerometer low pass filter of 460Hz.  She’s running at ±4g resolution which corresponds to drift of about 6cm minimum drift over the 10 seconds of the flight in a perfect world; for the imperfect world we live in, I’d say Zoe is doing her very best.

The code is on GitHub.

Just one problem: I flew identical code but with the CF tri-blade props this morning, and she can’t get off the floor and I have no idea why the difference in props has such a radical affect on the flights:

  • the plastic props flown in the video have two 3.25″ blades with a low pitch angle weighing about 4g
  • the CF props have three 3″ blades with a higher pitch angle weighing about 6g

That’s similar enough not to explain such radical difference in behaviour.  I need to understand this if I’m ever going to get Phoebe up in the air with her URF installed to measure vertical height and thus control the vertical drift Zoe showed in the video.

Onwards and upwards!