First prototype and TAROS 2019

The first robot driving freely, the motion from the omniwheels bears a remarkable resemblance to the robots in simulation

A timelapse view of hinge motion on the first module, note that it is both rolling and pitching at once

We've had the first robot fully functioning for a while, but found a number of design flaws which prevent the first robot from acting as quickly or reliably as intended. These are mainly problems in the low level I2C communication protocol between the (Linux operating system) Pi Zero W master and the (realtime microcontroller) ATmega slaves, a fix has been worked out to mitigate the ways in which both the Pi's BCM2835 CPU and the ATmega328P chips have problems in their I2C implementations which become especially prominent when using a Pi as an ATmega328P's master. One of the key reasons for this is a well documented bug in the BCM2835's I2C clock stretching features, except under special circumstances the Pi does not respond properly, as per the specifications of the I2C protocol, to a clock stretch attempt by a slave device. Full implementation of our fix however required a redesign of the PCB, some extra traces to enable negotiation between the Pi and each ATmega in advance of I2C communication events, so wasn't possible on the first prototype.

One of the successful I2C data transfers between the Pi and an ATmega328P, this consists of firstly the Pi's write attempt to pass data down to the ATmega, then a request to have the Atmega send data back to the Pi

The effect of the I2C crashes is especially visible when controlling the hinge microcontroller which is programmed to hold the hinge's position when I2C fails and is forbidden from resuming motion until the bus recovers. Although the hinge is fully self-contained in terms of position tracking and can accurately accomplish a move from any given pitch-roll combination to any other without requiring input from the Pi, we decided that while it was acceptable to keep moving in the absence of I2C communication from the Pi the hinge should stop if it detects that the I2C bus has failed, otherwise it may keep moving to a previously desired position while the Pi is attempting to send it to another location but unable to get I2C messages down to it.

Below are some more still images taken from video of the first prototype:

The first prototype demonstrates raising the 2DoF hinge and rolling it

The first prototype shows the torque delivered by the hinge by lifting itself up on its front and rear docking ports

The second prototype is now nearing completion, and also contains some modifications to ease the manufacturing process for modules and avoid vulnerable wire-to-motor solder joints which have dogged the development of the first unit. Videos of that second module, including some where it docks with the first prototype, should be posted here during the weeks after TAROS.

We will be bringing the first prototype to TAROS 2019 to provide a live demonstration of a single module as part of our poster presentation on the Friday morning. We have produced an autonomous docking demonstration in which the prototype wanders randomly until it detects the 5KHz light of a docking beacon (made from a spare docking port) then aligns compasses, based on IR 38KHz messages carrying the recruiting port's compass reading, and moves in to connect hooks and dock. Videos of this docking demonstration sequence will be posted on this blog shortly after TAROS.


In the meantime here is a brief video of the first prototype's early testing, and some images of the first prototype's PCBs wired up outside the structural body during the development and debugging of the electrical design and low level software.

Testing of the 4 port PCBs and port faces together with the central PCB to which the Pi is attached (from below)

A closeup of one of the port PCBs and the internal side of the 3D printed face

Testing the second robot with components spread across the desk to enable easy access for oscilloscope measurements