- Home
- Product Categories
- Arduino Shields
- ComMotion Motor Driver Shield
ComMotion Motor Driver Shield
This is the ComMotion Motor Driver Shield, a 4 channel motor controller that can communicate via I2C and be wirelessly controlled. This shield allows you to be able to control up to 4 motors at a time, read their encoders, and monitor their current draw all from one board. This powerful little shield fits snuggly on top of your RedBoard, Arduino, or any other development board that utilizes the R3 layout.
The ComMotion shield has been designed to drive 4 DC brushed motors at up to 2.5A continuous, each with peak currents of up to 4A per motor. With the preset configurations you will be able to easily control robots with omni or mecanum wheels by simply sending the ComMotion only three simple values: Velocity, Angle and Rotation. Onboard, the two ATmega328P processors will then do all the math required to calculate the correct speed for each individual motor.
Each ATmega328P processor even has its own serial port broken out into an FTDI header. These serial ports can be used for GPS, Bluetooth and LCD modules while leaving your Arduino serial port free for uploading and debugging code. The serial port on MCU2 is also broken out into a socket for an XBEE or WiFly wireless transceiver with voltage translation circuitry. While in the default configuration, the ComMotion shield will be able to accept serial commands directly from the serial port on MCU2. Just plug in a pre-configured Xbee, WiFly or Bluetooth module and you have instant wireless control!
Note: The supplier's supporting documentation was taken down by it's host site. Due to this vanishing support SparkFun is unable to offer technical assistance for this product at this time. We have drastically reduced the price of this shield as it is an at-your-own-risk motor driver. All sales are final and we will not be able to accept returns on this product if purchased after 11/23/2015.
- Two ATmega328P (16MHz) Processors
- Supply Voltage: 6V – 16V
- Logic Voltage: 5V @ 1000mA
- Wireless Support: Xbee / WiFly socket with voltage translation
- Xbee/WiFly Power: 3.3V @ 300mA
- Analog Inputs: 5x 10bit
- Motor Drivers: 4x FET“H” bridge
- Motor Current Continuous: 2.5A (each motor)
- Motor Current Stall: 4A (each motor)
- Current Monitor Range: 0A – 5A (each motor)
- Current Monitor Resolution: ~5mA (each motor)
- I²C Bus Voltage: 5V or 3.3V (selected by IO_REF pin)
- I²C Bus Speed: 100kbs
- I²C Addresses: 16 selectable pairs (software configurable)
- Serial Ports: 2x 5V TTL logic (FTDI headers)
ComMotion Motor Driver Shield Product Help and Resources
Core Skill: Robotics
This skill concerns mechanical and robotics knowledge. You may need to know how mechanical parts interact, how motors work, or how to use motor drivers and controllers.
Skill Level: Competent - You may need an understanding of servo motors and how to drive them. Additionally, you may need some fundamental understanding of motor controllers.
See all skill levels
Core Skill: Programming
If a board needs code or communicates somehow, you're going to need to know how to program or interface with it. The programming skill is all about communication and code.
Skill Level: Competent - The toolchain for programming is a bit more complex and will examples may not be explicitly provided for you. You will be required to have a fundamental knowledge of programming and be required to provide your own code. You may need to modify existing libraries or code to work with your specific hardware. Sensor and hardware interfaces will be SPI or I2C.
See all skill levels
Core Skill: Electrical Prototyping
If it requires power, you need to know how much, what all the pins do, and how to hook it up. You may need to reference datasheets, schematics, and know the ins and outs of electronics.
Skill Level: Rookie - You may be required to know a bit more about the component, such as orientation, or how to hook it up, in addition to power requirements. You will need to understand polarized components.
See all skill levels
Comments
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
Customer Reviews
5 out of 5
Based on 1 ratings:
2 of 2 found this helpful:
Works Well
After finding the documentation, I found this is fairly easy to use.
Hi, We'll add the link to the product page. But example code can be found here - https://sites.google.com/site/daguproducts/home/Software/ArduinoISP_and_IR.zip?attredirects=0&d=1 so sorry this wasn't listed before.
| | | WARNING! | | | RISK OF SHORT CIRCUIT!
I bought one of these boards and I placed in on top on my Arduino Uno and I failed to notice that the Uno's USB header's metal housing came in direct contact with the through-hole pins of the terminal block for motor 3 (M3). I powered on the board, a quick puff of smoke came out. I cut the power source, removed the board and quickly realized why the short-out happened. Consequently the MOSFET are blown out for M3. :(
I hope my mistake helps you avoid frustration.
I have ordered a new board but I am also going to try to replace the following components on the old board's M3 channel in the hopes that I can fix it. Qty 2 - A09T N-Channel MOSFET Qty 2 - A19T P-Channel MOSFET
I'll also post some working code once I get the new one. Updates to follow...
The ComMotion motor controller (Sparkfun PN ROB-13257) is a DAGU product resold by Sparkfun. It has a dubious current status (as of Oct 2015). The Sparkfun link to the "Product Page" no longer works. It previously led to the letsmakerobots.com website where as well as describing the board, many critical postings relating to the unfinished nature of the firmware for the board were also available in the forum area. These critical postings are also no longer available for viewing.
I've come across four situations now where the default DIP switch for setting the Board's I2C address is wrong as received from the manufacturer, preventing the board from working properly with the meager example driver software might be found on the Internet. If your board arrives with the four DIP I2C address switches set to ON, make sure you change them to all be set to OFF if you are using software that is configured to use the standard I2C default addresses of 30 and 31 for the board. (See the bottom of page 1 of the ComMotion Manual.pdf file)
The board does work as a basic speed controller with up to four motors, but many advanced features such as reporting individual motor currents, battery voltage and the like are not yet implemented in the firmware. In the pages that are no longer available at the letsmakerobots site, the board's designer stated that these advanced features probably would never be implemented because higher level managers at the company thought that support costs for the product were already too high.
If you are having trouble getting your board to work, I've posted example Arduino code at GitHub that you might want to try, that did indeed work properly once we got the DIP switches set right!
http://www.github.com/Blueglide/ComMotion
Good luck with it!
Thanks for the link to your Github. I have one of these boards and I hope to try your software.
It's too bad about the documentation at Let's Make Robots (LMR) being deleted. RobotShop purchased LMR and instituted new terms of service. If members of LMR didn't agree to the new TOS, all their posts were deleted. The person who designed the ComMotion board didn't agree to the TOS so all the his posts were deleted.
It was a very bizarre situation to see how quickly the new owners turned so many members against them in so short a time. If you read the comments of this Hackaday article, you can get an idea of what happened.
It says it can run continuously at 2.5 amps for each motor- does this mean i can run two or more motors at the same time at 2.5 amps continuous?
Also, if i wanted to power this via a 12v lead acid battery, what kind of current am i looking at to go into the shield? Would it be 2.5 x the max number of motors that will be running at one time?
This will be for an underwater ROV i am building, the motors are bilge pumps that will be used for thrust, 4 in total.
If my Xbee is attached to this shield, can I still use the Xbee communication for other wireless functions my Arduino needs, like triggering audio or does the ComMotion not give my Arduino access to the Xbee?
This is a great shield for R3 layout arduino's (why is is not listed under the Arduino shields? This definitely should be cross-listed)
Great to see the site was updated and this is now cross listed under the Arduino shields
How do I short the rst jumper?
I just received one of these boards. Sounded like a very powerful board as far as what all it does. I wish I would have read all the comments before I bought; wouldn't have bought it. I'm pretty new at these little controllers, just a hobby, no college for it. I know I will have some questions for you guys.
Has anyone succeeded in passing the parameters to this board? Just from reading, I'm not really sure.
Yes, it is a great board for controlling the motors if all you want to do is set the direction and speed of the motors - either as 4x individual motors, or have it do the calculations for Mecanum and Omni wheel configurations. If that is all you need to do, this board will be perfect and is easy to set up and use.
If you want (or need) to read back the encoder, motor current, or the analog values, this board currently will not do that. The code is all open source, so it can be fixed (and I am working on a version of it for that, but life keeps getting in the way of my hobbies).
Please post any specific questions or issues you may have here and I am sure someone will be willing to help you with it.
Hello!
Are you still working on a new firmware for this board?
Vitor Henrique
Can I control this Driver Shield with standard mega 2560 ore need uno?
Since it is an I2C peripheral, any system that has I2C will be able to control it.
So short answer, yes. I have successfully controlled the motors with it stacked over a red board, separate just running the necessary I2C signals, and from a Raspberry Pi (just running the I2C signals).
The wires you will need to run between the two are: GND, Vcc, I2C data, I2C clock, and IO_ref (hook this to your Vcc).
I had high hopes for this product. While there are a couple other quad motor driver boards, this was the only one I saw that could handle closed loop speed control within the board as well as allow me to query the motor's encoder and current values.
Unfortunately, it does not seem to come as advertised. While setting the motor speed works great - including the closed loop control on the board - it is not possible to query the motor's current or the encoder values - despite what is written in the board's documentation or on this (and many other) websites describing it.
I spent two weekends trying to get this to work - first with a Raspberry Pi, and then switching over to a Sparkfun Redboard. In both systems, I was able to quickly get the motors moving - which was great - but I hit a stumbling block when I tried to read anything back from the board.
I posted to the product page asking for help, and instead of help, I got comments about typical newbies issues of hooking up the power, or encoders wrong, or not reading the manual. When I posted my code for review, it was ignored. When I stated that even reading the internal battery voltage (which is not dependent upon the encoders), I got a question that perhaps the encoders were not wired properly.
I kept asking for a sample/demo/test code for the board, written for any controller, that showed the status was working. When I finally received that code, it was obvious it had never been executed as the values printed were done by "Serial.print("label"); value;" ... what? That doesn't print out anything - value is just thrown out by the compiler as a useless statement.
Looking at the source code for the ComMotion firmware, there are many errors with it - the biggest being that the logic to synchronize the two Arduinos to pass encoder and voltages back and forth was never completely implemented. This was not a corner case where something was not handled correctly - it was code that the author never finished, yet the board is being sold with the current documentation stating it works.
I have requested many times for help on how to get this resolved, but the author does not seem interested. This does not speak very highly of him, or of the company DAGU. The developer stated he was under pressure to finish it under a tight deadline, but even so, that was months ago - there has been no time since then to look to resolve the issue?
If the board documentation did not include the status readback functionality, I would have been very satisfied with the board as the other functionality is working correctly. Perhaps I would have still purchased the board, but I would not have wasted so much time/energy trying to understand why my code doesn't work, when it was never my code.
Go to the product page linked above to see the discussion and the lack of support for this product.
I am NOT blaming Sparkfun - they have always been a great company - in this case they bought something that was not as advertised.
I ordered my ComMotion board about 2 months ago and finally got to working with it last night. I am interfacing it to a Raspberry Pi via I2C and wrote a library for the first 5x functions (all the write functions). I then discovered that the protocol for reading back the status data (motor currents, encoder counts, etc) is based on a non-standard I2C specification where 2 bytes are sent during a read (SMBus and I2C send only a single command byte to read data) and hit a brick wall on that so I went to bed.
This morning, I try the program again and noticed I was getting IO errors when I attempted to talk to the i2c bus and spent about an hour trying to debug my program. I finally decided to drop back to the basics and ran i2c-detect and then discovered my problem. When the ComMotion board is first powered on (or reset), it responds to most of the I2C addresses (my board's addresses are 0x12/0x13:
pi@raspberrypi ~/commotion_i2c $ sudo i2cdetect -y 1
00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- 12 -- -- -- -- -- -- -- -- -- -- 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77
Then I run the command immediately again, and all of the addresses respond.
pi@raspberrypi ~/commotion_i2c $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77
There are no other I2C devices on that bus, and if I disconnect the ComMotion board, all the devices disappear. So it looks like my board is somehow scrambled and basically useless to me now.
I posted a bit more details to the product page over at:
http://letsmakerobots.com/commotion-shield-omni-and-mecanum-wheel-robots#comment-129039
The user manual mentions the ability to modify and upload new code to this board - where can we find the source code for the default load on this board?
Btw, i just placed an order for 1 for a mecanum based robot - looks like a great product and I am looking forward to using it. I plan to control it directly from a Raspberry Pi via the I2C port.
I found a second Product Page called "ComMotion Shield in action!". It has a link to a source code zip file. http://letsmakerobots.com/commotion-shield-action
I wonder why the firmware only supports omni-wheel configurations but doesn't also support differential drive (i.e. tank drive) for 2 wheeled or tracked vehicles. I see that you can control the motor speeds directly but that's a bit too low-level. It would be nice to be able to upload some specs to the board on startup (i.e. wheel diameter, number of encoder pulses per wheel revolution, and distance between drive wheels) and then be able to give commands such as turn with r radius (0 for pivot turn) at speed v for d degrees (negative value for left turn, positive for right) to allow for nice smooth turns. Most differential drive robots I see seem to always use 0 radius pivot turns which makes for very, well, robotic motion, which is also probably hard on drivetrains when they have to suddenly reverse motors for a turn. I know it is easier to navigate by changing heading in a point, but it would lead to smoother motion if you could turn on the go, and if the radius is wide enough, you wouldn't even have to reverse a motor. Oh, if differential drive ever gets thrown in, might as well add some "dead reckoning" position tracking for both modes (omni-wheel and differential drive). Yeah, it won't be very accurate, but it would give a bit more of a "leg up" to anybody starting a robot project. At the very least, you'll at least be able to demo more functionality quicker as you build.
The firmware has configurations for omni and mecanum wheels because these wheels can be difficult for beginners. The ComMotion shield does all the trigonometry for you.
Differential drive is much simpler and often only uses 2 motors (left and right). In the case of a 4 motor Rover 5 chassis with treads, the same speeds are given to the front and rear wheels for left and right. Individual motor control is the easiest way.
The ComMotion shield firmware is written using Arduino 1.04 and programmed using a RedBoard running the ArduinoISP sample code. You can modify the firmware if you wish.
Is that heatshrunk through-hole resistor rework in the third picture on the production boards? That smells like a prototype.
The resistor was added for the Scamper robot kits which use the demo code without an Arduino board. The resistor links the I2C pullup resistors to the logic voltage.
In a way it was an afterthought because all the development was done on a SparkFun Redboard which does not need the resistor.
If your using an R3 Arduino board with an IO_REF pin (such as the SparkFun Redboard) then the resistor can be removed. Future revisions will have an SMD resistor and a solder link.
Am I reading this right or missing something, "Logic Voltage: 5V @ 1000mA" ? That's a lot of current for an i2c bus...
No, you are not reading it right. The ComMotion shield has it's own 5V and 3.3V regulators. It is designed so that it can run from a seperate battery pack to the Arduino board if required.
The 5V regulator can deliver up to 1A of current for powering sensors and the 3.3V regulator. The 33.3V regulator can deliver up to 300mA which is enough for most Xbee and WiFly modules.
The I2C bus only draws a few milliamps through the pullup resistors.
It can supply 1000mA of 5V logic power. You can use that to power the Arduino that may be attached or a GPS or any number of other things. It doesn't really have anything to do with the I2c bus.
I think someone forgot to complete a thought in the text above, "With the ComMotion you will be able This powerful little shield fits snuggly on top of your RedBoard, Arduino, or any other development board that utilizes the R3 layout."
Fixed! Thanks for the catch, that was
True, but at lease we now know you will be able with the ComMotion.
LOLz