Daughter boards for microcontroller systems, whether they are shields, hats, feathers, capes, or whatever, are a convenient way to add sensors and controllers. Well, most of the time they are until challenges arise trying to stack multiple boards. Then you find the board you want to be mid-stack doesn’t have stackable headers, the top LCD board blocks the RF from a lower board, and extra headers are needed to provide clearance for the cabling to the servos, motors, and inputs. Then you find some boards try to use the pins for different purposes. Software gets into the act when support libraries want to use the same timer or other resources for different purposes. It can become a mess.

The alternative is to unstack the stack and use external boards. I took this approach in 2013 for a robotics competition. The computer on the robots was an ITX system which precluded using daughter boards, and USB ports were my interface of choice. I used a servo controller and two motor controllers from Pololu. They are still available and I’m using them on a rebuild, this time using the Raspberry Pi as the brain. USB isn’t the only option, though. A quick search found boards at Adafruit, Robotshop, and Sparkfun that use I²C.

This approach has challenges and benefits. A stack of daughter boards makes a neat package, where external boards makes a tangle of wires. Random sizes can make mounting a challenge. Providing power can also be a hassle because of the random placement of power pins. You can’t rely on USB power, especially from a Raspberry Pi whose USB is power limited.

On the other hand, external boards can offload processing from your main processor. Once a command is sent, these boards handle all the details including refresh requirements. They are likely to provide capabilities beyond the microcontroller software libraries since their processors are dedicated to the task.

I am using an 18-channel board from the Pololu Maestro Servo Controller family of boards that control from 6 to 24 servos using a single board. You might find the Adafruit 16 channel I²C board a useful alternative. For motor control I turned to the Pololu Simple Motor Controller family using one that will handle 18 amps. Others will handle from 7 to 25 amps. Or consider the Sparkfun Serial Controlled Motor Driver. Another source for USB controllers is Phidgets. I experimented with one of their spatial devices for the original robot. I should have used it to measure the tilt since one of my robots rolled over on a hill. Ooops!

Servo Control

The board currently installed on my robot is the Mini Maestro 18. The Maestro provides control over the servo speed, acceleration and movement limits. A home position can be set for startup or when errors occur. You can even do scripting or set movement sequences to play on command.

On the hardware side, the Maestro also allows channels to be used for digital input or output, and some channels for analog input. On some there is one channel for pulse width modulation output. An onboard regulator converts the servo power input to the voltage needed by the processor, simplifying part of the power distribution challenge.

My previous robot used the Maestro to control pan and tilt servos for camera positioning, a servo to lift samples from the ground, and a safety LED. Two analog inputs from current sensors on the motors helped avoid burnout during stalls, and four inputs from a simple RF key fob transmitter provided control. The latter came in handy for testing. I’d program a test sequence such as starting a 360° camera scan for landmarks or drive onto the starting platform and drop the sample. A button press on the key fob would initiate the activity. One button was always set up as an emergency halt to stop a rampaging robot. The rebuild is following this pattern with some additions.

Motor Controller

The two Simple Motor Controllers (SMC) each handled the three motors on either side of the Wild Thumper chassis. The SMC does more than just control the motor speed and direction. You can set acceleration, braking, and whether forward and reverse operate at the same or different speeds. The board monitors a number of error conditions for safety. These stop the motor and prohibit movement until cleared. Such blocking errors include lost communications, low input voltage, or drivers overheating.

An additional capability I found extremely helpful is the ability to read signals from a radio control (RC) receiver. These signals can be used to control the motor and, with some cross wiring between two controllers, provide differential drive control. This is useful for driving the robot to a new location using an RC transmitter. I didn’t use the RC inputs directly. Instead I read the RC inputs and issued the control commands from my program. This let me monitor the speed in my program logs for correlation with the other logged data. I also used an input to command the robot into autonomous or RC control operations. There are also two analog inputs that can be used to directly control the motor and can be read through commands.

Serial Communications

USB ports were my choice for communications but there is also a TTL level serial port with the standard RX and TX pins. This port can be used by the Raspberry Pi, Arduino, or any other microcontroller that has a TTL serial port.

The Maestro boards using USB appear as two serial ports. One is the command port that communications with the Maestro processor. The other is a TTL port. This port can serve as simply a USB to TTL serial port converter to allow communications with other boards, even from another vendor. Another use of the TTL port is to daisy chain Pololu boards. I could attach the SMC boards in this manner and save two USB ports for other devices. These boards support this by having a TXIN pin that ANDs the TX signal from the connected board with the TX on the board.

Both of these controllers support a few different communications protocols. I use the one Pololu created and is available on some of their other products. The command details are different between the boards, but the basic command structure is the same. They call it their binary protocol, and the basic format follows:

0xAA, <device address>, <command>, <optional data>, <crc>

All the fields are single bytes except for the data field which is frequently 2 bytes to transmit 16-bit data. The returned data is only one or two bytes with no additional formatting. Note they provide for detecting errors in the message by using a CRC (cyclical redundancy check). This is probably not critical over USB but a TTL line might receive noise from motors, servos, and other devices. A CRC error sets a bit in the error register that can be read if the command is critical.

I wrote my own code, C++ of course, for the PC and converted it just now to the Raspberry Pi. The main change is the different serial port code needed by Linux and Windows. Pololu now provides Arduino source for the protocol making it easy to use these boards with that family of controller boards.

Wrap Up

The chassis, Pi, and these boards are now installed on the Wild Thumper chassis along with a pan and tilt controlled by servos. A safety LED is on when power is applied and flashes when the robot is actively controlling the system. A LiPo battery powers all but the Pi because I need to configure a battery eliminator circuit to provide five volts. I’m powering it temporarily using a USB battery pack.

A test program, cross compiled from my desktop, moves the robot forward, pivots left than right, and then reverses. The pan / tilt moves and the LED flashes. I originally used a web camera for vision processing but will switch to the Pi camera since it is better. The Neato lidar discussed in a previous article will soon find a place onboard, along with an accelerometer to detect possible rollovers.

I’m sure I could have done this using Pi daughter boards despite the challenges I mentioned earlier. There are trade-offs to both approaches that need to be considered when working on a project. But there is one final advantage to the external boards: they have a lot of twinkly LEDs.

Product photos from Pololu.

[Vlad] wrote in to tell us about his latest project—an RC boat that autonomously navigates between waypoints. Building an autonomous vehicle seems like a really complicated project, but [Vlad]’s build shows how you can make a simple waypoint-following vehicle without a background in autonomy and control systems. His design is inspired by the Scout autonomous vehicle that we’ve covered before.

[Vlad] started prototyping with an Arduino, a GPS module, and a digital compass. He wrote a quick sketch that uses the compass and GPS readings to control a servo that steers towards a waypoint. [Vlad] took his prototype outside and walked around to make sure that steering and navigation were working correctly before putting it in a boat. After a bit of tweaking, his controller steered correctly and advanced to the next waypoint after the GPS position was within 5 meters of its goal.

Next [Vlad] took to the water. His first attempt was a home-built airboat, which looked awesome but unfortunately didn’t work very well. Finally he ended up buying a $20 boat off of eBay and made a MOSFET-based motor controller to drive its dual thrusters. This design worked much better and after a bit of PID tuning, the boat was autonomously navigating between waypoints in the water. In the future [Vlad] plans to use the skills he learned on this project to make an autopilot for the 38-foot catamaran his dad is building (an awesome project by itself!). Watch the video after the break for more details and to see the boat in action.

Brushless motors are ubiquitous in RC applications and robotics, but are usually driven with low-cost motor controllers that have to be controlled with RC-style PWM signals and don’t allow for much customization. While there are a couple of open-source brushless drivers already available, [neuromancer2701] created his own brushless motor controller on an Arduino shield.

[neuromancer2701]‘s shield is a sensorless design, which means it uses the back-EMF of the motor for feedback rather than hall effect sensors mounted on the motor. It may seem strange to leave those sensors unused but this allows for less expensive sensorless motors to work with the system. It also uses discrete FETs instead of integrated driver ICs, similar to other designs we have covered. Although he is still working on the back-EMF sensing in his firmware, the shield successfully drives a motor in open-loop mode.

The motor controller is commanded over the Arduino’s serial interface, and will support a serial interface to ROS (Robot Operating System) in the future. This shield could be a good alternative to hobby RC controllers for robots that need a customizable open-source motor controller. The PCB design and source code are available on GitHub.

Read the full article on MAKE

I have an Uno controlling a 4 channel Dagu motor controller with encoder support. Got this a month ago. (It's the red PCB version).

Although it works, I have read that I shall not power the motors before powering the control logic.

But does that really mean that if the controller voltage dies out in the field, and there's still juice in the motor batteries, the Dagu controller will burn ?

I saw OddBot said this might be the case, at least if you powered it up in the wrong order.

read more

Aahhmm...Behalf of my Majestic Awesomeness, 

I would like to ask a QUESTIONs that bothers me always when thinking about the Purpose of Motor Controller. 

I was reading about the Lessons in How to Make a Robot in http://www.robotshop.com/gorobotics/articles/how-to-make-a-robot-lesson-1 

then I found out that we need Motor Controller in order to control the Actuators.

Micocontroller and Motor Controller must work together in order to operate a Robot.

read more

Hi all.

I am really new to robotics, and only just recently got my arduino uno. i've played around a bit here and there to learn how to control servo's and such, so i figured it's time for me to build my first robot. but in the design, i've come across a few problems:

read more

Never one to pass up the recycle pile at work, [Scott] usually doesn’t find much. A few old hard drives, maybe a ancient laptop every once in a while, but on very rare occasions he finds something actually useful. This latest haul is a gaggle of stepper motor drivers that, with a bit of work, can be reverse engineered and turned into an Arduino.

After prying into one of the plastic-enclosed boards, [Scott] found a LED, a quartet of transistors for powering the motor, and an ATMega168 microcontroller. Interestingly, most of the pins for the 168 were already broken out on the DA15 connector on each controller. The only thing needed was to build a programmer to dump the Arduino bootloader onto these little widgets.

After much trial and error (and building a new programming interface), [Scott] now has 100 Arduinos with a single stepper motor controller built in. He’s already made a toy light cycle rotate on a small stepper (after the break) and blink a LED, but with this many widgets, we’re wondering what crazy contraption [Scott] will come up with.

I’ve just sent a new set of boards for fab.  The HexMotor rev2.3 boards have several new features: LEDs for +5v and +6.25v, a reset button, 16-bit shift register instead of 8-bit, servo outputs connected to pins 13, 7, 2, 9, 10 (rather than to the pins used for PWM).  The new board should be able to do either 6 PWM motors or 4 PWM motors, 5 servos, and 2 non-modulated reversible motors.

I’m also making some breakout boards for the MPXHZ6250A pressure sensors from Freescale Semiconductor, which will require doing some SMD soldering.  At least the design uses gull-wing pins, which can (supposedly) be hand soldered.  One of the breakout boards also has a place for mounting an ADXL335 accelerometer, which may be more difficult to solder.  I don’t think I want to spend the money for a hot-air rework station, and I’m a bit dubious about my ability to solder using a toaster oven.

The pressure sensors are tiny!  My original suggestion to the robotics club was to drill a hole in the dry box and superglue the pressure sensor to the inside of the box (after the pressure sensor had been attached to the breakout board, of course).  Now I’m not so sure that there will be enough glue area to hold firmly enough.  Perhaps a dab of some sealant on the outside of the box might help, if we can keep from plugging the hole in the sensor.

The breakout board that I think that the robotics club will end up using puts a pressure sensor on one side and headers for a piggyback ADXL335 breakout board on the back.  that way there only need to be one set of wires for connecting the analog inputs and power to the sensors.

One limitation of the Arduino for use with this combination of sensors is that the accelerometer is a 3v part and the pressure sensor is a 5v part. We’ll have to set up the analog-to-digital converter on the Arduino to have a 5v range, which reduces the precision of the acceleration readings.

I’ve also bought some other sensors (not for the underwater vehicle, but for physics class and dry robotics): a couple of ultrasonic rangefinders.  More on those in a separate post, after I’ve had a chance to play with them.

Top view of the HexMotor rev 1.3 board fully populated.

I got the board fully populated yesterday, plus I made a heat sink out of a piece of ¼” × ¾” aluminum bar stock.  The heat sink makes an enormous difference.  Before using it, running a small motor at low power for 20–30 seconds was enough to make the H-bridge uncomfortably hot.  Now running the same 12v motor stalled at full current (3A) for a full minute raises the temperature only to 100ºF.

The motor got warmer than that, and I think I burned it out, since it no longer runs and has a 400kΩ resistance.  I’m not really surprised—it was a cheap door-lock actuator, and only intended to be used with fraction of a second pulses.  Further testing will require a more robust motor.

As you can see from the photo, the screw terminal for motor 4 (second from the bottom) is a bit crooked—I’ll have to unsolder it and straighten it.  For the HexMotor 2 board, I’ll use slightly smaller holes so alignment is easier.

The thermal grease I used (Cooler Master IceFusion High Performance Thermal Compound 40G RG-ICF-CWR2-GP) was more liquid than I expected, especially since it comes with a little spatula for applying it.  I had to put on a fairly thick layer, because the aluminum extrusion was not very smooth, and when I tightened the bolts the stuff oozed out making a sticky mess. Next time, I’ll sand the aluminum smooth first and use much less thermal grease.

Closeup, showing the excess thermal grease puddling under the H-bridges, where it is very difficult to wipe off.

This closeup photo, in addition to showing the pooled excess thermal grease, shows the header pins with shorting jumpers to configure the H-bridges for either lock antiphase or sign-magnitude control.  (Because of the last-minute change from TLE-5205 to TLE-5206 chips, the silk-screen labeling of the header pins is wrong—this board is actually configured for sign-magnitude throughout not lock antiphase.

The photos also show that I did not leave room for the heat sink between the electrolytic capacitors.  The HexMotor 2.0 board will fix this problem also.

The HexMotor software now can handle 3 different boards: the HexMotor rev 1.3 board shown here, the Adafruit Motor Shield, and the HexMotor rev 2 board, which I am just about done fussing with the design for.  I’ve only tested with an Arduino Duemilanove board, but the software should work with an Arduino Mega as well.