More PCB progress and the forward hinge

The November PCB design passed most of the tests performed on it however had major problems with proximity sensing. The proximity sensing functionality uses the same phototransistors, op amp circuits and ATMEGA analog inputs as the infrared 5KHz cone sensing, except that while 5KHz guidance cone sensing looks for an ambient signal in the environment proximity sensing emits an occasional 5KHz pulse and measures the signal strength while it is in progress, which the microcontroller can then compare to the background readings of the signal when a 5KHz pulse was not in use. It turns out that the "surge" of current going into the LED when the LED is turned on for a pulse is enough to subtly pull down the 5V power rails all across the PCB, while the ATMEGA has bypass capacitors to prevent it restarting due to a low voltage condition there was nothing preventing these dips in the 5V line from reaching either the op amps or the 2.5V virtual ground on which the op amps rely. This meant that when the LED was flashed a 5KHz fluctuation in the 5V rail caused a small apparent signal in the first op amp, this was massively amplified and passed on to the next op amp. The op amps are very precisely tuned so as to cancel out noise in general, but 5KHz noise is instead treated as a signal. By the point where it reached the ATMEGA input pins the amplified noise signal was reading as brightly as a 5KHz emitter less than 15cm from the phototransistors. This was utterly drowning out any ability to sense reflected infrared 5KHz signals.

A 5KHz fluctuation in the 5V rail, it only took a few mV to generate huge fake signals in the op amps.

My first attempt was to use extra decoupling capacitors, especially around the op amp circuitry and phototransistors. However even with several MILLIFARADS added in the 5V fluctuation remained.

Yellow trace shows the voltage on the LED as it is switched on and off, blue shows the fluctuations of the 5V rail. This was with a several 100uF decoupling capacitors in use, the blue trace was even worse without them.

We are grateful to one of our technicians who recommended trying a π filter instead. Two capacitors and an inductor. This was constructed and tested on a breadboard equivalent of the relevant sections of the PCB.

Breadboard test of the π filter. The glowing LED on the right is emtiting 5KHz IR, a vertical shield prevents non-reflected light from the reaching receiving photransistor (left). Power to the op amp circuits is connected at the left end of this image, the inductor and one of the two capacitors of the π filter are just about visible on the right of the shield.

The π filtered waveform on the op amp's side of the inductor. Now free of unwanted 5KHz disturbance.

The PCB was redesigned to accomodate the inductor and the two capacitors, it was a difficult job to work out positions for them which would not collide with other sections of the omni-pi-tent robot when assembled but a few safe locations were found. After fabrication the new PCB achieved in testing everything that the earlier version had, except that this time the proximity sensing also worked and measured solely the efect of reflected 5KHz IR light, not the effect of voltage dips in the circuit.

Tests were also done with the new and old PCB both fitted to docking ports and both wired over I2C to a Raspberry Pi. Operation of docking hooks,  IR emitting, receiving and 38KHz communications were all operated succesffuly from the Pi as they will be in the completed robot. A problem with code timings causing 38KHz messaging and reception sensitivity to fall into synchronisation was found but overcome with the insertion of some randomised delays between transmissions.

Testing of two docking port faces with old and new PCBs attached both connected to a Raspberry Pi 3. A Zero W will be used in the finished robot.

In other news we've improved our module self-assembly algorithms, firstly we've been building on the multiple entry recruitment work of Liu and Winfield to make robot controllers which do not get stuck in states where docking will not possible at later times and to avoid conflicts between multiple robots attempting to dock to the same port. We've included features to allow robots to verify with certainty which port they are about to attach to, and escape the situation if they find themselves approaching a port they did not expect to. This has all been done using a V-REP simulation which includes sensor and actuator performance parameters determined from lab tests of prototype hardware. We've also found our methods resilient to motors running at some speed a level of error away from the desired speed, even at physically implausibly high levels of this error. Work has begun on a new, expected to be rather faster, self-assembly algorithm which we will compare to our equivalent (optimised for Omni-Pi-tent sensors and actuators as opposed to Liu and Winfield's SYMBRION units and with the above listed improvements made) of Liu and Winfield's Multiple Entry Recruitment work. More details of our new method to follow in a few months.


In yet other news, the 3D printed design elements are almost complete, but not quite everything has been printed yet. Expect mechanical construction to be completed, and pictures posted here, in January.

The forward sections of the hinge, and the array of microswitches to precisely monitor the hinge's angles, have all been printed and assembled.

Mounting of half of the inner parts of the hinge. The worm gear (white) is driven by gear motors positioned above and below it (not shown here). This driver the side cog (black) which also acts as a bevel gear against the forward cog (pink). When the other half o the hine is fitted the two worm gears can be driven in the same direction to elevate or lower the forward docking port, as far as the parts visible here are concerned that means rotating the inner hinge section (orange) about the same axis as the side cog. Or the two worms can be driven in opposition to leave the forward port at the same elevation (orange part maintains constant angle) but rotate the forward port about the axis of the forward cog. A similar mechanism to in the SMORES modular robot, but larger and made reliably non-backdrivable using worm gears.

A stacked series of 3D printed elements of the forward docking port. From the bottom upwards: the front bevel cog (as seen alone in the image above), adapts into a yellow mount with microswitches to detect roll angle, the forward omni-wheel (not shown here) sits between this yellow mount and the red component, the next yellow part is referred to as the back of the docking port and holds the rear end of the docking hooks (not shown here) as well as the port PCB, uppermost are the docking spikes in pink.

The forward parts of the hinge, showing the front bevel cog fitted into the elevating elements.

The forward port attached to the elevating front parts of the hinge.

The first Omni-Pi-tent module prototype, with ports assembled and the forward hinge also, only some central parts remain to be printed.

We've also breadboard tested a small LM386 based speaker system for our Pi Zero W, this will mount onto the central PCB and allow spoken status, error and debugging messages to be generated by a speech synthesizer (we've found espeak a good choice), there's no space for a screen or LCD of any kind so this will be the main way in which printf("statements"); are relayed to a human.

Breadboard test of Pi Zero W audio output filters, amplifier and speaker, with un-necessary components removed to save on space when it comes to PCB mounting.

Design of a pair of two layer central PCBs to accomodate the hinge controlling microcontroller and adapt between the 3.3V Pi and 5V docking port circuits is under way with the layout decided (mostly forced by shape and space constraints of 3D printed moving parts close to the circuit board) and routing in progress. I'm expecting to finish this in early January.

Our intention is to stick to two layer boards where posible such that fabrication is feasible by your typical small lab or workshop, there are quite a few SMD parts and multiple through hole components but all are relatively easy to fit using hand placed solder paste and an oven as well as a normal hand soldering iron. The first prototype module should be complete by the end of January, though making a nice C based API for programming it might come a little later.

More posts coming soon.