My hacked Altair Aerial Blackhawk continues to serve as a great test platform for experiments in DIY flight controllers. So, when I heard the buzz surrounding the ESP32 line of Arduino-compatible microcontrollers (Dual 240 MHz cores, WiFi/Bluetooth on-chip), I knew I had to try one of these boards on the "Hackhawk".  

If you've been following the developments in the ESP32 community, you know that the smallest ESP32 board is the recently-released TinyPICO.  With its petite form factor, this board seemed to me like an obvious choice for indoor MAVs, and I wasn't disappointed.  This wiki shows how I got the Hackhawk flying with the TinyPICO, using my favorite IMU solution and some small additions to my platform-independent C++ flight-control firmware toolkit. 

Future plans for this project include:

1. Finding (or designing) an IMU that will mount on the TinyPICO without sacrificing two of the GPIO pins to serve as power and ground.
2. Switching from standard / old-school ESCs to DSHOT600, using C++ code I've already tested on ESP32 boards. (The ESP32's RMT signal module and FreeRTOS kernel make this especially easy.)
3. Using the TinyPICO's on-board Bluetooth (or wifi) for real-time sensor telemetry, and possibly even control from a mobile device.

What could be more fun than hacking an RTF quadcopter to fly with your own custom firmware? How about hacking with your own DIY Arduino-compatible 32-bit flight controller?  This tutorial shows how I did it. Advantages of using this controller include:

1. Access to the huge selection of Arduino-compatible add-on sensors (distance, optical flow, ...)
2. Use of the high-accuarcy SENtral Sensor Fusion IMU, freeing up computation cycles for other tasks.
3. 3.3V signal levels, for adapter-free interfacing with Raspberry Pi and other single-board computers.

Looking around for an inexpensive, almost-ready-to-fly brushless-motor quadcopter to use a basis for indoor flight-control research, I was delighted to come across the  Altair Aerial Blackhawk.  With its extra-long extension legs and GoPro mount (which I plan use for additional sensors), the Blackhawk really fit the bill.  

As soon my Blackhawk arrived, I removed the cowl covering the fuselage, revealing the custom flight controller / receiver board shown below. I unplugged the LED leads for the headlight and four arm lights, carefully snipped the soldered-on wires with a diagonal cutter, and unscrewed the board from its mount, leaving me with the ESCs and battery leads shown in the second picture below.

The Blackhawk with its original flight controller

Original flight controller removed

As you can see, the inside bottom of the Blackhawk didn't provide a flat surface on which to mount a new controller. So I used Tinkercad to design a 3D-printable mount that I attached with E6000 adhesive.  The mount has the standard hole spacing for a 36x36mm flight controller and power distribution board (PDB).

3D-printed mount for PDB and flight controller

Once I'd printed out the board on my Lulzbot Mini, I added some M3 nylon machine screws and spacers:

Then I glued the mount to the Blackhawk with a bit of E6000:

Next I secured the PDB to the mount with another set of spacers, soldered a new pair of heavy-gauge wires from the power supply to the PDB, soldered some female jumper leads onto the control wires going into the ESCs, soldered a pair of female jumper wires to the auxiliary power supply, and soldered the ESC power wires to the PDB.  Double-sided VHB tape helped re-secure the ESCs firmly in place:

For the flight controller, I chose the inexpensive Flip32 Ominbus F3.  Its onboard battery-elimination circuit (BEC) allowed me to connect the power wires directly from the PDB, and its DSM connector made it easy to plug in my favorite receiver. 

For the flight-control firmware, I decided to with my own C++ Hackflight  system (which also works on Arduino-based flight controllers, as well as a flight simulator I built with UnrealEngine4.)  After testing the IMU, receiver, and motors, I attached the propellers and was ready for the maiden flight:

As you can see, the LemonRX receiver fits nicely into the front of the fuselage, leaving plenty of space to attach a "companion board" like the Raspberry Pi Zero W,  NanoPi, etc. – as I hope to show in a future post!

Originally developed as an MAV flight simulator, Microsoft's AirSim program recently added the ability to drive a simulated  car.  Although my own interests lie on the MAV side,  students in my recent AI / Deep Learning course chose to work with the car simulator as the basis for their project. 

As the video and code show, AirSim's support for Python interaction, combined with the powerful features of the TensorFlow deep-learning package, made it a matter of a few days' work to put together a simple demonstration of visually-guided collision avoidance. 

With sophisticated simulation and machine-learning tools available to anyone for the price of a decent workstation and GPU, it promises to be an exciting year ahead!

In earlier posts I described HackflightSim, an open-source quadcopter flight simulator built on the V-REP robotics simulation platform, using actual C++ flight-control firmware. After seeing the kinds of beautiful, real-time simulations that Microsoft was able to get with ts AirSim program built on UnrealEngine (UE4), I figured it was worth looking into UE4 for my own simulator. Thanks to the powerful features of UE4, I was able to start from scratch and build a rudimentary, 120 frames-per-second simulator in under 500 lines of C++ code. 

As this video shows, UE4 makes it easy to switch among a variety of cameras: "follow" camera (always in front of the vehicle); "chase" camera (behind the vehicle); and the familiar FPV.  It's also pretty straightforward to import an existing frame design (like this modified 3DFly frame) and propeller design into UE4 as a "mesh", saving you the trouble of designing a vehicle just for the simulation.  

I'm planning to work with a studio-arts student on building some realistic interesting indoor environments in which to fly, using the powerful level-design tools in UE4. This should speed up the prototyping of firmware algorithms to exploit the tiny, powerful new sensors available these days, like the VL53L0X ranging sensor and the PMW3901 optical-flow sensor, before deploying them on an actual MAV.

This video shows the Maiden flight of the Arduino-compatible STM32L4 "Ladybug" brushed-motor  flight controller from Pesky Products (enabled by the Arduino STM32L4 package from Grumpy Old Pizza), running my Hackflight firmware (which already runs on a variety of flight controllers, as well as a simulator).  I used a 3DFly frame, Lemon RX satellite receiver, Walkera Devo7E transmitter running DeviationTX firmware, and standard 8.5mm brushed motors for the Hubsan X4 and similar vehicles.  

The goal is to have a very inexpensive, state-of-the-art flight controller for nano-scale quadcopters, with a minimalist, object-oriented firmware design (around 1500 lines of C++) that you can program with the Arduino IDE, enabling all sorts of cool projects. The board has pins for I^2C, UART, and GPIO, allowing it to be connected to the new ultra-lightweight, low-power Arduino-ready sensors (like this one).

Instead of a traditional IMU, the board uses an EM7180 SENtral Sensor Fusion coprocessor, which performs much of the work traditionally done by the flight-control firmware. The EM7180 also incorporates a barometer, for altitude estimation. The main processor is an STM32L4, a low-power-consumption ARM Cortex M4 running at 80 MHz, with a Floating-Point-Unit.

The next iteration of this board (currently being built) will feature a standard Spektrum DSM connector for the receiver (which is currently plugged into the RX2 port on the board for convenience until the new iteration arrives).  It should also be possible to use a CPPM receiver on the same connection, with a slight modification to the firmware.  Once the prototype has been tested, I will be looking to produce the assembled boards in bulk, for use by students, researchers, and hobbyists.  

This video shows me flying our homebrew "Hackflight Sim" quadcopter flight simulator using a Spektrum DX8 receiver without a cable. The DX8 is talking to a Lemon RX satellite receiver connected to Teensy 3.2 (32-bit Arduino-compatible microcontroller), which connects to my Linux computer over a USB cable, as shown in the image below. A simple Arduino sketch reads the DSM-encoded values from the RX over the Teensy's RX1 (UART input) pin, and converts them to serial messages encoded using Multiwii Serial Protocol (MSP). The simulator parses these messages, converting them into stick demands to fly the simulated MAV.

Consistent with the Hackflight approach of using and re-using inexpensive, open-source hardware and software as much as possible, this hack relies on hardware (Teensy 3.2 micrcontroller, Lemon RX satellite receiver) and software (MSP parser) that we are using onboard our MAVs as well.

Although it'd be great to get this cable-free hack working with a commercial flight simulator like Phoenix, there is already at least one such solution available commercially.  

This video shows me flying a Syma X5C quadcopter, with the factory closed-source flight controller replaced by a Quanum Pico 32-bit brushed FC.  I followed the directions in the "Visible Drone" chapter of this excellent new book, but, lacking the eye/hand coordination required to do surface-mount soldering, I used a Quanum Pico instead of the Teensy-based FC shown by the author.

A simple 3D-printed mount allowed me to attach the new controller with some 3M VHB tape. 1.25mm picoblade connectors, available cheap on ebay, connect the FC to the brushed motors on the Syma.  I flashed my own firmware on the board, using PIDs from a 3DFly/Pico vehicle I'd built.

In addition to having a Spektrum DSM receiver onboard, the Quanum Pico has built-in Molex connectors for attaching I^2C and UART devices.  So I'm hoping to use the modded Syma drone to experiment with proximity sensing, optical flow, and the like.

This video  shows the maiden flight of my new brushed quadrotor, a “totally DIY" project using my own C++
firmware  (Multiwii clone with hardware abstraction), 3DFly
3D-printed frame, and, best of all, a 32-bit brushed-motor flight controller that I built from a Teensy 3.2 board. Why build your own brushed flight controller, instead of using one of the many excellent commercial FCs available today?

Apart from the educational value and satisfaction of building something yourself, I was frustrated by the the limited signal pinout on the commercial off-the-shelf (COTS) boards. Inspired by the work of  Geof Barrows with the Crazyflie platform, I wanted to be able to connect an I²C or SPI sensor to my brushed flight controller, while still using a standard R/C transmitter / receiver. Like many others, I am also drawn to the Teensy/Arduino platform because of the enormous variety of code libraries available for it. By the time you hear about a new sensor, there's likely already Arduino support for it. Finally, I had spent a significant amount of time developing my own hardware-independent C++ firmware , which I already had working with COTS flight controllers on a brushless-motor quad, a brushed quad, and even a DIY simulator. So I was reluctant to buy into another open-source project like the (admittedly awesome-looking) Crazyflie, with its own firmware, radio, base-station software, etc.

The photo below shows one of my earlier attempt to build an FC using a Teensy board and a standard MPU6050 Inertial Measurement Unit (gyro/accelerometer) breakout board. It's obviously much too big for a brushed copter,and I had such poor results using it on one of my brushless vehicles that I gave up, and returned to trying out COTS solutions.

Then I stumbled across the Pesky Products store on Tindie. Not only was there a cutting-edge IMU shield (with  magnetometer and barometer) suitable for mounting on a Teensy; there was also a shield for turning PWM signals into  rushed DC-motor voltages. Thirty-six bucks and a few days later, I had them in my shop. I soldered pin sockets on the Teensy and pin headers onto the two shields, then soldered a female 1.25mm micro JST connector to each of the four motor through-hole pads on the motor shield. For battery power I cannibalized the power cable on an old Hubsan X4, soldering female jumpers onto the ends (though I subsequently discovered that you can get even these cables on Amazon!) This allowed me to use the standard set of 8.5mm motors and 3.7V battery for this vehicle.

I modified the Pesky Products IMU code to work with my firmware, and then used my own Arduino PWM input library to access the radio signals on my FrSky VD5M receiver. To flash the firmware and test the motors and the receiver signals, I made up a no-power USB cable following the “Option #2: Cut the Red Wire” directions for the Teensy (No, the RED wire!!!)  Several iterations of modify/flash/test later, it was up and flying.

Although the all-DIY quad has about the same gross weight (60g) as the equivalent vehicle with a COTS board, the DIY version is much bulkier. It also doesn't take advantage of the awesome FrSky-compatible micro PPM receiver that I prefer for indoor vehicles; so, instead of one signal wire from the receiver, I need four (or five, for the auxiliary switch). So now that I have a flying prototype, my next steps are:

1. Get another Teensy, IMU, and DC motor board and mount them together directly with pin headers for a much flatter profile.
   

2. Get the micro RX working with an existing Arduino PPM library. I nearly got it working with this library, but I was doing something wrong, because when I powered up the motors, the throttle and yaw signals would swap values with each other intermittently (Yipes!)

One I've done that, I'll do a proper build post, then start comparing flight times and current draw against a COTS board. No data on that yet, but my impression is that the DIY board flies maybe a half or a third as long on the same battery. (I've also ordered a compatible battery  with twice the charge, which should improve things – and this time I ordered the one with the correct polarity!)

Meanwhile, the firmware is on github if you want to look it over.

This video shows a test flight of the HackflightSim quadcopter flight simulator, with a new feature: a simulated "companion board" (Raspberry Pi, BeagleBone, ODROID) running machine vision code written in Python with the OpenCV library. This software allows rapid prototyping of machine-vision algorithms before deploying and testing them on an actual vehicle. In this simple demonstration, we are running a threshold-based detector for blue components in the image: non-blue pixels appear as black in the detector, and blue pixels appear as white. Clicking the Play button on the simulator starts the simulation and then launches a Python script that reads successive images from a simulated belly camera on the vehicle. By grabbing the image bytes directly from the V-REP simulator using a C++ plugin (rather than the slower vision sensor built into V-REP), we get an on-the-fly resizable camera image and realistic update rates of 35-40 frames per second. The C++ firmware flying the simulated vehicle is the same as what we run on our actual quadcopters, and the Python code running the machine vision algorithm can likewise be deployed on an actual companion board with no modification.

In earlier posts I wrote about  PyQuadSim, a Python-based flight simualator built on top of the Virtual Robot Experimentation Platform (V-REP). Although PyQuadSim enabled some pretty cool projects, it relied on a client/server model that limited the simulation speed to an unrealistic 10Hz, and required configuration steps that made it difficult for people to use. It also used an ad-hoc stabilization algorithm that was not easy to relate to actual firmware code.

So as an upgrade to the simulator I naturally thought of using actual firmware like the minimal Hackflight firmware I wrote about in my previous post. The result is HackflightSim, which incorporates this firmware as a V-REP plugin, allowing 100Hz updates -- still slower than the cycle time of Hackflight and other firmware, but fast enough so that the firmware can be tweaked to work with the simulator.

This brief video shows a test flight of HackflightSim. Like the Flip32 flight controller on my quadcopters, the simulator has a green LED that is solid during the initial gyro-calibration phase and flashes when the pitch or roll goes above a critical threshold (25 degrees), and a red LED that indicates whether the vehicle is armed.

HackflightSim currently requires Linux to buld the plugin, and a FrSky Taranis transmitter with USB cable. If there is enough community interest (and time!) I will try to support other OSs and controllers.

Instructions here

This is a follow-up to yesterday's post.  As promised, I wanted to provide some information about the C++ firmware running on this little quadcopter.

Following in the Baseflight / Cleanflight / Raceflight / Betaflight naming tradition of the 32-bit Multwii lineage, I call this firmware "Hackflight".  Hackflight is simple C++ firmware for inexpensive quadcopter flight controllers. It is geared toward people like me who want to tinker with flight-control firmware, and use it to teach students about ideas like inertial measurement and PID tuning. 

If you are in the 99% percent of users who just want to get your vehicle flying without getting into firmware hacking, I would stay away from Hackflight. Go with Cleanflight (great for getting started when you're on a budget) or the Ardupilot suite (the gold standard for sophisticated mission planning with waypoint navigation and the like). In addition to big user communities and loads of great features, these platforms have safety mechanisms that Hackflight lacks, which will help avoid injury to you and damage to your vehicle.

Hackflight currently works only on STM32F103 flight-controller boards (Naze32 and clones like Flip32, MultiRC, etc.) The original Hackflight idea was to write firmware for flight controllers built from the Arduino / Teensy hardware. As you'll see, the code follows the Arduino design pattern of a startup() routine that calls the init() method of a few objects (IMU, RC, PID, Board) and a loop routine that calls the update() method and other methods of those objects. But with all the features you can now get onboard an inexpensive STM32F103 board (barometer, magnetometer, flash RAM), there seems little point in building your own board, unless you're interested in hardware hacking. So Hackflight currently supports only the STM32F103 boards, while keeping the Arduino design principles. The code provides abstraction (through the Board class) that should make it easy to use on other boards.

For more info and download, see the github repository.

I wanted to try my hand at a true "DIY" project, designing and building my own micro quadcotper frame and writing my own firmware in C++.  In this post I will describe the frame and build; in my next post I will talk about the firmware.

Excluding stuff I had lying around the shop, (heat-shrink tubing, EC-3 connectors, velcro, cable ties, etc.) the cost came to just under $170:

• 3D-printed frame "free"!

• Flight Controller: Flip32 (Naze32 clone), with Spektrum RX mount removed to expose 3V. $15

• Receiver: MicroFrX by Curtis Fissel.  $16.

• ESC: BLHeli 4 in 1 ESC - 12A, with male EC-3 soldered on. $34

• Motors: RMRC Black Series 1306 3300kv ( 2 CW, 2 CCW) $56

• Props: 3030x3 glass composite $8
  • HQPROP 3030X3 - BLACK CW
  • HQPROP 3030X3 - ORANGE CW
  • HQPROP 3030X3 - BLACK CCW
  • HQPROP 3030X3 - ORANGE CCW

  • Battery: Turnigy nano-tech 1000mah 2S 25~50C Lipo Pack $8

  • Fasteners:
    • M3 nylon machine screws (20mm, cut down to around 5mm) (4) $8
    • Nylon 6/6 Male-Female Threaded Hex Standoff, 4.5 mm Hex Size, 5 mm LG., M3 Thread (8) $13
    • Dese nuts (4) $11

Here's the frame, fresh out of my LulzBot Mini printer:

Before adding any components, I inserted a velcro tie to keep the battery in place:

Here's the amazing RMRC BLHeli 4-in-1 ESC with motors and EC-3 battery connector soldered on:

Here's the BLHeli mounted on the frame.  I should've used the thinner (4.5mm) standoffs on top and bottom to avoid damaging the circuit!

Next it was time to make a custom jumper for the tiny 3V FrSky-compatible CPPM receiver, which is not 5V tolerant.  I un-soldered the 3V Spektrum header from the Flip32 and jury-rigged a little three-pin jumper connection:

Here's the super-tiny FrSky-compatible receiver from Curtis "Beef" Fissel (of Beef's Brushed Board fame). This photo shows the receiver after I soldered on a three-pin header, solder-bridged the bind pads, connected it to the Flip32, powered the Flip32 through the USB port bound the receiver to my Taranis, and un-soldered the bridge:

You can see the completed project at the top of this post.  Although I could have used Baseflight or Cleanflight to configure the board, I used my own C++ firmware, adapted mostly from Baseflight.  Having never configured such a tiny vehicle before, I struggled for a while with the PID settings.  Eventually I just divided all the default values by two, and that worked fine, giving me the smooth flight shown in the video.

In a follow-up post I'll discuss the C++ firmware that's flying the 'copter.

This video shows me checking the size of the flash RAM (memory) on an MRC Naze32 (ARM STM32F103) flight controller from MultiRC. Because I am loading my own firmware onto the board, I have to short the bootloader pins on the board, via some male jumper wires I soldered on.

These inexpensive FCs with onboard flash RAM are sold for use with the Blackbox logging feature in Cleanflight, but I wanted to re-purpose the RAM for developing algorithms like SLAM onboard the FC. As advertised, the board has 8 MB (eight megabytes, or 64 megabits) of flash memory.

Borrowing firmware code from Cleanflight, and the original Baseflight firmware on which it's based, I've created a simple API for this kind of firmware hacking:

https://github.com/simondlevy/BreezySTM32

As you can see by looking at the code, the API allows you to write very short, Arduino-like programs for specific tasks like this. There are also examples for the classic blinking LED, I^2C sniffing, and ultrasonic sonar.

This video shows the 250mm quadcopter from my previous post, holding altitude by means of its MaxBotix MB1242 ulatrasonic rangefinder (sonar). The Flip32 flight controller onboard is running a modified version of the Baseflight firmware to support the MB1242.  Original Baseflight requires a barometer for alt-hold, and then fuses it with data from an HC-SR04 sonar if one is available.  So I removed the baro requirement and replaced the HC-SR04 code with code that uses the MB1242.

The real-time plot (made in Python with RealTimePlotter) shows AGL (Above Ground Level) in centimeters (blue) as well as the desired altitude that locks in when I flip a switch on the transmitter (red). The desired altitude starts out with its value from a previous run, which has no effect until I hit the switch, at which point it resets to the current AGL. The bottom plot is the PID (Position / Integral / Derivative) -based correction to the throttle in support of altitude hold, which likewise has no effect until I hit the switch.

Although the vehicle holds low altitude (here, around a meter) pretty well, the values being displayed are quite a bit off from what you expect to see (vehicle is holding AGL at around 100cm, though reported AGL is 60cm, with locked-in AGL at 40cm). At higher altitudes, big transient jumps in the sonar-measured AGL can cause the vehicle to jump slightly. So my next steps are to (1) figure out the discrepancy between the observed behavior and displayed signals; (2) add an Extended Kalman Filter to smoothe out transient jumps in the sonar signal.

In a recent post I showed how to get live IMU telemetry from a Flip32 flight controller using an inexpensive Bluesmirf Bluetooth modem from Sparkfun. After getting that to work I figured it was time to branch out to some external sensors.

I played around a bit with PX4Flow and LidarLite but thought that for doing something like altitude hold it would be safest to stick with an inexpensive, high-quality ultrasonic sensor like the MaxBotix MB1240, which MaxBotix suggests for  quadcopter applications and other environments with lots of vibration and potential electrical noise. However, based how easy it was to use the Flip32 to read I^2C signals, I wanted an I^2C sensor instead of one that uses TTL, analog voltage, or PWM as the MB1240 does. So I was delighted to find the MB1242, which is the same sensor but with I^2C.

As you can see in the photo below (with the Bluesmirf removed), the same four-wire cable that I used for the Bluesmirf / UART connection was perfect for the I^2C connection, and this time I didn't even have to clip and solder it! (though I did use a Sharpie to color the ground wire black for safety):

Here's a side view showing both the Bluesmirf and I^2C connections:

Having designed and 3D-printed a simple mount for the LidarLite and stuck it firmly to the lower plate with E6000 ("Goop"), I decided to keep that plate attached and print a mate for it to carry the MB1242. Since the MB1242 didn't have enough room for Dee's nuts, I used an additional pair of nylon M3 standoffs to secure the MB1242 to the new mount:

This video shows a test flight of this rig, in the usual "Dronehenge" aerodrome in the Washington and Lee Science Center. As with the IMU hack, I wrote a Python program to display the Bluetooth AGL telemetry in real time. (The Python package I used for the display is on github for anyone who wants to try their hand at this kind of live telemetry visualization.) To support the MB1242 I had to modify the Baseflight firmware to read I^2C from the unit and send it to the UART. This amounted to around 20 lines of C code (send a request byte to the MB1242, then 10 msec later read the two  bytes for AGL in cm). On the laptop, our MSPPG compiler made it easy to generate code that parses the new sonar message from the Bluetooth stream.

Of course, my real goal is to modify the firmware to support altitude-hold based on the sonar AGL. To get started on that I used PyQuadSim, our Python-based quadrotor  simulator, with a simple PID controller to keep the altitude steady. If I can get that working, I will post a link to the modified firmware for others who want to try it.

Since posting the BreezySLAM package for Python and other languages, I've received several inquiries about supporting the Lidar unit on the XV-11 vacuuming robot from Neato Robotics.  Although I have an XV-11 and a Python package for it as well, I was reluctant to pull the Lidar unit from it to put on an MAV or other robot.  Now, thanks to GetSureal.com, I was able to get the XV Lidar with a handy Teensy USB adapter built in (which makes clever use of the popular Teensy Board).  So I wrote a little acquisition module for the XV Lidar, and added SLAM support for it in BreezySLAM.  

This video shows a Flip32 flight controller ($15 from re readytoflyquads.com) onboard a min 250 quadcopter, sending IMU attitude telemetry (pitch, roll, yaw) to my laptop via a Bluesmirf Bluetooth module ($35 from sparkfun.com). The Bluesmirf connects to the Flip32's UART via a four-pin jumper cable, also from Sparkfun ($.095). On the laptop, a Python program parses the IMU messages using code auto-generated by our MSPPG parser generator (https://github.com/simondlevy/MSPPG), and displays the vehicle's attitude using Tkinter.

Here's a more detailed picture of the Bluesmirf wiring.  I used a Sharpie to color one of the wires black, since it's supposed to be GND. A piece of clear 1/2" heat-shrink tubing (from McMaster Carr) helps insulate and stabilize the wiring.

In my last post I showed a Flip32 flight controller talking to a PX4Flow unit using the I^2C protocol.  Once that was working, I wanted to mount the PX4Flow to a vehicle and make a more permanent cable connection.

For the mount, I used Tinkercad to design a simple rectangular plate with four recessed screw holes, plus a small rectangular hole to pass the I^2C cable through.  Four M3 nylon machine screws and standoffs, both 5mm size, fit snugly into the holes, after which I mounted the plate permanently on the rear  bottom plate of my 250mm H-quad using E6000 adhesive.  

To make the cable, I soldered one end of the four-position cable from 3R to a four-pin jumper cable from Sparkfun.  To keep the color-coding sensible, I covered the red jumper wire with black heat-shrink tubing, making it the ground (leftmost) of the four I^2C pins on the Flip32.  Then the orange wire was +5V, the yellow SCL, and the green SDA:

Once the PX4Flow unit was mounted and wired, I found that the vehicle's legs were too short.  So I designed and printed some extra-long legs, allowing the unit plenty of ground clearance:

My ultimate goal is to modify the Flip32's Baseflight firmware so it uses the sonar and optical-flow readings from the PX4Flow to perform altitude- and position-hold.  Before doing that, I plan to collect in-flight data from the PX4Flow, by attaching a Bluesmirf modem to the Flip32's UART pins and sending a new MSP message from the Flip32 to a Python program on my laptop.

I added a few lines of code to the Baseflight firmware to get optical-flow velocities and sonar altitude from a PX4Flow unit connected to a Flip32 flight controller over I^2C.  In the video you can see the readout on the laptop showing the computed X/Y flow velocities (meters per second) and distance (meters), multiplied by 1000.