BYOQ-BAT ⇒ BYOAQ-BAT

If you have reached this page searching for “BYOQ-BAT”, please change your search to “BYOAQ-BAT”.


BYOQ-BAT has been renamed as BYOAQ-BAT to emphasize that HoG is autonomous: there is no remote control beyond ctrl-C to abort the flight.  A flight plan is programmed, the code is run, and HoG does what she’s been told from the pre-programmed flight plan.  So if you are looking for a remote controlled quadcopter, while these articles might be useful to some extent, they are far from the full solution for you, and for the missing bits, you are on your own.

BYOAQ-BAT VII: Networking

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


HoG needs to be its own WAP to allow it to be controlled out of range of any domestic WiFi router.  I’ve left adding the WAP support until after all necessary software is installed; once HoG is a WAP, there is no internet access, and updating software requires backing out some of the WAP changes temporarily.

The information below is based on this link and this link and this link, but is customized to give exactly what HoG needs: a secure WLAN / VPN with no internet access using a statically configured fixed IP address.


WARNING: Depending on the USB WiFi dongle you are using, you may need to update the WAP software (hostapd).  More specifically, anything using RealTek drivers is likely to need these changes.  To find out whether you have such a dongle type

lsusb

and look for RealTek in the response.  If you are, I refer you to the Dave Conroy and Jens Segers links above.  I’ve used both, and both work well.

There is also the minor point that some WiFi dongles don’t even support hosting a WAP.  Be very careful when you are shopping that the description mentions WAP or soft-AP support.


Here are the steps I’ve taken from HoG’s console still connected via WiFi to the home network.

  • ping www.google.com just to be certain of your internet access
  • install WAP and DHCP software:
    sudo apt-get install hostapd udhcpd
  • Update the hostapd software if you are using a dongle with the Realtek chipset as per the links at the top
  • Configure hostapd by creating /etc/hostapd/hostapd.conf “sudo vi /etc/hostapd/hostapd.conf” and add the following:
    interface=wlan0
    driver=rtl871xdrv
    ssid=HoGWAP
    channel=1
    wmm_enabled=0
    wpa=1
    wpa_passphrase=HoG3.141592654
    wpa_key_mgmt=WPA-PSK
    wpa_pairwise=TKIP
    rsn_pairwise=CCMP
    auth_algs=1
    macaddr_acl=0
  • Now to configure the WAP static IP address – “sudo vi /etc/network/interfaces”, replacing the existing entry for wlan0 with the following
  • auto wlan0
    iface wlan0 inet static
    address 192.168.42.1
    netmask 255.255.255.0
  •  In the same file, comment out (# at the start of the line) the following if present
    #allow-hotplug wlan0
    #wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
    #iface default inet dhcp
  • We next need to configure dhcp for the clients accessing the network to  provide their IP addresses – edit /etc/udhcpd.conf adding:
    start 192.168.42.2 # This is the range of IPs that the hostspot will give to client devices.
    end 192.168.42.20
    interface wlan0 # The device uDHCP listens on.
    remaining yes
    opt domain local
    # opt dns 8.8.8.8 4.2.2.2 # The DNS servers client devices will use.
    opt subnet 255.255.255.0
    opt router 192.168.11.1 # The Pi's IP address on wlan0 which we have set up.
    opt lease 864000 # 10 day DHCP lease time in seconds

    Note the dhcp address range starts at 192.168.42.20 allowing some space for static addresses 1 – 19.

  • In the same file, delete or comment out “#” any other lines as these are just example settings.
  • Enable dhcp by editing /etc/default/udhcpd thus to comment out the line
    #DHCPD_ENABLED="no"
  • Add the dhcp leases file by typing
    sudo touch /var/lib/misc/udhcpd.leases
    sudo chmod 666 /var/lib/misc/udhcpd.leases
  • Enable hostapd by editing /etc/default/hostapd thus, adding
    DAEMON_CONF="/etc/hostapd/hostapd.conf"
  • Edit /etc/hostname to ensure the domain name is included – in my case, the domain is called “local”, and the hostname is “hog”, so /etc/hosts reads
  • hog.local
  • Next assign static IP address for the server in /etc/hosts
    192.168.42.1 hog hog.local
  • Turn off the ifplugd (pluggable interface daemon) for the WiFi dongle as it seems to cause conflict between hostapd and udhcpd – edit /etc/default/ifplugd
    # This file may be changed either manually or by running dpkg-reconfigure.
    #
    # N.B.: dpkg-reconfigure deletes everything from this file except for
    # the assignments to variables INTERFACES, HOTPLUG_INTERFACES, ARGS and
    # SUSPEND_ACTION.  When run it uses the current values of those variables
    # as their default values, thus preserving the administrator's changes.
    #
    # This file is sourced by both the init script /etc/init.d/ifplugd and
    # the udev script /lib/udev/ifplugd.agent to give default values.
    # The init script starts ifplugd for all interfaces listed in
    # INTERFACES, and the udev script starts ifplugd for all interfaces
    # listed in HOTPLUG_INTERFACES. The special value all starts one
    # ifplugd for all interfaces being present.
    INTERFACES=""
    HOTPLUG_INTERFACES=""
    ARGS="-q -f -u0 -d10 -w -I"
    SUSPEND_ACTION="stop"
  • Finally (and I don’t know if this was necessary), update /etc/resolv.conf to local domain name resolution rather than relying on an external DNS
    domain local
    search local
    nameserver 192.168.1.254
  • Check, double check, and triple check that you’ve done all the above steps, and then finally
     sudo reboot

That’s it done for the WAP side, but because there’s not internet connection and so no DNS, you’ll need to configure your clients with the HoG static IP address so they have access to HoGWARTS (HoG Wireless Access Remote Terminal Server!)

Add the static IP address to /etc/hosts in your clients:

192.168.42.1       hog.local

That’s it, job done!


When later you wish to update the RPi software, you’ll need to add an ethernet interface.  First, get a USB to Ethernet dongle – I use one by Pluggable which worked out of the box.  Then you need to re-enable the interface pluggable daemon:

# This file may be changed either manually or by running dpkg-reconfigure.
#
# N.B.: dpkg-reconfigure deletes everything from this file except for
# the assignments to variables INTERFACES, HOTPLUG_INTERFACES, ARGS and
# SUSPEND_ACTION.  When run it uses the current values of those variables
# as their default values, thus preserving the administrator's changes.
#
# This file is sourced by both the init script /etc/init.d/ifplugd and
# the udev script /lib/udev/ifplugd.agent to give default values.
# The init script starts ifplugd for all interfaces listed in
# INTERFACES, and the udev script starts ifplugd for all interfaces
# listed in HOTPLUG_INTERFACES. The special value all starts one
# ifplugd for all interfaces being present.
INTERFACES="all"
HOTPLUG_INTERFACES="auto"
ARGS="-q -f -u0 -d10 -w -I"
SUSPEND_ACTION="stop"

You may also need to update /etc/hostname if there is a domain name specified like hog.local, rather than just the machine name.

You also probably will need to update /etc/hosts to remove the WAP host  hog.local

Connect an ethernet cable to your hub, and a reboot then should give you internet access – ping www.google.co.uk to check. From there you can do a “sudo apt-get update && sudo apt-get dist-upgrade”. Then reboot, revert /etc/default/ifplugd to

# This file may be changed either manually or by running dpkg-reconfigure.
#
# N.B.: dpkg-reconfigure deletes everything from this file except for
# the assignments to variables INTERFACES, HOTPLUG_INTERFACES, ARGS and
# SUSPEND_ACTION.  When run it uses the current values of those variables
# as their default values, thus preserving the administrator's changes.
#
# This file is sourced by both the init script /etc/init.d/ifplugd and
# the udev script /lib/udev/ifplugd.agent to give default values.
# The init script starts ifplugd for all interfaces listed in
# INTERFACES, and the udev script starts ifplugd for all interfaces
# listed in HOTPLUG_INTERFACES. The special value all starts one
# ifplugd for all interfaces being present.
INTERFACES=""
HOTPLUG_INTERFACES=""
ARGS="-q -f -u0 -d10 -w -I"
SUSPEND_ACTION="stop"

Re-add the WAP domain into /etc/hostname if you changed it previously.  Likewise add back into /etc/hosts the WAP local address (192.168.42.1  hog.local hog)

Unplug the ethernet dongle and reboot. All should be back to how it was before with HoGWARTS.

P.S. Anyone spotted the link between HoG and her IP address?

P.P.S. The next article will be about calibration of the sensors.  This has radically changed in the last couple of weeks, but currently remains just theory due to the death of Zoë right at the point I was about to test the theory.  That’s actually the trigger for BYOAQ-BAT: I had to build a brand-new quadcopter to replace Zoë, and so it made sense to blog it live.  HoG has just completed the calibration, and is about to undergo the first few basic tests.  Only at that point will I know whether the new calibration works and therefore that I can blog about it.  I hope it does, because otherwise, this may well be the last post in the series!  More details about the new calibration will appear on the blog regardless, but outside of the BYOAQ-BAT articles.

BYOAQ-BAT VI: Performance

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


This is another short article about getting the code to run as fast as possible. I’ve taken numerous steps to ensure the code itself is fast including:

  • i2c 1 x 14 byte read rather than 14 x 1 byte reads
  • time.time() called once per cycle at the point the next sample is read – there’s an irony that calling time.time() takes a lot of time!
  • calculations of values used multiple times is done once – see the various matrices for an example
  • apply calibration / scaling once per motion not once per sample
  • separating data collection and motion processing into separate threads (although to be honest this is buggered by the GIL)
  • data logging to RAM disk and copied to SD card on flight completion

but without the best from the OS, they are pointless.

We’ve already overclocked the CPU and given as much memory as possible to the CPU.  Two last steps.

Get GPIO.tgz from GitHub is you don’t have it already.  Do the following:

tar xvf GPIO.tgz
sudo apt-install remove python-rpi.gpio
cd GPIO
sudo python setup.py install

That installs the GPIO replacement which is fast enough to catch the 50μS hardware interrupts from the sensors to say there is new data ready.

Then to read the data as fast as possible, you’ll need to edit /boot/config.txt adding:

dtparam=i2c_arm_baudrate=400000

Together I’m able to get about 700 loops per second each reading 14 bytes of data (a data rate of 78.4kbps) and process them.  The sensors is updating this data at 1kHz or 112kbps which is why the baudrate needs to be increased from its default of 100kbps.

BYOAQ-BAT V: Power

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


Up to now, the HoG has been powered from the mains, but now it’s time to swap to battery power for the next article. My quad has 2 batteries – the main LiPo powering the motors, and one of those phone charger rechargable battery banks (Lithium Ion under the covers) powering the HoG. That way by using optically isolated ESCs (‘Opto-ESCs’), the HoG is electronically isolated from the power demands of the motors: the phone charger power bank provides the 5V to supply the HoG, and the LiPo powers just the motors. There is not electronic connection between them – just an IR LED and photo-transistor.

One word of warning though: some ESCs may claim to be opto but are not. If the ESC has a (U)BEC, the presence of the (U)BEC is to power the flight controller. But due to ignorance in the market, sometimes the lack of a (U)BEC has incorrectly marketed as “Opto”. I came across this with a set of “The Black Sheep” (TBS) ESCs, where the manufacturers do not mention “Opto” whatsover, but a vendor / distributor made the mistake that a lack of (U)BEC must mean “Opto” and they sold it as such.

I took a gamble and bought a set. First thing I did was attach an ESC to the LiPo via the high power wires and measured the voltage on the 3-wire cable between (brown & red) or (black & red). It should read an unstable voltage close to 0v for “Opto” as you are measuring the voltage across an unpowered IR LED. But with the TBS ESCs they measured a clear and stable 5V. There’s nothing wrong with that in itself other than the ignorance of the distributor / vendor, but I wanted to keep my HoG completely isolated from the high-current surge LiPo and provide it with a stable regulated 5V instead.

So it’s your choice whether you go for 2 batteries and opto-isolation or 1 battery and (U)BEC, but be careful on the choice of ESCs in either case.

BYOAQ-BAT IV: Software installation

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


A very short article this time around, just picking up and configuring the last few bits of software that are specific to this project.

  • get RPIO from here and install – it provide DMA PWM on any GPIO pin
  • qc.py from GitHub
  • Quadcopter.py from GitHub
  • GPIO.tgz from GitHub.

Check pins in Quadcopter.py match your PCB layout for pins attached to the sensor interript, heater, and ESC PWM connections.  In my case, these are:

 RPIO_DATA_READY_INTERRUPT = 22
 RPIO_THERMOSTAT_PWM = 18
 ESC_BCM_BL = 5
 ESC_BCM_FL = 27
 ESC_BCM_FR = 17
 ESC_BCM_BR = 19

These tell the code which GPIO pins (based on the Broadcom chip pin numbers, not the Raspberry Pi board pin numbers) connect to which ESCs, data ready interrupt on the IMU and the heating element.

BYOAQ-BAT III: OS installation

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


Next step is getting the Raspbian OS installed and talking to the sensors.

You’ll need a USB hub for plugging in a(n)

  • keyboard
  • mouse
  • ethernet dongle (WiFi is possible, but I use ethernet as there is no need to configure SSID)
  • Raspberry Pi

Don’t forget an HDMI TV / monitor

Get the latest image on a micro SD card – I’m using the 2015-01-31 Raspian.

Boot to raspi-config

  • Expand filesystem
  • Overscan Disabled
  • Memory Split 16MB
  • Overclock Medium 900MHz
  • Set hostname
  • I2C Enabled

Reboot

Ping google.co.uk to check internet access

Update latest image to the very latest bits

sudo apt-get update
sudo apt-get dist-upgrade

Install the following packages

  • python-smbus
  • python-dev
  • i2c-tools
  • ftpd
  • ftp

Remove the following package – we will add a high performance one later

sudo apt-get remove rpi-gpio

Scrub that for the moment, the standard package may well be up to speed now. I’ll come back to that later if necessary.

Ensure the i2c kernel drivers are loaded – add the following to /etc/modules:

i2c-bcm2708
i2c-dev

Reboot

Check what can be seen on the i2c bus: sudo i2cdetect -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77
  • 0x68 is the MPU9250 – accelerometer, gyroscope and magnetometer
  • 0x77 is the MS5611 – barometer

Next time, software installation. There will be a delay for the next article as my writing of the artcles has caught up with what I’ve done so far.

BYOAQ-BAT II: Hardware construction

If you haven’t already, please read the previous BYOAQ-BAT articles first – just search for the BYOAQ-BAT tag.


The next step is to build the hardware components: attaching the PCB to the model A+ / B+ Raspberry Pi ,adding those to a baseboard and building the frame.  This is only really just a BOM, as assembly is trivial.

First, the pieces required to securely attach the A+ to the Beret and the Base.  Together, I’m going to refer to these throughout the articles as the Heart of Gold or HoG

  • Pimoroni Coupe Royale – only the base plate is used; the inner holes are countersunk for…
  • M2.5 10mm countersunk bolt to connect the base plate to the A+ via…
  • 3mm spacer.
  • 11mm M2.5 hexagonal spacer to solidify the join between the Raspberry Pi and the Beret – my 40 pin IDC is 11mm high
  • flat head M2.5 6mm (appox) bolts to connect the Beret to the 11mm standoffs
  • Non-slip washers for the bolts above.
HoG

HoG

Secondly, the physical frame of the quadcopter

Frame

Frame

For the moment, the frame and the HoG are left unconnected.  The HoG needs OS, packages, software, calibration and tuning before these two with meet again.  I’ll start on this next time.

BYOAQ-BAT I: Introduction

I’ve been slowly collecting parts for a new quadcopter – by slowly, I mean for over a year; each time I spot something better designed, I’ve been buying them – for me design incorporates not just engineering  but also elegance.  I finally have all the parts I need to start building, and since I’m starting from scratch, I thought it worth blogging my progress – “Build Your Own Autonomous Quadcopter – BOM (Bill of Materials), Assembly and Testing.  You can follow my progress by searching for the tag “BYOAQ-BAT”.

WARNING: This series of articles describes how I am putting together my new autonomous quadcopter.  They are not a set of instructions which, if followed, will result in a working, remote controlled quadcopter.  They won’t.  What you will end up with is a piece of machinery that spins blades around all by itself hacking to pieces anything in its path.  I have deliberately omitted the very low level details from this set of articles for that reason.  If you do choose to use these articles as though there were a set of detailed instructions, any resultant damage, death or destruction is entirely your own fault.  You have been warned.   

On the flip side, if you are building your own quadcopter, with either autonomous or human control, I hope you’ll find things here that are interesting and useful to you.


First, PCBs and electronic components.  Here’s the PCB, as produced by Ragworm from the Eagle beret.brd board file up on GitHub.  It’s essentially just a breadboard, with just a few minor tweaks to fit some very specific requirements of my new quadcopter.

Beret PCB top

Beret PCB top

Beret PCB bottom

Beret PCB bottom

When soldering components to PCBs, I find it’s best if you add the smallest things first, and build upwards.  The first step then is to add the wires; I’d worked out the wiring beforehand on a print out of the top-side of the Eagle board.  With all the wires in place, I sellotape them down before flipping the board and soldering them to the board.

Beret wiring

Beret wiring

Once the wires are soldered in place, next step is to add the smaller components – this time I hold them in place with blue-tak while I solder them on:

  • a 100k pull down resistor
  • a MOSFET
  • IDT pins for the IMU breakout
  • IDT pins for the ESC connections

Next comes the 40 pin IDC connector joining it to the PCB.  At this stage, I fix the beret HAT board PCB to the A+ (no power and no SD card) while soldering on the connector to ensure positioning is perfect.

Next step is to add the wires and connector that will eventually attach to the heater resistor.  It should now look like below.  All that’s missing is the IMU; but before I attach that, I like to test the various points on the board.  Without an SD card, you can power up your A+ with the beret plugged in and then power will make it through the GPIO pins to the PCB to allow you to do the testing with a multimeter.  I check that there’s 5V where I expect it, and zero resistance between connected rows / columns where I expect.

Beret sans IMU

Beret sans IMU

Prior to attaching the IMU to the pins on the PCB, there’s a few bits and bobs to do with the IMU breakout board.  It supports both I2C and SPI, and allow option pull-up resistors to be used, and if using I2C, the I2C addresses may be selected.  These are all done by soldering bridges between clearly marked contacts on the breakout PCB.  Since the Raspberry Pi I2C pins already have pull ups, I’ve not bridged the gap enabling the breakout pull-up.  I’ve set both I2C solder ‘bridges’ to 0.

I attached the 10Ω SMD resistor “heating element”, gluing it to the top of the IMU with Arctic Silver thermal epoxy adhesive*; I couldn’t find a UK vendor so bought it from the US via e-bay.  Once the epoxy has set (I give it a good couple of hours to be sure), I soldered on a couple of IDT pins to the resistor.  Finally, I surround the IMU with a wrapping of blue-tak pure to provide thermal insulation.

Now I can attach the DroTek 10DOF IMU itself to the PCB IDT pins already soldered onto the board.  And that’s it:

Beret complete

Beret complete

The next article will cover getting the A+ and beret firmly attached to each other and to a base which are all aligned / parallel to each other.

*This is the stuff used by psychotic overclockers on gaming machines along with water-based CPU cooling etc etc.