Quad Update #7

In my earlier post I said that the bootloader for the KroozSD was luftboot, but in reality it’s available here. The version contained in that tree doesn’t appear to be fully up to date as there is no CRC and the strings reported by the device are different, but I’m assuming the current code is similar.

While I realise I could simply switch to a different laptop, I can’t help but feel this should be a simple enough problem to fix and as I’m always interested in learning another wee adventure begins!

USB Debugging

Having gone from working USB transfers to non-working USB transfers I’ve been doing a little bit of debugging of the USB. The stm32_mem.py script uses PyUSB so my first stop was to enable additional debug information for the library. The library authors have made this very easy.

$ export PYUSB_DEBUG=debug
$ ./stm32_mem.py ...
2016-05-21 10:05:06,719 DEBUG:usb.backend.libusb1:_LibUSB.__init__()
2016-05-21 10:05:06,721 INFO:usb.core:find(): using backend "usb.backend.libusb1"
2016-05-21 10:05:06,721 DEBUG:usb.backend.libusb1:_LibUSB.enumerate_devices()
2016-05-21 10:05:06,721 DEBUG:usb.backend.libusb1:_LibUSB.get_device_descriptor()
2016-05-21 10:05:06,721 DEBUG:usb.backend.libusb1:_LibUSB.get_device_descriptor()
2016-05-21 10:05:06,721 DEBUG:usb.backend.libusb1:_LibUSB.get_device_descriptor()

The level of information is impressive and allowed me to check that no additional calls had been made and that what I thought was taking place was reflected in the calls being made. Having checked that the next level was to look at whether there were other calls being made by the system. For this I turned to usbmon.

The Ubuntu kernel already has the basic support needed, so the first step was simply to load the usbmon kernel module and verify that it was available.

$ sudo modprobe usbmon
$ ls /sys/kernel/debug/usb/usbmon
0s  0u  1s  1t  1u  2s  2t  2u

Finding the bus number was easy enough.

$ dmesg
[25450.332261] usb 1-2: new full-speed USB device number 34 using xhci_hcd
[25450.462462] usb 1-2: New USB device found, idVendor=0483, idProduct=df11
[25450.462505] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[25450.462510] usb 1-2: Product: KroozSD CRC
[25450.462514] usb 1-2: Manufacturer: S.Krukowski
[25450.462517] usb 1-2: SerialNumber: Bootloader

So, bus #1 was where to look, but which endpoint did I need? The usbmon documentation explains that endpoints ending with ‘u’ are the best ones to use, so ‘1u’ endpoint was what I wanted. Getting the data into a file so I could analyse it turned out to be as easy as

$ cat /sys/kernel/debug/usb/usbmon/1u > krooz.mon

Running the stm32_mem.py script again (in a different terminal) resulted in a capture file that contained a lot of information so I used CTRL-C to stop the capture. Analysing the data turned out to be simple enough as well thanks to Virtual USB Analyzer. The app wasn’t installed by default but was in apt, so installation and usage was simple enough.

$ sudo apt-get install vusb-analyzer
$ vusb-analyzer krooz.mon

The app displayed the information needed, but without DFU support built in some interpretation was required.

Not an issue…

One of the recurring entries in dmesg has been

[25457.004284] usb 1-4: usbfs: interface 0 claimed by btusb while 'python' sets config #1

Looking at this in more detail it’s not an issue and merely informing me that the discovery phase of the stm32_mem.py script has attempted to claim ownership of my bluetooth device (which has a DFU endpoint). It would be nice if PyUSb had a way to check whether a device was already claimed, but I couldn’t find anything that would allow such a check. It does remove one source of concern.


Everything I looked at showed me that the script does exactly what I expected it to and there is no interference from anything else on my system. Not a big surprise and certainly what I expected, but it also illustrates how easy it can be to get the additional information I wanted. As the scripts haven’t changed I can rule that out as the source of problem, which would imply that the bootloader code has an odd bug in it somewhere. Figuring out what and how to fix it will be much harder.

The bootloader code I have looked at all appears to be simple enough that there is only one way the manifestation stage can be triggered.

static int usbdfu_control_request(usbd_device *usbd_dev, 
                                  struct usb_setup_data *req, u8 **buf,
		                  u16 *len, 
                                  void (**complete)(usbd_device *usbd_dev, struct usb_setup_data *req))
    if ((req->bmRequestType & 0x7F) != 0x21)
        return 0; /* Only accept class request. */

    switch (req->bRequest) {
        case DFU_DNLOAD:
            if ((len == NULL) || (*len == 0)) {
                usbdfu_state = STATE_DFU_MANIFEST_SYNC;
                return 1;
            } else {

This is meant to be triggered by an empty download request, but somehow is being triggered following a 2050 byte download. The function is a callback supplied to the libopencm3 usb setup code,

                                   USB_REQ_TYPE_CLASS | USB_REQ_TYPE_INTERFACE,
                                   USB_REQ_TYPE_TYPE | USB_REQ_TYPE_RECIPIENT,

The sequence leading to the crash is always the same.

DFU_DNLOAD 2050 bytes
DFU_DNLOAD 2050 bytes of data

In all my debugging I see that the download transfer completes for the erase and then the data transfer, and after a few transfers (which is normally 3) working as expected the manifestation stage is triggered. Answers on how to further debug are welcomed on postcards (or emails) 🙂

Quad Update #6

#6! Who knew I’d get this far and still not have a flying quad? At least I’m getting closer and learning a lot along the way…

Satellite Receiver

I’ve updated the spektrum_serial.py code to have code that now converts the split channels into appropriate values and having watched it what it produces seems sane. Using this is a basis I changed the code in paparazzi to do the same conversions and rebuilt. All was well and so the next step was to flash the new firmware to the board – as usual.


The flashing process is sometimes a little fussy and from time to time needs a few attempts, but after 30 or so attempts it was still not working. This is very unusual and checking the board it seemed as though the firmware I had flashed a while back has been removed – I have an empty board ready and waiting for code! The bootloader is still in place and when connected the USB device appears, so it’s just the upload that’s causing the problem. Given I’ve always uploaded using this laptop the sudden change is a little strange.
The KroozSD board uses the luftboot bootloader (or a modified version thereof) and a custom uploader which implements the DFU protocol. Running with debugging switched on didn’t show much, so I dug a little deeper. After adding some code to see the state being returned by the bootloader the problem became apparent (with my additional debug messages).

Using device : ID 0483:df11 S.Krukowski - KroozSD CRC - Bootloader
Programming memory from 0x08004000...
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Download Idle [05]
State = DFU Download Busy [04]
State = DFU Manifest [07]

The DFU process should only enter the final “Manifestation” state when the code is complete and a zero length download is sent. That’s what the DFU specification says and what the luftboot code looks for, so quite why it’s entering it so early is unclear. Each write until then appears to be sent OK and there is no sign of any extra zero byte requests being sent.

What next?

My options appear to be switching to another computer for uploading the firmware, getting an external USB interface that doesn’t cause this problem or figuring out what’s going on and fixing it. Of those I suspect the last may be a little beyond me 🙁 I guess when I have time next week I’ll try again with a different computer.

Quad Update #5

Having spent some more time looking at the Spektrum SPM9246 satellite receiver and it’s output I’ve made some progress. When trying to use this with Paparazzi I’ve had very variable results and it fails to work.

Direct Binding Doesn’t Work 🙁

I’ve been unable to get the binding via the KroozSD board to work with the satellite and watching the output using pigpiod (as detailed Quad Update #4) the reason became clear as the simple series of pulses was never visible. I’m still a little unclear why, but after hooking up the RaspberryPi I managed to replicate the required pulse pattern and the satellite receiver went straight into bind mode. Binding to my Spektrum DX8 failed however – probably because the required responses weren’t sent as these would normally be provided by the AR8000. After the failed attempt the receiver was not receiving any information so I restarted the bind process using the AR8000 and all was well again.

As this makes sense and appears logical, I think it’s worth ignoring the possibility of binding my satellite receiver directly from a Paparazzi board.


Every time I bind the receiver the transmitter reports it’s connection as DSMX and 22ms. Given the individual frames are sent every 11ms this means that there are 32 bytes sent per frame, which after removing the 2 byte headers leaves 28 bytes of channel data, or 14 channels available. Watching the data I often see the “split channels” where movements would be reflected across 2 channels for one control. As an example, when the channel data is split idle throttle appears as (output from spektrum_serial.py)

    0    1
 ---- ----
  354    0

Increasing the throttle position results in

    0    1
 ---- ----
  900    0

Increasing it further, results in

    0    1
 ---- ----
    0  500

Every time I see this behaviour the number of bits per channel is 10, whereas when the number of bits per channel is 11 I see a single value. From this I am assuming that DSMX always uses 2048 values and hence requires 11 bit data per channel. If the transmitter/receiver decide to transmit 10 bit data then 2 channels are required to transmit the required accuracy (2 10 bit numbers == 11 bit number) and hence the channels are split. While the throttle data is simple to understand, the other “stick” controls are a little more interesting. The figures below are for the pitch control, but similar results are seen for yaw and roll.

    4    5
 ---- ----
 1004    0

With the pitch fully forward

    4    5
 ---- ----
  320    0

And fully back

    4    5
 ---- ----
    0  657

AUX 1 is a simple toggle switch, but even that is shown across 2 channels.

    8    9                            8    9
 ---- ----   switched from 0 to 1  ---- ----
  342    0                            0  682

AUX 2 is a 3 way position switch, and the values are similarly recorded across 2 channels.

   12   13                           12   13                           12   13
 ---- ----   switched from 0 to 1  ---- ----   switched from 1 to 2  ---- ----
    0  682                            0    0                          342    0 

AUX 3 is a rotary switch, so starting with it at the 7 o’clock position,

   14   15                              14   15
 ---- ----   turning fully clockwise  ---- ----
    0  682                             342   26

These are just some values I grabbed today, but they do show the range of values that I have been seeing. Switching off the transmitter and then switching on again (while still observing data) sometimes results in the data being sent changing from 10 bit to 11 bit which then results in single values being reported (AUX 2 was at position 2 and AUX3 at fully clockwise position)

    0    1    2    3    4    5    6    7
 ---- ---- ---- ---- ---- ---- ---- ----
  354  998 1006 1006  342 1706  342  342

Changing to full throttle position, AUX 1 moving from 0 to 1 and AUX 2 moving to position 0 resulted in

    0    1    2    3    4    5    6    7
 ---- ---- ---- ---- ---- ---- ---- ----
 1698  998 1006 1006 1706 1706 1706  342

With AUX 2 in position 1 and AUX 3 at the 7 o’clock position,

    0    1    2    3    4    5    6    7
 ---- ---- ---- ---- ---- ---- ---- ----
 1698  998 1006 1006 1706 1706 1024 1706

The pitch value (channel 2) changes from 322 at fully forward to 1681 fully aft.

Going Forward

Every time I switch on my transmitter it starts off sending 10 bit data and so I have to deal with the split channels. Until I can reliably detect and convert that data into the single values that are needed I suspect it will never work reliably with paparazzi. The challenge is to convert this 10 bit data

    0    1    2    3    4    5    6    7    8    9   10   11   12   13   14
 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
  354    0  998    0 1006    0 1006    0  342    0    0  682    0  682  939

into these 11 bit values

    0    1    2    3    4    5    6    7
 ---- ---- ---- ---- ---- ---- ---- ----
  354 1003 1004 1011  342 1706 1706  936

Transmitter Settings

The other option I have is to change the transmitter setting for the frame rate to force 11ms updates. Hopefully this will cause the data to be always sent as 11 bit and hence the problem will no longer be an issue. I’ll try this soon and see what happens.

UPDATE – I tried using the 11ms and DSM2 option under the Frame Rate settings menu and from what I observed neither makes much difference and the behaviour doesn’t change, so I have reverted back to the default settings.


The small python script I have written to allow me to watch the output from the satellite receiver is now available on github. As usual, any comments, suggestions welcome to improve it.

Quad Update #4

Following on from my experiments with the radio control receiver I still found myself unable to simulate the binding process. Everything I’d read suggested that a series of pulses needed to be sent just after power up, but the code in paparazzi that did this didn’t work for me.

Capturing the pulses

The starting point was using the existing AR8000 as when this is powered up with a bind plug inserted and the satellite receiver attached both go into bind mode (rapid flashing of their orange lights). It was obvious that the AR8000 sent the pulses to the satellite to trigger this, so by watching the signal line I should be able to see them. The next question was how.
Bring out the RaspberryPi 🙂

Both receivers are happy at 3.3V and the GPIO pins on the RaspberryPi are also 3.3V, so that part was easy. Using the +3.3V and GND pins supplied power and after some surgery on a cable I ended up with this (apologies for my poor drawing skills).

Bind signal setup

The next step was to watch for the signals.

pigpiod and piscope

While looking for a way to capture the changes in signal I came across a post detailing using a daemon and client to do that exact thing. The daemon is pigpiod which needs to be installed and running on the RaspberryPi (obviously). Downloading, building and installing were very easy. Running the daemon proved to be as underwhelming as I had hoped – it just sat and did it’s thing 🙂 The daemon allows the output of GPIO pins to be monitored, but the data can be sent remotely, making it very flexible.

I decided to run piscope on my laptop, so grabbed the code, built and then ran it. Here I did hit a minor surprise when I was greeted with a segfault. Trying the usual command line options for help resulted in the same response. Looking at the instructions on the site provided the answer.


Now I was greeted with a the application running.

piscope running

I opted to only have the GPIO pin I was using selected (Misc > GPIOs) shown and made sure that the Live feed was running.

GPIO selection. A Select All/Select None option would be nice :-)


Powering on the AR8000 with the bind plug inserted resulted in a series of pulses. Finding the correct scale and position to look at these in the piscope app took a few attempts but with some experimentation I had a screen showing what I wanted. There were 9 pulses sent, each was 120us long and the gap between them was 120us. This agreed with the code I had seen which meant I was a little confused why the binding wasn’t working when attached to the autopilot board. Once the binding was complete, the usual flow of information was visible and the 11ms separation of frames was very evident.

Having never thought about using the RaspberryPi this way before, I’ve been pleasantly surprised by how straightforward it was.

pullup not pulling up?

Paparazzi allows you to have a “bind pin” which functions much like the bind plug for the AR8000 – it starts the bind process. I had this setup but looking at the code revealed that the bind code was always being executed, even if the bind pins weren’t activated. Hmmm. More investigation revealed that the function call that was meant to activate the pin and leave it “pulled up” wasn’t doing that so the pin was always being sensed as clear. Easy enough to find and fix. Once fixed the code was only being executed when the bind pin was activated though I still didn’t get the binding process started.

Single file pull request?

The next step would have been to issue a pull request to the main paparazzi branch, but there’s a previous change that I didn’t want to include in the pull request. I’m afraid my github fu is too weak to know how to do such a thing – answers on a postcard! I tried using the cheery-pick option, but that didn’t work and so now I’m left with my local repo in an odd state of affairs! D’oh.

This is not the GPS you want…

Having made the cable to connect my GPS to the board I was surprised when it failed to work. Further investigation has revealed that I ended up buying the wrong version! So, if you want a GPS from Navilock, the one you want should end with TTL not ERS. All is not lost as I can add a serial interface to the module and will therefore be able to use it in another project. I have found another supplier for a GPS module and it should be here soon.

Molex picoblade

The 1mm connectors really are as fiddly and annoying to use as their size suggests. I’ve managed to make the cables I need but the process hasn’t been without a few failures. The crimpers seem good and are very well made. Arriving wrapped in japanese newspaper was a nice touch 🙂

Quad Update #3

When I started updating the quad I didn’t expect it to be an instant process, but I didn’t really expect it to take as long as it is taking me 🙁 The delays are due to a number of reasons, but the time it takes for some orders to arrive certainly is a large contributor.

Radio Control

I’ve been using a Spektrum DX8 for radio control and with the previous board The individual “servo” leads were connected directly from the AR8000 receiver. The satellite receiver, an SPM9645 was attached but both boxes were required and took up a reasonable amount of space.

Spektrum AR8000 & SPM9645

On the KroozSD board there is no place for the individual servo leads to attach and a UART connection is discussed. This didn’t make much sense initially, but after reading it became apparent that the SPM9645 was a fully fledged receiver and communicated via a serial interface, so the board would only need that one small module. The space savings and simplicity of a single wire are huge advantages, but once again I ran into the issue of how to attach it. I’m not sure what the connection is on the receiver (1.5mm JST?) but the UART connector is a 4 pin Molex PicoBlade, a connector I’m still unable to create. Inside the Spektrum package I did find a cable that allowed me to connect the receiver using the standard 3 pins, and as 2 of the pins are ground and power with a single cable for the communications I started looking at whether I could use that cable and one of the PWM connectors. The answer turned out to be yes, but there is a slight issue. The power supplied via those pins is 5V but the receiver is meant to be used with 3.3V, so while it may be able to handle the voltage it’s not worth the risk long term.
I did connect it for testing and to ensure that the code I was looking at worked, but the results never quite looked right and the values being set didn’t make sense to me. As I like to understand such things more investigation was required!
Longer term I have ordered a small voltage regulator that will allow me to use the pin connection safely, though it could be a while making it’s way here from China!

Can we read it?

There are plenty of articles on the web about the output from the satellite receiver, but many of them deal more with the timing than the values, so I decided to see if I could read the data and see what was going on. Knowing it was a serial stream and that it needed 3.3V I hooked up a Raspberry Pi I had and looked for the GPIO connections I needed to make.

Raspberry Pi GPIO pinouts

The pins therefore needed to be 3.3V (pin #1), GND (pin #9) and serial RX (pin #10). The cable does twist, so I was careful to ensure I connected them correctly 🙂

Raspberry Pi pinouts

Once connected I connected via SSH to the Pi and tried to read data, but nothing appeared and a number of messages appeared about problems with the serial port. Having read about the serial port being used for kernel messages I wasn’t surprised, but the posts I found to correct it didn’t seem to apply. After trying a few different suggestions I eventually came across a post suggesting the raspi-config command, which proved to be the solution. Switching off the option for kernel debug (under Advanced Settings) and restarting the Pi resulted in access to the serial port and data flowing from the receiver. I wrote a small python script and the excellent PySerial module (installed via pip).

Receiver connectedRaspberry Pi

Yes we can!

Now that data was flowing, the next step was to try and interpret it. Thankfully many had gone before me and so I knew what to expect!

The data flowed from the serial port in 16 byte blocks, each of which looked similar.

00 5A 0B E9 2E AA 13 E8 1B F3 31 56 FF FF FF FF
00 5A A1 56 01 62 3A 0C FF FF FF FF FF FF FF FF
00 5A 0B E9 2E AA 13 E8 1B F3 31 56 FF FF FF FF
00 5A A1 56 01 62 3A 0C FF FF FF FF FF FF FF FF
00 5A 0B E9 2E AA 13 E8 1B F3 31 56 FF FF FF FF
00 5A A1 56 01 62 3A 0C FF FF FF FF FF FF FF FF

This was what I had been expecting. 2 bytes of “header” followed by 7 sets of channel information. As the DX8 is an 8 channel transmitter and there are only 7 sets per frame, the repetition of the 2 frames made sense. Looking at details of the “header” I expected the first byte to the dropped frame count and the second byte to contain information about what was to follow, namely the number of bits per channel and the number of frames required.

| dropped frame count    |         |bit|      |frames|
16                                                   0

When I bound the receiver to the transmitter it helpfully told me that it had bound using DSMX and 22ms, which should (according to what I had read) give me 11 bit channel data, hence I expected to find that the transmitter data decoded as 2 frames and 11 bit data – which it did. The next step was to look at the channel data. Each channel is sent as 16 bits and as it was using 11 bits for the data should look like this.

|   | channel ID | Channel value                     |
16                                                   0

The channel ID’s all appeared to be within a range of 0 to 15, though those with an ID of 15 I chose to ignore as that appeared to suggest it wasn’t valid data. As I only have 8 channels this seemed a larger number than I was expecting so I decided to try and watch the values in real time using the small python script I had created. (I’m still refining the code but can put it on github if anyone is interested.)

It turns out that the main 4 channels – throttle, elevator, aileron and yaw – are split between 2 channel ID’s, with the left and right deflection being reported separately. In the case of the throttle this results in the value for channel 0 going up until you reach the midpoint where it drops to 0! Obviously only reading one channel would result in some interesting results so I need to look at combining the values appropriately.


The GPS and it’s cable have arrived and are just awaiting the addition of the connector to attach to the board.



Having played with the STM32 I’ve found myself contemplating using it for some other projects I have planned. Looking around for an easy way to start experimenting I came across the STM32 Stamp which looked perfect for my initial needs, but as my skills aren’t up to constructing one myself, does anyone know where I can buy something similar? I don’t really want a discovery board as I want to be able to use it on a breadboard while I experiment with connecting it.

Quad Update #2

I’ve spent a bit more time with both Paparazzi and the KroozSD board, so these are a few more observations.

NB these ONLY apply to the KroozSD board 🙂


After a good look through I changed the settings to match my configuration, tweaked a few to what I hoped would be more appropriate values and rebuilt. The ESC’s now make the correct noises and the telemetry looks good. The battery voltage being shown is that supplied via the BEC built into the ESC‘s, which is essentially 5V, so I had to adjust the battery warning levels to prevent the constant warnings. I’ll need to add a battery sensor to address this.


When powered up, plugging in a USB lead doesn’t provide any information. Powering the board with a USB cable attached does provide a connection to the bootloader, as expected, but the lack of connection from the board when powered struck me as odd. Thinking about it more, there is no reason why the board should power the USB when it’s going to be as far away from a computer as it is! It’s possible to build a firmware that does have a USB connection when powered, but it would only really be useful for testing.
Having built such a firmware and loaded it I found that my next attempt to flash firmware failed as the USB connection was being made with the running firmware and not the bootloader. Watching the board more closely I found that LED 1 would be solid red when the bootloader was connected and ready for new firmware to be uploaded.


The configuration file includes some default calibration values, but these need to be replaced by values for the my own board, so time to look at calibration. Prior to doing this I had a look at the PFD (Primary Flight Display) tab on the Paparazzi ground station to see how good/bad the initial values were. The result was it showed the board in a climbing left hand turn, but the right way up. Moving the board also showed the expected responses.
Calibrating the accelerometers is the first step and proved to be quite simple, though I’d suggest reading the “Basic procedure” description and generating a log file a few times before using trying the actual calibrations.


Put the board in the correct orinetation, hold for 10 seconds, move to next one… Relatively easy to accomplish once you figure out the order of the orinetations as shown in the supplied image (below).

Reading the text and comparing it with the image made things clearer but the image could be better. I did the tests with the board secured in the quad as it made moving it around easier and allowed me to reinforce that I had it correct way round!

Once complete, I ran the script and had some new calibration values. Once the configuration file was updated, firmware built and uploaded the PFD showed level wings and nose – exactly as expected.


I’ll do this over the next few days, but ran out of time yesterday.


I’m sure this would give much improved results, but the procedure outlined looks…complex! I’d be interested to know hos much improvement it makes?

Quad Upgrade

When I built the quad I went with a simple controller with the intention of upgrading at some point once I had more idea “what I was doing 🙂 Of course, such an open ended target was a total cop out and after some discussions with a friend and having a little more time on my hands than I had, I recently decided the time was right to start looking at an upgrade. This is what I had (a Hobbyking KK2.0 now replaced by the newer KK2.1.5).

KK 2.0 Board

Following the discussions and looking at a few options, I decided to stick with my open source leanings and move to the Paparazzi UAV Project. Looking at the autopilot boards (and following advice) I went with the KroozSD. Ordering it was easy enough and it arrived nicely packaged in a reasonable time. The fact it shares the same physical form factor as the old board helps greatly, making it almost a drop in replacement. Of course, nothing is ever that simple and so I’m currently getting the connections sorted out 🙂

Installing the Paparazzi software was easy enough and once installed it all ran without issue. The only thing that wasn’t clear, though it may just have been my poor attention span missing it, before you can run a simulation you need to use the “Build” option to create the files you will use for the simulation. Failing to do so will produce lots of windows but also a few warnings. This isn’t the most helpful as initially it appears everything is working! However, building is quick.

One aspect of the change that was new to me was the introduction of live telemetry. This is done using XBee modules and setting them up was my first task. I took a while deciding which modules to buy as there is a bewildering selection, but eventually went with 2 of these. I also bought 2 USB adapters, so once configured using the X-CTU software it was nice to see them communicating. Installing the “remote” module onto the board and applying power produced telemetry 🙂

KroozSD TopBottom side with ZBee module attached.


In case it helps anyone else, the connectors on the board are Molex PicoBlade with the exception of the 3 pin SWD connector in the centre of the board which is JST.
I had to guess which way round the XBee module attached, though the pictures on the webpage about the board helped!

As I discover more information I’ll pass it along, but thus far I have to congratulate Sergey on producing a great board and being very easy to deal with.

Quadcopter #2 is Alive

Following the arrival of the longer screws, all 4 motors were quickly attached and their directions checked. Only one was incorrect and needed the wires swapping. Despite the colours of the arms clearly showing direction I also went with green propellers at the front and black at the back (as per the first quad) to give additional indications.

After a quick tweak of the PI values and a zeroing of the receiver inputs it was time to see how it flew.

The answer was surprisingly well. Compared to the earlier design there was far less yaw evident when lifting off and the extra indicators of direction made figuring out corrections easier. The shorter legs means it sits closer to the ground which appears to make it slightly less stable just as it lifts, but that was easily corrected. The main issue I ran across was some of the receiver leads came loose and didn’t seem to be seated as well as I’d have liked, constantly becoming disconnected. As I have spare cables it’s an easy fix.

As it was hovering around freezing when I was trying, I didn’t stay out long. The early signs are positive. Now if the gale force winds can just abate to allow me to tune the PI settings…

Quadcopter #2

Seemingly hitting the ground on a regular basis with legs that rotate leads to them not staying vertical – who knew? 🙂

After spending a lot of time adjusting the rotors on my Talon 2.0 quadcopter frame to try and get them vertical, I decided it was time to look for an alternative frame to use while learning. The constant battle to stop spinning due to non-vertical motors really didn’t help figure everything else out.

When the Q450 frame came back into stock at Hobbyking I decided to get one and try it. Having had it for a while I finally had time today to start assembling it.

The frame arrives with no instructions, but is so simple that none are needed 🙂 The supplied screws were fine, though I had one that appeared to have skipped a step in manufacture and could not be used. At the end of construction there were a couple of spares, so the rogue screw wasn’t a problem.

Assembled Frame

The top plate has plenty of holes, but it doesn’t have the 4 holes for the power distribution board I’m using (recycled from version 1 of the Talon quad which came with the holes to attach the board pre-drilled). I stuck the board using the supplied tape and it’s pretty solid, but having the holes available would have been nice.

The other problem I had was attaching the motors. The screws that come with the accessory pack are M3 x 5mm which are too short to allow the motor to be secured to the frame. Longer bolts are required (M3 x 8mm will probably be fine)!

I also bought another KK2.0 flight control board and this has been fitted and flashed to version 1.6 already. Hopefully once I get a the longer bolts and mount the motors it’ll be taking to the skies.


The M3 x 8mm screws arrived and are a perfect match for mounting the motors on the frame. I bought one pack of these, which had one screw with a twisted head, but the rest were fine and 16 are now attaching the motors to the frame.

Firmware Updated

I’ve been waiting to update the firmware on my KK2.0 board for a while as I needed a USBasp. The one I ordered turned out to have a 10 pin connector, so I then had to wait for the 10 to 6 pin adapter to arrive! Thankfully both parts are now here and so having time this morning it was time to upgrade from the old 1.2 firmware the board shipped with.

When I first looked at the KK Multicopter Flash Tool I missed the fact it’s a Java application and so, mistakenly believing it required Windows, I hunted down and installed the Windows 7 drivers the USBasp required. This took a few attempts as the drivers I found initially wouldn’t install, though why they wouldn’t install remains a mystery to me. Once everything was installed I connected the board, ran the application and flashed the new firmware in less than 5 minutes.

Once flashed to firmware version 1.6 I powered the board and configured/calibrated ready for a test flight, though with the high wind and heavy rain that wasn’t possible today.

This is not the P value you want…

Having built the QuadCopter from scratch I always knew it would need tuning. The initial few flights proved it could fly and that it responded as expected, but I had expected it to be slightly more stable given the reputation of the KK2.0 board.

After those first few flights I started looking for advice on tuning via Google. While these produced lots of opinions and advice much of it was contradictory and mildly confusing. All of it agreed that I needed to adjust the P and I values. Exactly how to adjust them and what the effects of getting it wrong would be was less clear, but as the next step was tuning, I decided I would start changing the values. (However, as I outlined in Changes the timing wasn’t ideal and I probably shouldn’t have.)

The weather finally cooperated, allowing me to fly it for the first time with all the changes in place. The results were mixed. The new cleaner layout was an improvement and the new dome gave it a more robust feeling, but the handling was noticeably worse. Was this due to the new ESC or the changed P values?

Yesterday and today saw more flights and as my experience has grown things have gotten easier, but still I felt that things weren’t quite right and that set me to thinking back to all the advice I had read around tuning the P & I values.

Finding good guides to help with the tuning wasn’t easy and some of the videos weren’t as clear as they thought they were. Watching obviously experienced pilots perform fast manoeuvres over a large area and then declare what needs to be changed isn’t helpful 🙁 It would be great if someone could write one!

“The KK2.0 board requires flying.”

This was one statement I saw in many different places and led me to think that the amount of effort involved in getting the Quad airborne was normal. That said, when looking at videos of other people flying none seemed to have so much trouble so I suspected something was wrong.

Initial Values

So, what values to start with?

“For small quadcopters start with a P value of 30”

What’s a small quad? Is mine small? It’s certainly not as large as many, but is it small? As I didn’t know I decided to start assuming it was a small quad and so set the roll and pitch P value to 30, I value to 0 but left the limits at their factory defaults.

Higher Values == Better Stability?

30 was certainly too low to start and appears to have been the reason for the challenges I was experiencing.

After changing the P value to 70, the Quad lifted off smoothly and was suddenly far easier to fly! Increasing it to 80 seemed to help even more though a very small amount of oscillation started to creep in. With the I value still at 0 this was acceptable.

Next Steps

Next time I fly I’m going to try increasing the I value and also see if a higher P value gives me a little more stability.

In addition I have ordered a cable to allow me to upgrade the firmware in the KK2.0 board from the 1.2 it comes supplied with to 1.5 (or 1.6) which will hopefully also improve the stability.


After Flying the Quad, I did some more looking around the web and started thinking about tuning the KK2.0 board. This is done by adjusting the PI values, which initially seems like a form of dark art. It wasn’t abundantly clear what these values were until I cam across a piece that identified them as the values used for a PID Controller loop. After reading the page the values I was entering made more sense and some of the advice I had found also became more obvious.

The first step was to change the values and see how it flew. All went well and thanks to the easy menus the values were soon changed. The next few days brought wet and windy weather, so no flying was possible to see if the new values were an improvement or not.

It was at this point that the upgrade parts from HobbyKing finally arrived (have I said before how their shipping isn’t the fastest?). With the benefit of hindsight I should have resisted the temptation to upgrade the frame and flown it to check the new PI values, but I didn’t and so the new ESC was installed and the frame made ready.

In order to use the QBrain ESC, we needed to solder on an XT60 power connector, which was trickier than it looked given the nylon connectors tendency to melt. More than one attempt was required.

The numbering of the QBrain ESC outputs differs from what the KK2.0 board uses, so I had to experiment to get the correct orientation and connections. When ordering I also failed to appreciate how much larger the module was compared with the power distribution and KK boards, meaning the well aligned holes in the top plate were of no use requiring some alternative attachments to be used 🙁

It was dark when the changes were finished but undaunted we went outside and powered it up. All seemed good and my calibrating of the ESC was successfully starting all 4 rotors at the same time. Edging the power brought a couple of surprises.

  1. There was a clear pulsing between the propellers
  2. The #2 rotor seemed to be producing noticeably less thrust than the others

After these discoveries I did some headscratching and had a look around the web. The QBrain ESC is still a new product and there wasn’t as much help available as I had found for the Plush models it replaced, but the instructions sheet that came with it showed the default timing was set to Medium, not High. Using the ESC Programming Card I changed the settings and then calibrated the ESC again which seemed to cure the pulsing.

When next flying the quad the #2 rotor seemed to be producing more power, but the addition of the GoPro on top meant the whole frame was unbalanced. I’ll try it again without the GoPro and hopefully that will be better balanced.

With hindsight I made too many changes at once. Given my current lack of experience and knowledge I should have changed one aspect and evaluated the results before changing another. It would have been slower, but that’s not always a bad thing.

Flying the Quad

Since finishing the construction we’ve had 4 opportunities to fly it. The first of these was largely wasted due to the ESC’s not being calibrated, but the next 3 have all seen the quad take to the air. Today marked the first time I’ve tried flying our older GoPro Hero2 on it.


The GoPro attachment proved to be inadequate and so more thought is needed to figure out a better way to attach it. I have a solution in mind just need to get some pieces and some time to try it.

I anticipated that the learning curve would be steep – and it has been! As with all such things every time it flies things get easier. The initial hesitations about increasing the throttle to get it airborne are reducing and I’m starting to be more gentle with the controls and overcontrol less. That said, after today’s session I have adjusted the PI values to try and improve the handling. Time will tell if these are better or not.

Liftoff occurs with around 45% throttle which I think seems a good point and means there’s plenty of power left. It’s certainly spritely when it starts moving 🙂



The frame is proving to be more resiliant to damage than I had feared and despite a few minor and one larger crash it’s still in good shape. Ordering some replacement legs may be on the agenda soon, but it’s certainly not desperate 🙂

Quadcopter Construction

Having finally decided to build a QuadCopter I ordered components from HobbyKing. Now that I have everything I needed and some time to build it – it is time.

Main Components

The list below is not exhaustive but provides the main components.

Ordering from HobbyKing was great for price, but the delivery was expensive and their stock situation highly frustrating. Additionally when ordering the pieces it often wasn’t clear whether pieces I wanted would work together as I envisaged, necessitating much use of Google.
Calibrating the ESC’s

NB You also need to order the accessory pack for each motor as this provides the shaft and attachments for a propeller!

In addition to the above I also needed to do some soldering for various cable connections and the screws are hex (2 and 2.5mm as best I can tell) so suitable tools were required. I didn’t use screw lock for the frame as I was sure I’d be replacing broken parts 🙂

LiPO Charging?

The horror stories about charging LiPO batteries aren’t hard to find and certainly deserve being taken seriously, so I wanted to get a charger with some “smarts”. There are so many conflicting views about this that eventually I bought an Accucel-6 50W charger/balancer and a power supply (though the power supply is likely overkill). As an additional safety precaution I also got a charging bag for the battery.

Actually using the charger proved interesting and required me downloading the manual and reading the appropriate section. This would have been easier (and more obvious) had they included a link to the manual in the box, but they didn’t.


The first job we did was to solder all the connectors onto the ESC’s and heat shrink them. This took a while as there are 5 connectors per ESC.

Assembling the frame was easy enough. The motor attachment plates appeared to have the countersunk holes on the wrong side, so we put them on upside down without any problems. I had been hoping to run the wires inside the arms but without fabricating extension leads this wouldn’t have worked, so we just tied them to the side (we decided early on to change our ESC so this was temporary). One thing we didn’t do initially was spend a little time ensuring that all the legs were level prior to tightening the legs, which with hindsight we should have.

Attaching the KK2.0 board was straightforward and connecting the RC receiver was simple enough (though without the online pdf manual getting them in the correct order would have been much harder). Once the ESC’s were attached to the KK2.0 board it was time to power it up 🙂


The layout is quadcopter-x and once selected it will show the correct numbering and directions. Again the pdf manual was very helpful for this. Once selected I checked the rotation direction and changed connections as required on the ESC’s to ensure they were all correct.

Calibrating the ESC’s

This turned out not to be as simple as it initially appeared. Reading the instructions for the KK2.0 board provided the basic procedure but as there are a lot of different ESC’s available knowing the beep sequences to wait for was the stumbling block. As I’m using Turnigy Plush ESC’s I eventually found this helpful video that explained where I was going wrong.

Essentially I was waiting too long and so the ESC’s went into programming mode (after playing their funky tune). Being quicker and moving the throttle from max to min after the 2 beeps was all that was required to correctly calibrate them.


After a lot of searching I eventually decided to use 8×4.5 propellers and decided to follow convention and have different colours at the front and rear – green for the front and black for the rear in this case. As you need both left and right rotation propellers for each, this means I should have ordered 4 packs, but managed to misorder initially and only got left handed propellers! When ordering the right handed ones I also forgot I needed both colours and so it took a while to have everything I needed! Hopefully this will act as a warning to others 🙂

One thing to note is that the propellers don’t have many markings on them, so it’s not always easy to quickly tell them apart 🙁 It would be better if they were clearer about what they were.

Receiver Test

Having read the various guides online I did a receiver test early on in the setup and zeroed the controller, but by the time we came to fly they had changed so needed doing again. Failing to do this caused an early accident when it flipped on the ground and smashed a propeller 🙁


Between my initial ordering of components and the final assembly it has become possible to get 4 ESC’s on a single board, with integrated power distribution. To simplify the design and make things far neater we have ordered one of these boards which will allow the cables for the motors to be run inside the arms and removing the need for extra wiring for power distribution.

As I also plan on flying a GoPro I’m debating how to attach it and balance the frame.

Up, Up and Away…

Following some initial teething problems and after climbing the inevitable learning curve, today marked the first few flights 🙂 The next post will detail more about that though 🙂

Quad Copter

Having the GoPro cameras has led us to open up our imaginations about how to use them. We’ve had one suspended from a kite (more to follow) but I’ve been pondering building a Quad Copter to fly a camera around for a while. The ready made solutions seem a lot of money for what they are and it’s always good to have a project 🙂

When I started looking into what was required there was the usual very steep learning curve. All the new terms and concepts to grasp coupled with people keen to sell you things without telling you the details meant it has taken me a while to bite the bullet and start assembling the parts I’ll need.

I’ll try and document what I do to try and help others and remind myself of what not to do next time. It’ll probably also help when reconstructing from the inevitable crashes!