I have been busy, but not posting. I can't believe it's been nearly five years since I posted last!

In the mean time I worked for a while on the LibrePilot project, which is one of the offshoots of the OpenPilot project. Mostly I improved the firmware for the OPLink modem. Recently the LibrePilot project has died down, and there's not a great deal of activity developing it, although I still believe it's a great platform for UAV research and development.

For many years I've been interested in combining a Linux-based CPU with flight hardware to make it easier to experiment with advanced flight controls and navigation. My ideal platform would contain a CPU running some form of Linux with a micro-controller that performs the low-level stabilization.

That's not such a big deal anymore, since it's been done many times, but over the years I've experimented with building a nano-copter based on the now-defunct Intel Edison. I've also designed carrier boards for the NanoPi Neo Air (and family) and the NanoPi Duo.

More recently I've been experimenting with the Raspberry Pi family.The Raspberry Pi Zero W is a nice board, but not quite as advanced as some of the other boards. Fortunately the Raspberry Pi family has a great deal of support by the community, so it's relatively easy to find solutions for pretty much everything you could want to do with them.

One aspect that they excel in (compared with other boards) is support for hardware acceleration, especially in video encoding/decoding.This makes them ideal for digital video for FPV, which is my most recent project.

Digital FPV video on the Raspberry Pi is not new, and there are multiple projects that support it, but I have been working on similar project for low-latency audio decoding/encoding, so I wanted to tackle it myself. What I currently have working is low-latency encoding of the camera on a Raspberry Pi Zero W to H.264, which transmission over UDP to a decoder that also will run on a Raspberry Pi (or Windows/Linux) and display the video either in a window or via the Raspberry Pi composite video or HDMI (untested) port. I also support Mavlink telemetry to add a full-color OSD to the video.

After working on this for a while, I found out about the Sky Viper quadcopters, which are a line of "toy" quadcopters that support all the way up to fully autonomous flight. At least the higher end models run ArduPilot, with all the capabilities that that entails! I purchased a Journey for less than $60, and they sell on Amazon for less than $100, which is an amazing price for such a capable quad-copter!

​This is a picture of mine:

I also purchased a "for parts" Journey from Ebay that I felt comfortable tearing about to see if I could use the guts in something else. It looks very promising!

This is the guts:

That includes the flight controller board (center), a GPS with integrated magnetometer (center bottom), and an amazing camera/WiFi board (left). The flight controller board includes an F412 MCU, and and (I believe) ICM-20789 IMU, and CC25000 radio. The camera/WiFi board has a Sonix MCU and WiFi module. It talks to the flight controller via a UART, using the Mavlink protocol, and sends Mavlink telemetry over the standard UDP port and video over a standard RTSP link.

Most recently I've been adapting my FPV/OSD softare to support the Journey, which turns out to be fairly simple. I currently support low-latency video from the Journey along with Mavlink telemetry, both over WiFi, with and integrated OSD, all decoded and displayed on a Raspberry Pi.

The current version of the code (along with other stuff) can be found on github.

Well, that's enough for now. More updates to come.

In order to debug the Pixie Flight Controller I needed to at least create an adapter that breaks out the SWD pins on the expansion port to a debugger.  Instead of doing that I decided to create a custom debug board that would both debug the Pixie and serve as a compact and easy to use debugger for other projects.

In the past I've used several JTAG probes.  More recently I started using STM32 discovery boards for SWD debugging.  The discovery boards work well, but they're pretty bulky for their purpose, so I've been looking for a more compact alternative.  I tried several of the small st-link compatible adapters on ebay.  They generally work, but I've had some issues with them, and who knows where the firmware comes from.

Recently I ran across the Black Magic Probe.  This is both an open source software and hardware project that supports debugging STM32 as well as other Cortex MCUs.  Unlike most other debuggers, it doesn't require any external software, such as OpenOCD, etc, because it implements the GDB extended remote interface in the firmware.  It presents two CDC serial ports, one of which is the GDB interface, and the other is a direct link to an on-board UART.  This allows one to connect GDB directly to the first CDC serial port for flashing firmware and debugging, and connect a terminal program to the other for debug output, etc.  I find it to be very elegant.

You can buy an official Black Magic Probe from several distributors, but I decided to try it out by trying to flash the firmware to one of the many st-link clones that I bought on Ebay.  It turns out that it is very easy to port to most any STM32 device, and it actually works pretty well on the Ebay clones.  I may document how to do that in a later post, but it's probably easier to just buy an official Black Magic Probe, especially if you don't already have one of the st-link clones.

After trying out the BMP firmware I decided that it wouldn't be very hard to just build a debug board similar to the BMP that would connect directly to the Pixie, and could be used in other projects as a small debugger.  That's where Pixie Debug came from.

Above you can see a picture of the top side of the Pixie Debug board.  It contains:

• STM32F103 MCU
• UART1 (can be passes through to USB serial interface).
• USB interface
• Standard 0.05" JTAG connector
• An SWD port for connecting to boards other than the Pixie.
• Pixie expansion port that connects to SWD and USART6 on Pixie.  It also connects to the SPI, which could be useful for something.
• 4 LEDs

The bottom of the board is essentially empty, so it's a one-sided board.

The schematic is very similar to the original Black Magic Probe, with the addition of the Pixie expansion header, etc.  I made the form factor the same as the Pixie both because it was easy, and as a first test of using the expansion header.  The next version will likely be a more conversational form factor with 0.1" headers.

I am very happy with the Black Magic Probe firmware, and would recommend it to anyone who normally uses GDB to debug and develops for the supported MCUs.

One of the boards that I've been working on over the last couple of months is an updated Pixie IMU / flight controller.  In the previous iteration I put very little I/O on the main board, intending to make a few I/O boards for various configurations.  On this iteration I reverted back to a more traditional design, which includes many communications options as well as an expansion port for connecting peripheral boards.

Version 0.96 of the Pixie board includes the following:

• 24x24 mm board, with 20 mm hole spacing
• 2 grams
• STM32F415RG MCU
• MPU-9250 IMU (via SPI)
• MS5611-01BA03 Pressure Sensor (via SPI)
• MX25L3206E 32 Mb SPI Flash
  
• USB OTG
• 10-pin servo port, supporting 8 output(/input) channels
• USART1 port
• USART3/I2C port
• USART2 port with flow control.  Also supports 4 ADC.  Can also serve as a combination Voltage / Current / Sonar / Rx input port.
• CAN port with 3.3V transceiver
• 12 pin (dual 0.05") expansion header, supporting SPI2, UART6, and SWD.  Also contains CAN2 (without transceiver).
• Expansion header outputs both battery/USB voltage and 3.3V (up to 500mA total current).

Above you can see the top of the board, containing the MCU, IMU, pressure senser, and flash.  The expansion header (yes it's misspelled on the board) can be seen on the left.

Above you can see the bottom of the board.  It's pretty crowded with connectors, but most of the components fit on the top of the board, so it's not too crowded.  The bottom includes the voltage regulator and CAN transceiver.

In the picture above you can see a size comparison between the Pixie and a an OpenPilot Revolution board, which is 35x35 mm.

So far I've been able to load a version of a TauLabs bootloader and firmware and verify that the MPU-9250 and SPI flash work as expected.  Unfortunately the board has a minor defect that destroyed the chip select line on the pressure sensor, so I'm currently unable to test that.  I still need to test the CAN interface and all the I/O ports.

For some reason the magnetometer is flaky on the MPU-9250.  Sometimes it is detected and sometimes not.  I suspect the MPU-9250 is just bad, but I need to replace it to know for sure.  It's been re-flowed a couple of times, so it might be just heat damaged.

As soon as I have the firmware fully configured I plan to flight test it.  I have a couple of options for mounting it, as I'll go over in a future post.

So, my previous blog when up in a puff of bits when my VPN host went belly up.  Of course I didn't have any backups, so I'm starting a new blog here.  I hope to have better luck on a hosted blog site!

I've been busy over the last several months updating some of my previous designs, and coming up with new boards to test and evaluate.  Over the next day I plan to post status on all of my current projects and where I plan to go from here.