Say ‘Hi!’ to Hermione*

Hermione will be the mother of all that’s gone; she’s a bit heartless at the moment – her HoG will be an RPi A3 when it appears on the market.

Hermione flat-out (with banana for scale)

Hermione flat-out (with banana for scale)

Hermione flat-out (with banana for scale)

Hermione tip-toes (with banana for scale)

The main reason behind building yet another quadcopter is the frame:

  • loads more space for extra sensors
  • folding arms so it’s easily transportable
  • beautiful build – lots of CF and CNC machining
  • lots of extension platforms adding lots of options of where to put all the pieces – installed here are a power distribution board (in the plate sandwich), a plate for her HoG, and a GPS plate sticking out to the left.

The one thing that’s missing are legs – I’ve had the ones supplied before, and they crack and break with the down-falls my testing produces.  There are stronger ones I’ll be getting.  I’ve bought from quadframe.com previously for Chloe so I know the high quality of their frames; the previous frame I’d bought was premature, and sadly I ended up selling it.

But this time, I have a purpose for all the extra space: Hermione will be deployed with GPS, LiDAR x 2, PX4FLOW, a RPi Camera and anything else I can get onto her.  Also the frame supports an X8 layout as well as standard quad format; X8 is where each arm has 2 motors and props: the top motor prop is set up as normal; the lower one is upside down, and the prop is installed on the motor upside down.  The topside and underside props spin in opposite directions.  This format provides more power for heavy lifts and protection against motor / prop damage or failure.  Each prop has its own ESC and separate PWM feed.

Doing the above requires the A3 for its extra cores to do a lot more sensor processing and a new PCB to support the new GPIO pin requirements.

GPS, LiDAR and LEDDAR require UART connections; X8 requires another 4 GPIO pins for the 4 ESCs PWM feed.  One of the sensors – probably GPS – can use the USB port, assuming the A3 has built-in WiFi like the B3.  PXFLOW uses I2C.

My thinking is that LEDDAR and PXFLOW provide term fused inputs to the distance PIDs; GPS provides targets for the flight plan; compass is the yaw input with the the flight plan providing direction of travel so that a camera pointing forwards can always track her progress; Scance Sweep provides object detection overriding the GPS flight path short term to avoid objects.

Together, this means I could set a start and end position for a flight using GPS (either just start and finish or with intermediate check points), and then just set her loose autonomously to track against those points, whether this is simply flying from A to B or getting from the entrance to the centre of a maze, logging “where I’ve been” to ensure she always prioritises new paths through the maze.

Here’s the current PCB eagle layout for Phoebe and Chloe:

A+ PCB

A+ PCB

  • the right hand side 3 vertical PCB tracks are for the LiPo to 5V regulator – I’m planning on Hermione having a BEC on her PDB (power distribution board), so that opens up space for the rear X8 PWM pins.
  • the left hand side 4 vertical PCB track are I2C extensions in place for the URF, but the space is needed for the the front X8 PWM pins so the I2C extension is moved to the bottom edge and will be used for the PIX4FLOW.

Here’s the first draft of the revised PCB:

Hermione PCB beta

Hermione PCB beta

PIN usage:

  • pins 4, 6, 8, 10 and 12 are used for LEDDAR as now but extended outwards
  • the GPIO pins for PWM are completely reworked for X8 format as is the MPU9250 interrupt pin; I’ll probably end up adding X8 before I add Scanse Sweep simply to fill the gap between now and its delivery
  • I2C is extended on the lowerside for the PX4FLOW
  • That leaves a selection of pins and space on the topside for Scanse Sweep – I need to get wiring specs for this; and alternative is via USB using a UART to USB converter – I have one of these already for use configurating LEDDAR by my Windows PC.
  • GPS will also be via USB, assuming the WiFi is now build into the A3 board or I might use a mini USB hub like on of these that I used already for other projects.

Regarding WiFi, to extend the range, I’m going to replace the (hopefully) on board antenna with a HiRose U.FL connector, as per here.  That will then allow me to connect to a U.FL to RP-SMA cable, and place a higher gain antenna on the board.

I’ve still  left a few breadboard pins at the base as they may turn out to be useful for LEDs, buzzers etc.

As you can see, there’s a lot that needs to be done, but it breaks down into lots of separate blocks to keep me busy until the A3 and Scanse Sweep arrive.  The first step is simple: move Chloe’s HoG over to Hermione’s frame, and get her stable.


*Penelope (as in “Pitstop”) was a close runner up, but with my existing HoGWARTs WAP installation notes, Hermione (as in “Granger”) won the ballot outright.

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.