Robotics Shield

Robotics Shield for GAFFORDuino644

This is a dual-axis motor and sensing shield for the GAFFORDuino644. Based around the L298N H-bridge driver, it has the capability of driving two brushed DC motors with up to 2A continuously. This board is unlike many other L298N-based driver boards in that it provides a host of sensing feedback for closed-loop control applications. (two current sensing outputs, two quadrature encoder outputs, and three-axis acceleration data).

Dual Brushed DC Motor Drive

Based on the (somewhat dated) L298N H-bridge driver IC, this board can simultaneously deliver 2A of current to each motor simultaneously. Beefy Schottky rectifiers prevent the rest of the board from the inductive kick when the motor current switches.

Low-Level Analog Current Sensing

The drive side features two 0.5 ohm, 5W power resistors used for sensing the current passed through each motor. The output is filtered through 10Hz low-pass filter, thereby averaging the PWM and providing DC-level analog outputs to pins A0 and A1 through solder jumpers. Current can be calculated based on the analog voltage reading: I = 2V.

Built-In Quadrature Decoding for SPI

High-level motor control is enabled by two 32-bit LS7366R-S Quadrature Decoder-to-SPI IC's, which each take in single-ended encoder inputs (A, B, and Index) and output the encoder counts via SPI interface, thereby offloading the burden of requiring the Atmega644's hardware interrupts to keep track of encoder counts. Dedicated 30 MHz crystal oscillators for each LS7366R provide precise timing. Solder jumpers provide the option of pulling up the A, B, and IDX pins to 5V via 10k resistors.

Breakout Headers for MM8451 Nine-Axis IMU

Perfect for mobile robotics applications, the board features a breakout header that is compatible with the MM8451 three-axis accelerometer breakout board provided by Adafruit. IMU data is sent to GAFFORDuino644 via I2C.

Board Design

The board is roughly split in half, with the high-level sensing circuitry (encoders, accelerometer) on the left, and the drive circuitry and low-level current sensing on the right. Isolated ground planes and a carefully-designed ground path ensure that the noisy ground produced by the motor driver does not couple to sensitive digital and analog MCU ground planes. I tried my best to use through-hole components exclusively but could not get around the use of a few surface-mounted SO1-14 packages for the quadrature decoders (but the pads should be big enough to solder to by hand without significant difficulty).

Robotics Shield Board Design in Eagle CAD

Fabricating

I ordered 5 PCBs from jlcpcb.com (once again, impressed with their quality, customer service, cost and lead time). The silkscreen is a little off in some places but not enough to detract from the overall quality and appearance. The SO-14 decoder chips were not too difficult to solder by hand, and all the surface-mounted components fit as intended with no interferences. I realized that the flyback diode package I used is only implemented in avalanche diode form which is not ideal for rectification since they break down at a very specific reverse bias voltage, but I went ahead with it and ordered the 1N5061CT rated at 600V reverse bias and 2A average rectified forward current (I would hope that any motors I use with this board don't generate 600V inductive kicks but that remains to be seen; if at some point the MCU fries then at least I'll know what happened).

Fabricated boards: (left) front side, (right) back side

Populating and Testing

I was able to get motors spinning relatively quickly, much to my excitement. I hit a small snag in the realization that one of the input logic pins I was using for Motor 2 (specifically IO21) is a JTAG programming pin, so I had to disable some JTAG fuses first in order to use it as general purpose I/O. If I decide to re-design the board, I'll change this pin. After figuring that out, I was good to go. See video below which shows the motors executing a sinusoidal trajectory.

As far as sensing goes, the current sensing works like a charm. I was able to get encoder readings from Encoder 1 through SPI, but have not had luck getting any readings from number 2. It's not clear to me why, as they have the exact same wiring (and share the same SPI lines), and if anything I would expect 2 to work first since the trace lengths are much shorter/less likely to be contaminated by noise. I did a continuity check on all the pins, verified that the chips was properly powered/grounded, and took some voltage readings on the encoder inputs to verify functionality, and everything checks out. I also ruled out any programmatic errors. I'll have to take the board into lab and scope the 30 MHz clock lines to ensure functionality before I can blame the problem on a bad chip. So TBD on that. I'm still waiting on the 9-axis IMU but I expect that to be pretty plug-and-play.

Populated/Functional board: (left) stacked on a Gafforduino, (right) functionality check (driving two motors with a sine wave simultaneously)