Big Quad Deck

So last week we received the first prototypes of the Big-quad-deck. With this deck it will be possible to transform the small Crazyflie 2.0 into a flight controller of a bigger quad. It does this by using some of the deck port pins to drive brushless motorcontrollers. This has been explained how to do using a prototype board in a previous post. For those that like it to be more convenient the Big-quad-deck will be a good choice. This will also use the one wire memory so that it will automatically detect the big-quad-deck board and configure it, that is the idea at least :-). So currently the dynamic motor driver is one of the things we are working with. Well that and fixing the layout of the board as there was a major mistake of mirroring the deck port connectors… no blaming :-)

iPhone bootloader

The bootloader is finally implemented on iPhone. The change have been pushed to github and will be released before the next firmware release. The GUI is simple and hopefully clear enough:

The iOS app fetches the latest firmware directly from GitHub and the flashing operation takes about 10 minutes. All new code written for the app is written in Swift, there is an ongoing work to cleanup the app architecture to make it easier to implement more advanced functionality like log/param. We are actually thinking of converting the full app in Swift to make it easier to work with.

The next step is to implement the bootloader in the Android client, this will be one of our main tasks for next week.

We have had a lot of deck ideas for the Crazyflie 2.0 but not much time to finish anything, now we finally took the time to order batch PCBs at seeeds so we though we could show a bit what we are working on. Our idea is to order during the summer while some of us are in vacation so that we have all the hardware available when everyone comes back.

One deck that we are working on for a long time is the GPS deck:

We had a prototype last summer but we never managed to get it to work properly: the antenna of the module we used relied too much on the ground plane and was disturbed by the proximity of the Crazyflie. Now we are using a more traditional chip-antenna which, we think, might work better in our design. We also added a u.fl connector to add an external patch-antenna in case the chip antenna is not good enough.

Lately we posted about connecting Crazyflie to a bigger quad frame to use it as a flight controller. We made an adapter deck for this purpose:

The deck can be on top or bottom of the Crazyflie and has output for 4 motor controller, a SPPM input for RC receiver, monitoring input for battery current and voltage, I2C connector and finally a GPS connector. We tried as much as possible to use standard pinout for the connector. Finally this board has holes spaced at 30.5mm, which is common for attaching controller boards.

Some time ago we have seen an interesting kickstarter that implemented local positioning, the pozyx project. While looking at it we found that the transceiver they are using is available, it is the DWM1000. We are really interested about this technology so we made a deck out of it:

The DWM1000 tranceiver allows for time-of-flight measurement which would allow to make a local positioning system. This is something we have been looking at for a long time. Of all the prototype board this is the one that might take the most time to develop though, as the software work will be extensive.

Another board we wanted to do for a while is an Intel Edison adapter deck:

One thing that delayed us to make this board is the use-case: the main use-case we see for Edison is to connect a camera but the Edisson does not have the MIPI interface required to connect a small and lightweight camera. On this deck we wired the USB port both to a uUSB connector and to breakout pins giving options on how to connect a USB camera.

Finally for the end we keep the simplest but very useful for development FTDI cable adapter deck:

On the middle of this deck can be connected a standard 3V3 FTDI cable, and jumper allows to connect the RX and TX pins to UARTs on the deck port. It can be used both to debug the Crazyflie 2.0 firmwares and to debug other decks (for example to talk to the GPS deck).

We will keep you updated when we have received and gotten to work the boards (some will be much quicker that other as you can imagine).

While we where in the US we finally received our long-awaited HackRF Blue. Our plan was to use it to sniff the Crazyradio and Crazyflie communication in order to be able to better debug the communication.

HackRF Blue is a lower cost build of the open source HackRF One. It is a Software Defined Radio (SDR), you can think of it as a sound card for radio. It allows to observe and manipulate radio signals from ~1MHz up to 6GHz within a maximum bandwidth of 20MHz. We use it with GNU Radio on the PC which is a signal processing library that contains all we need to do using SDR. Gnuradio has a nice GUI, the Gnu Radio companion, that allows to start testing without having to write code (this GUI actually output a Python program). Getting into SDR is not easy, we have been looking at the Michael Ossmann’s SDR videos (I suggest you look at them if you want to learn about SDR!) and it helps a lot understanding what to do. In this post I will try to briefly explain the step to detect and decode the Crazyradio nRF24 signal. We wrote an howto in the wiki if you want to set up an nRF24 sniffer.

To test the HackRF I just created a very simple python script that sends 10 packets per seconds with Crazyradio:

from crazyradio import Crazyradio
import time

cr = Crazyradio()
cr.set_channel(26)
cr.set_data_rate(cr.DR_1MPS)

while True:
    cr.send_packet((0,1,2,3,4))
    time.sleep(0.1)

Then we just tune HackRF to the Crazyradio frequency, and we can see the GFSK signal!

GFSK is a kind of Frequency Modulation. Which means that it should be a cosine wave of constant amplitude. So calulating the magnitude of the complex signal allows to locate data packets by setting the scope trigger:

Now that we can synchronize on a packet, we can add a filter and a quadrature demodulator to demodulate the fm signal and show the data packet (in green):

The preamble (series of 0101010101) is clearly visible followed by the radio address which is 0xe7e7e7e7e7. Now the ‘only’ things left would be to decode the packet. Hopefully for us Cyber Explorer already did the hard work and all we have to do is to send the demodulated data in a unix fifo and send the fifo in the decoder. This procedure is explained in the wiki. As a result we receives the packets:

As a conclusion we found that with the current setup we have a lot of packet lost. We also have a sniffer made out of an nRF51 evaluation kit and it gets much more packets so it is still preferred to analyse protocols. However we can still enhance the SDR algorithm and the 20MHz bandwidth of the HackRF will allow us to sniff on many channels at once, making it perfect to debug channel hopping when we implement it for the Crazyflie.