Let's Make Robots!

Prototyping ComMotion


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 Heart

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.


Wireless Communications

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.


Electrical Specifications

  • 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:

  1. The top layer has all logic and communications circuitry.
  2. The groundplane shields the top layer from the electrical noise and also works as a heatsink for the 5V regulator.
  3. This layer consist of large power tracks to handle high currents as each motor can draw as much as 4A.
  4. 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.






Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Pullup to the IORef pin. On a 3.3v board the IORef pin should be powered from the 3.3v output and on a 5v board it should be the 5v output (and on the intel galileo, its jumper selectable). Its next to the reset pin, other side from the 3.3v and 5v pins. Was introduced to solve the issue of shield compatibility across the mix of 3.3v and 5v systems now out in the wild.

Even though analog inputs are used for the I2C bus they are being used as digital IO pin so the analog IO reference pin has absolutely nothing to do with compatibility in this case.

I will still have the analog IO reference tied to 5V so that the analog inputs can work with signals up to 5V without damage. The I2C bus pins however will be pulled up to 3.3V so that 3.3V controllers will not be damaged. Even though the inputs on the comMotion are 5V inputs, a 3.3V signal is still recognised as a logical 1.

Even though analog inputs are used for the I2C bus they are being used as digital IO pin so the analog IO reference pin has absolutly nothing to do with compatibility in this case.

IOREF is not the analog reference (AREF). It is a new arduino 1.0 header pin intended for defining what voltage a shield should be using for digital logic.

ARef is located up on the digital 8-13 block next to the ICSP header for the onboard serial adapter. IORef is located down on the power headers next to the capacitors.


Quoting from the arduino 1.0 layout changelog:

  •  1.0 pinout: added SDA and SCL pins that are near to the AREF pin and two other new pins placed near to the RESET pin, the IOREF that allow the shields to adapt to the voltage provided from the board. In future, shields will be compatible with both the board that uses the AVR, which operates with 5V and with the Arduino Due that operates with 3.3V. The second one is a not connected pin, that is reserved for future purposes.



Its an output pin only not an input and has nothing to do with AREF. 3.3v boards it will be tied to 3.3v, 5v boards it would be tied to 5v. If the i2c was pulled up to IOREF then it will be pulled up to whatever voltage the host board runs at.

I'd say its entirely relevant.

Although the board will work fine with the I2C pullups always at 3.3V I have updated the schematic with your suggestion so the next revision will use the IOref pin however, programming via the ISP must be done with a 5V controller.

Sorry, I got my reference pins mixed up. Currently the shield ignores the IO ref pin. Because most Arduinos have that HUGE USB socket on them the ComMotion sheild will not fit them anyway (without another shield in between).

So for now it looks V1.0 of the ComMotion shield will only work with 5V boards that use a mini USB socket such as the SparkFun Redboard.

this may well be the first shield I actually buy

Another cool board OddBot.

Have you used it yet to control either an omni wheel bot or Mecanum wheeled bot?

I see you have a few extra pins. Have you ever used Nordic nRF24L01+ modules? They're super inexpensive. They're not as easy to use as a XBees but I think there's some pretty good Arduino code for these transceivers. IMO, they're a great way to add inexpensive wireless to a project. Maybe you could arrange the headers of the extra pins in a way to make these little modules easy to plug in to the board?

One more thought (I'll write here). With all the motion going on with Mecanum and omni wheels, a spot to plug in a MPU6050 board would be nice. I suppose the main processor could handle communication with gyros and accelerometers.

BTW, I was just playing with a MPU6050 on a BaseCam unit and it was rock solid. I couldn't figure out how they could possibly keep the gyro reading so steady but they did.

You might need a preemptive strike on this one. You know I love multiprocessor projects.

Settle down Duane. I just got the PCB last night. When I have the shield working I will post a robot project with video. When the board is available for sale I'll do a forum or something.

Now I am only blogging the prototype testing. First I need to check that everything actually works. I have not used a single ISP header linked to multiple processors before so it could fail before I even program it.

There's no more room on the PCB for another socket. This board is absolutely crammed full of components and we had to use 4 layers to fit every thing in and still have large power tracks. I've updated the post with better pictures.

All those modules you mentioned can be connected easily with some jumper wires. Ideally there should be shields made for them. I only put the Xbee socket in because they are so popular and now that there is the WiFly module you have two options with a single socket.

I have not done many multi-processor projects before. I'm sure someone will tell me I could have used a single ARM processor (or Propeller) but I wanted to keep it all Arduino compatible since that's what most hobbyist understand.

Despite being an Arduino based shield you could still use this with a Propeller since it is all controlled via I2C.

There is also a propeller board with arduino shield headers.



Sure you could have used ARM, MSP430, propeller, picaxe, plain pic or anything on that shield. Any real advantage though when the AtMega8A can do it just fine? Msp430 and arm have more external interrupts (encoders) than AVRs usually have and often cost less to boot, but it is a new set of tools for hobbyists to learn, dagu of course need new hardware forcprogramming them (no ICSP there) and its another component to stock. Even if there was some humungous advantage in switching, I can still see the point in remaining with the atmega.

We do have an engineer who's expertise is ARM processors and as you point out, an ARM MCU would be cheaper but it would actually be a disadvantage to many hobbyist including myself.

For now I have used ATmega8's because they are cheaper. I can always upgrade to ATmega328's if I need more memory for the software as the chips use the same pin layout.

I'll have to get a sample of that Propeller board you mentioned.