July 2, 2014
I was inspired to create the ComMotion shield after building my robot Scamper. It took a reasonable amount of work to get the encoder feedback working how I wanted and I knew it would be much harder for a beginner.
ComMotion is a shield designed specifically for robots that use omni or mecanum wheels. These robots need to drive 3 or 4 motors with encoder feedback. As I was designing the shield I realised I had 2 serial ports going to waste so I added a socket for a bluetooth module and another for Xbee / WiFly. Hence the "Com" in the name ComMotion.
The Shield is designed specifically for a SparkFun RedBoard as that was what I had lying about when I designed it but should fit on any R3 board that has the dedicated I2C pins (fingers crossed).
The ComMotion shield has 4x FET "H" bridges with current sensing rated at 12V, 2.5A each. Controlling these "H" bridges are 2x ATmega8A processors. Each processor monitors 2 encoders and controls 2 motors. All communications between the Arduino and the shields two ATmega8A's are done using I2C with the address selected by a set of dipswitches on the shield. This leaves all the other Arduino pins free for other shields, sensors etc.
The ComMotion shield effectively gives your Arduino two additional serial ports. These can be accessed directly by the FTDI sockets. The serial ports on MCU1 is completely free and could be used for devices such as an LCD display that has a serial interface or a bluetooth module.
The serial port on MCU2 has a socket for a DAGU bluetooth module plus the 3.3V regulator and translation circuitry for an Xbee or WiFly module.
Bells and Whistles
The shield has it's own 5V@1A and 3.3V@300mA voltage regulators so it won't load up the regulators on the Arduino. As the shield is actually two Arduino's anyway you can program them directly if you wish and leave your Arduino free for other projects.
An advantage of being I2C controlled is that the shield can also be controlled from another type of controller such as a Picaxe, Raspberry Pi, Beagle Bone, Propeller etc.
A bi-colour LED on each motor output can be useful for debugging even when no motors are attached. RX and TX leds are fitted for the wireless interface on MCU2. 5V and 3.3V power indication LEDs.
The reset button on the shield is tied to the Arduino reset pin via the ISP socket so it doesn't matter that the shield blocks the reset button below.
A battery voltage monitor allows the shield to shut down if the battery voltage falls below a preset level.
The board comes pre-programmed (no bootloader) but can easily be re-programmed using your Arduino as an ISP programmer.The PCB has a female header underneath that plugs directly into the Arduino ISP header. A small 3 position switch allows you to select the processor to be programmed with the center position being NC (not connected). If you choose to install bootloaders then there is an FTDI socket for each processor.
I'm now working on the software. At the moment the planned features are:
- Automatic current limiting for each motor (configurable).
- Low battery shutdown (configurable).
- Pre-programmed configurations for 3 or 4 omni wheels, mecanum wheels or individual motor control.
- Just 3 integer command needed for omni and mecanum wheels - Speed, Angle and Rotation.
- Just 4 integer command for individual motors - 4 speeds with negative numbers reversing the direction.
- All configurable settings such as maximum current for each motor stored in EEPROM.
- Use motors as speakers to indicate fault conditions and play music.
- Access to 5 spare analog / digital IO pins for additional sensors / LEDs etc.
- Rated for 12V systems where peak voltage may be as high as 15V when batteries are fully charged.
- 5V L4941 5V LDO regulator rated at 1A with an input of 7V.
- 3.3V MC33375 LDO regulator rated at 300mA for powering Xbee / WiFly modules.
- 4x FET "H" bridges rated for 2.5A (4.2A peak) - maximum "ON" resistance is 98mΩ.
- 4x Current sensors with 100mΩ shunt and 10:1 gain (1A = 1V).
- 4x Encoder inputs using external interrupt pins.
- 2x ATmega8A MCU, 5V @ 16MHz with 512bytes EEPROM, 1K SRAM, 8K FLASH.
- 4 layer PCB.
Update: 5th July, 2014
Testing the PCB has not gone well as there appears to be a short in the 5V supply.
After talking to a few people I will be modifying the PCB anyway so that the I2C control lines pullup to 3.3V instead of 5V. This should still work fine for 5V controllers but will be safer for 3.3V controllers.
Update: 15th July 2014
After a few Frankenstein style modifications and some hotglue the power problem was solved but then I had the problem I could only program MCU1 through the RedBoard's ISP header (Using the ArduinoISP example code). However when using an external ISP programmer both MCU's could be programmed. There seems to be another problem with the PCB. In the end I soldered a jumper wire to the reset circuit and plugged it into D10.
There was some problems with my initial design because of the shared ISP header but that's solved now. I now need to add an extra jumper for connecting the reset circuit to D10 for programming. Previously this was done by the programming switch but I now need that part of the switch for the MOSI connection.
The 4 "H" bridges test fine at 12V using a small motor. Later I'll test with bigger motors under load to make sure electrical noise from the motors won't crash the processors. I want to enable the brown out detection in the processors to prevent the memory being corrupted by flat batteries. In the past I have had trouble with the brownout detection being too sensitive so this also needs more testing.
The new PCB will have the I2C pullup resistors connected to the IOref pin as suggested by 6677.
Update: 6th August 2014
I got the new PCB a few days ago. It all seems to be working fine now. Although the ComMotion shield does not use the Arduino bootloader I found it was still necessary to install the bootloader first in order to set the fuse bits. When you use the "Upload Using Programmer" option in the Arduino IDE.
I've editited the "Boards.txt" so that brownout detection is enabled and set to 4V. This will prevent the code being corrupted when batteries get flat. Once the bootloader is loaded I can then overwrite it using the "Upload Using Programmer" option without affecting the fuse settings.
To program the board with an Arduino running the ISP programmer example code you must first set a jumper to connect the reset to D10 of the Arduino. After that the switch selects which MCU is connected to the ISP socket.
I've also added a jumper to let you disconnect the Arduino Vin from the ComMotion's Vin. This allows you to power the motors from a separate power supply to the Arduino if required.
As you can see from the top and bottom views, the board has a lot of parts. We ended up making this a 4 layer PCB so that the board could be small and still have wide, high current tracks to power the motors. The 4 layers are:
- The top layer has all logic and communications circuitry.
- The groundplane shields the top layer from the electrical noise and also works as a heatsink for the 5V regulator.
- This layer consist of large power tracks to handle high currents as each motor can draw as much as 4A.
- The bottom layer has all the high current motor control components.
I'm now testing the ComMotion with a SparkFun Redboard on the new Scamper robot.
The Scamper Kit will come in a Quality case rather than the usual carboard box. I'm going to add an IR sensor to the kit and write some demo code for a spinning line follower and maze solver. This will allow beginners to have some fun with the robot as soon as it's assembled.
Update 18th August 2014
Unfortunately the ATmega8's ran out of memory. I've written one program that is uploaded to both processors. The PCB uses A2 as an ID pin which is tied to Gnd on MCU1 and tied to Vcc for MCU2. The program itself does not use an excessive amount of memory and worked fine with the EEPROM and Wire libraries included but hit the limit once the Serial library was added.
As such I've switched to ATmega328's. The difference in price is small so I'm sure some people will ask why I bothered with the ATmega8A to begin with. The fact is I do not like waste and considering I was only short by 1 or 2K makes me feel that most of the additional 48K added (24K for each processor) is being wasted.
On the up side, it allows plenty of room for additional code if customers want to take full advantage of the extra 2 serial ports.