RC software test 1 passed

Courtesy of the creator of SMBus2 on GitHub, the joysticks are working perfectly.  Here’s the code.  Time now to move on to the network connection with Penelope.

#!/usr/bin/python
import time
from smbus2 import SMBusWrapper, i2c_msg 

try:
    with SMBusWrapper(1) as bus:

        bus.write_byte_data(0x40, 0x76, 2)
        bus.write_byte_data(0x41, 0x76, 2)
        
        while True:
            time.sleep(0.5)

            msg = i2c_msg.read(0x40, 2)
            bus.i2c_rdwr(msg)
            data = list(msg)

            assert (len(data) == 2), "Joystick 0 data len: %d" % len(data)

            if (data[0] > 127):
                X_0 = data[0] - 256
            else:
                X_0 = data[0]

            if (data[1] > 127):
                Y_0 = data[1] - 256
            else:
                Y_0 = data[1]
            
            msg = i2c_msg.read(0x41, 2)
            bus.i2c_rdwr(msg)
            data = list(msg)

            assert (len(data) == 2), "Joystick 1 data len: %d" % len(data)

            if (data[0] > 127):
                X_1 = data[0] - 256
            else:
                X_1 = data[0]

            if (data[1] > 127):
                Y_1 = data[1] - 256
            else:
                Y_1 = data[1]

            print "X_0 = %d | Y_0 = %d | X_1 = %d | Y_1 = %d" % (X_0, Y_0, X_1, Y_1)

except KeyboardInterrupt:
    pass

finally:
    pass

RC hardware complete…

courtesy of lots of extra layers of the Pimoroni PiBow Ninja.  They also did a couple of custom cuts for Penelope’s PiBow so I could lower her by 2 layers (6mm) making space to include the battery warmer.  Penelope is however still waiting for the Garmin LiDAR-Lite v3HP.

RC hardware

RC hardware

I wish I could say the same about the software.  The problem is how to access these I2C Hall Effect Joysticks.  Although “i2cdetect -y 1” can see them, none of three different I2C python libraries (smbus, smbus2 and pigpio) can read the data correctly from them.  The problem is that the joysticks’ I2C does not need a register, you simply read two bytes from the I2C address, yet none of these libraries successfully doing this.  A google query found my own post high in the rankings which is disappointing when hoping to find someone else’s solution, so I’ve contract Grayhill directly.

Until this is solved, there’s little point adding the code to connect to Penelope (and for her to be listening), nor having Ivy load the code on boot.  Very frustrating.

Remote control

I’d run out of ideas of what to do next, and then it struck me: I could finally add an RC, and with just a few seconds’ thought, I realised it would be reletively simple.

Back at the end of 2013, about a year into my piDrone project, I’d clearly considered this – and yes, that is a Raspberry Pi 1A!!!

Remote Control Prototype

Remote Control Prototype

I’m guessing this was the point I realised I was way too ignorant, and realised autonomous control was easier, ironically.  I still have these I2C Grayhill 67A joysticks, and now RC control is much easier to add safely – it’s just another poll.poll() input to the Autopilot process like the Sweep- and GPS-flight plan inputs are now.  And this is perfect for Penelope.  Hermione will remain the OTT autonomous control, and ‘P’ will have some degree of manual control.  And in a way, this is much like my DJI Mavic – it hands control to the human only when it is safe to do so.

The RC will be based on the new RPI B3+ with it’s improved WiFi.  I’ve already done a prototype of how the joysticks attach to a Pimoroni PiBow Ninja body.

Pibow Joysticks

Pibow Joysticks

And actually, that feeds into the GPS fusion with the IMU ∑∑(acceleration – gravity)δtδt, and LiDARs distance inputs when the LiDARs are out of range.  I’m a lot more comfortable testing it this way rather than flying her over a lake!

My lord, I have a cunning plan!


P.S. I’m calling the RC “Phoebe”, who alongside Penelope make up team “Pi²”.

P.P.S. In one of those convenient coincidences, my one unknown was how to power Phoebe.  Then this appeared via Twitter.  I hope they do another production run.  It’s these synchronised occurrences that force you to consider whether there is a higher being playing chess with one’s life!

P.P.P.S. Changed my mind: the RC is called “Ivy” and together with “Penelope”, they make the “PI” team!

Obstruction avoidance test 2 – PASSED!!!!!

After a minor tweak to the handling resolution of the Scanse Sweep data, all works brilliantly.

This is a five metre forwards flight, with the flight paused and later resumed once the obstacle has been avoided.  Note that ‘H’ tracks the obstruction at about one meter away.  Hence she flies a quarter circle around the circular cardboard tube, before continuing the forward flight when the obstruction is behind her.

The code is updated on GitHub as a result.

WAP RPi 3B+ and Stretch

So Hermione is a 3B running Jessie from February 2017 due to network and I2C problems added in the March release.

Penelope is now a 3B+ running Stretch.  As a result, I want to update to the latest WAP software and I2C.  The biggest problem for me is setting up the isolated Wireless Access Point.  I’ve finally solved it with a lot of help from my friends on the RPi Forum.  Here’s how:

To set up an isolated AP:

  • Follow these instructions up to but not including “ADD ROUTING AND MASQUERADE” section.
  • Comment out any “NETWORK={” entries in /etc/wpa_supplicant/wpa_supplicant.conf
  • reboot

To disable the isolated AP to contact the internet for apt-get updates etc:

  • In /etc/default/hostapd set DAEMON_CONF=””
  • Reinstate the “NETWORK={” entries in /etc/wpa_supplicant/wpa_supplicant.conf for your home network ssid etc
  • Comment out the AP interface IP details in /etc/dhcpcd.conf
  • reboot

To solve the I2C, I’m waiting for the Garmin LiDAR-Lite v3HP which has been consistently delayed by up to 8 weeks since (at least) the start of February i.e. it’s still delayed by up to 8 weeks, two months later!  The Garmin LiDAR-Lite v3 exposed the I2C problem: it was strictly running I2C rules whereas the RPi I2C included an incompatible bend of the rules commonly supported many other devices e.g the MPU-9250 IMU.  I’m hoping the delay is due to the fact they are updating their I2C implementation to support the bent rules.

THBAPSA


P.S. Penelope has a new salad bowl:

Penelope's Salad Bowl

Penelope’s Salad Bowl

OA test 1 analysis

My fault: when an obstacle is detected, the autopilot tells ‘H’ to move 90°, parallel to the obstacle, until she reaches the safe zone.  That’s not what the logs from the autopilot say:

AP: PHASE CHANGE: RTF
AP: PHASE CHANGE: TAKEOFF
AP: PHASE CHANGE: HOVER
AP: FILE FLIGHT PLAN
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 6 DEGREES.
AP: PHASE CHANGE: AVOID @ 103 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 7 DEGREES.
AP: PHASE CHANGE: AVOID @ 94 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 13 DEGREES.
AP: PHASE CHANGE: AVOID @ 81 DEGREES
AP: AVOIDING OBSTACLE @ 11 DEGREES.
AP: PHASE CHANGE: AVOID @ 79 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 15 DEGREES.
AP: PHASE CHANGE: AVOID @ 76 DEGREES
AP: AVOIDING OBSTACLE @ 15 DEGREES.
AP: PHASE CHANGE: AVOID @ 72 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 14 DEGREES.
AP: PHASE CHANGE: AVOID @ 70 DEGREES
AP: AVOIDING OBSTACLE @ 18 DEGREES.
AP: PHASE CHANGE: AVOID @ 72 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 23 DEGREES.
AP: PHASE CHANGE: AVOID @ 72 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 31 DEGREES.
AP: PHASE CHANGE: AVOID @ 73 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 31 DEGREES.
AP: PHASE CHANGE: AVOID @ 65 DEGREES
AP: AVOIDING OBSTACLE @ 37 DEGREES.
AP: PHASE CHANGE: AVOID @ 59 DEGREES
AP: OBSTACLE AVOIDED, RESUME PAUSED
AP: PHASE CHANGE: FORE
AP: AVOIDING OBSTACLE @ 40 DEGREES.
AP: PHASE CHANGE: AVOID @ 71 DEGREES
AP: PROXIMITY LANDING 1.46 METERS
AP: PHASE CHANGE: PROXIMITY CRITICAL 0.67m
AP: LANDING COMPLETE
AP: FINISHED

Frankly, it’s a miracle the video looked as good as it did! Clearly, there’s something wrong with compensating direction angles, as the OBSTACLE and AVOID angles should be ±90°.  Superficially this should be simple to fix, fingers crossed.


P.S. Based on the video, Sweep angles are correct; it’s my code calculation that’s wrong; for example, the final sample of the object at +40°should result of a result of -50° not 71°.

P.P.S.  The bug was crass; the log used the distance not direction, and the functional code is correct.  I suspect the problem’s solution is fine-tuning of the critical vs. warning ranges.

Penelope’s progress

I’ve done nothing on Penelope since my introductory post, but now I have reason to proceed:the new Raspberry Pi 3 B+ is already on its way courtesy of pimoroni combined with the new Garmin LiDAR-Lite v3HP and the new Raspian Stretch O/S.  Together these make the motivation I need though only in the background; my main focus is object avoidance with Hermione, and I hope to post on the first results imminently.  Oddly, what’s holding things back is hardware not software: construction of the obstacle.

Back to the mundane

After a great @CotswoldJam 6th #PiParty yesterday, it’s back to bug fixing; trouble is I only have symptoms and no idea of the cure.

Here’s the various processes running, all connected by shared-memory FIFO streams:

+—————+     (1)
|Sweep|——————>——————+
+—————+             |
              +—————+———+     (3)     +——————+
              |Autopilot|——————>——————|Motion|
              +—————+———+             +———+——+
+———+               |                     |
|GPS|———————>———————+                     |
+———+      (2)                            |
                                          |
                      +—————+     (4)     |
                      |Video|——————>——————+
                      +—————+

The problem is this: when using the GPS and Sweep processes individually, the system works beautifully, but together, the Motion process poll.poll() doesn’t pick up what the Autopilot process sends it.  From the logs for each process, GPS, Sweep, Video and Autopilot are working, sending their data to their neighbour; it’s just Motion that picks up just Video not Autopilot data from the FIFOs.

I can’t help but suspect that is hardware in some way:  The Raspberry Pi 3B has 4 CPUs; I have 5 processes and 4 FIFOs between them.

While I could continue working on the pond or object avoidance enhancements without GPS and Sweep working together, I’d very much like not to.  There’s will now be a short delay until I work out what to do next.

P.S. Ideas gratfully received!


Bug fixed, code updated on GitHub