Tour of the main PCB

As mentioned in my previous post, this year we needed (an excuse) to learn KiCad and build a custom PCB.  Thankfully, we did succeed in soldering it up , despite the tiny pitch on some of the components.

Picture of the board

The PCB dives into a few parts.  I expect you’ll all recognise the Pi header in the top left.  Above that, in yellow on the annotated image, we have the SPI peripherals: the screen and the IMU (which we use mainly for the gyroscope).

Annotated board
Yellow: peripheral connectors; Pink: Parallax Propeller; Green: Time-of-flight sensor connectors; Red: Isolation chips

Below the header, in pink, we have the Parallax propeller chip, a fast microcontroller that we use to decode the signals from the motors.   Each motor can put out 200k pulses per second, which isn’t really possible to handle from the GPIO pins because Linux can’t really handle that many interrupts per second.

To the right, in yellow, we have connectors for the “noisy” off-board components.  These sit over their own ground plane, so that, if we want to, we can drive them from a completely isolated power supply. From top to bottom:

  • “noisy” 5v power
  • motor driver control 1
  • motor encoder 1
  • motor driver control 2
  • motor encoder 2
  • servo controller
  • 2 x power monitors

To bridge the gap between the microcontroller and the noisy world of the motors, (in red) we have a pair of ISO7742 chips.  These provide two input and two output signals, which are level shifted from 3.3v to 5v and are  isolated through an internal capacitor.  Unlike an optoisolator, they were super-simple to use, requiring 3.3v and 5v power and grounds, a couple of decoupling capacitors and some pull-ups on their enable pins.

Similarly, below that, we have an isolated i2c line for driving the servo board (which runs from the “noisy” 5v power supply.

In the bottom left (in green) we have 6 connectors for optical time-of-flight sensors.

The time of flight sensors, Propeller, servo controller and voltage monitors are all i2c controlled, which poses a couple of problems:

  • i2c busses tend to become unstable with more than a handful of devices (because each device adds capacitance to the bus, making it harder for any device to drive the bus)
  • we have no control over the addresses of many of the devices; for example, all the time-of-flight sensors use the same address.

To address those problems, we included an i2c multiplexer in the design (to the left of the Propeller), allowing us to switch any combination of devices on and off the bus.

Multiplexer schematic
Multiplexer schematic
Picture of the multiplexer

Despite having very little space to play with, we were able to squeeze in a bit of prototyping area, which we’ve used to address errata.  For example, I found that I’d missed a couple of pull-ups on the i2c port that the propeller was attached to.  A bit of thin kynar wire to the rescue:

Leave a Reply

Your email address will not be published. Required fields are marked *