A Robotics Example
While some embedded systems do just fine with a single microcontroller, there are circumstances when offloading some processing into a second processing unit, such as a second MCU, offers a lot of advantages. In this article, Jeff explores this situation in the context of a robotic system project that uses Arduino and an external motor driver.
By Jeff Bachiochi
When your tasks begin to slip, it might be time to get help. At home, when the job jar begins to overflow, it’s often time to call in a professional to fix the leak, repaint, change the oil and so forth. At work, your project might require additional help from a programmer, purchaser, designer, or other specialist. I believe a good manager is one who is able to handle any facet of the project, but can also step back and let those associates handle their areas of expertise without micromanaging.
And so it is with programming a MCU. You can write the project yourself or—with confidence in your function library—you can make calls to complete a task without having to code those library functions. You can do more by having to do less. All that said, computationally intensive routines can eat up all your computing power. This might suggest that you move up to a more capable processor, or divide and conquer the project by using multiple MCUs.
Case in Point
I have a robot wheel base that uses an Arduino and an external motor driver board. The motors required more than the typical 2 A most Arduino motor shields can provide, so I went to an external motor driver for about $20. This requires direction and speed control outputs for each of the two motors. The wheel encoders require phase A and phase B inputs for each wheel.
It wasn’t long until the basic movement routines were written. Then I added encoder routines to handle measuring wheel movements. Finally, I made routines for adding acceleration/deceleration, positional and speed cooperation between the wheels. At that point, it was becoming clear that I was going to run out of processing power and application space. And I had not yet added a single sensor!
I considered using this Arduino as a separate processor just for wheel base movement. Certainly, someone must have integrated an MCU with motor drivers. Enter the motor controller. I chose to use a Basicmicro Roboclaw 2x7A motor controller (Figure 1) . This is the smallest in a line of compatible controllers. At $70, it cost more than my motor driver. However, it incorporates the use of the wheel encoders, so it has some pretty good intelligence. It can handle two motors at 7 A of continuous current each. I like the fact that I can substitute other models should I need more current—up to 2 x 160 A!
Basicmicro’s Roboclaw motor controller  handles two motors and associated wheel encoders. This allows the user to command motor movements without needing to drive motor phases or count wheel encoder outputs. Its on-board MCU offloads the need to deal with low-level functions.
While I plan to connect this via serial to the Arduino, it can be used stand-alone with an RC receiver, or with analog inputs from potentiometers. The serial link can be “simple” TX only or “packet” TX/RX to provide feedback.
Your motor (and gearing system) can produce some maximum torque or rotational force on a wheel to overcome the load or weight of the robot. Larger loads require more torque. Motors are rated by the maximum torque they can produce. The load or resistance to move must be less than the motor torque, or the motor will not be able to move the load. This is the stalled state of the motor, and will draw maximum current, the “stall state current.” Motor drivers must be able to withstand this current, or the driver will be destroyed trying to dissipate excess heat—not to mention overheating the motor.
Starting from a standstill will most likely require this current until movement has started. High currents while starting are typical but temporary. As the speed increases, the torque required goes down, and so does the current. With the load completely removed, the motor rotates at its maximum speed, requiring minimum current. You will typically see this “no-load” rating (no-load current vs. speed) for a motor. You may also see a continuous current rating. This will be much less than the stall current, and your motor selection should be based on the ability to provide the required torque to run continuously without exceeding the continuous current rating. This is assuming you will need to run continuously.
I’ve measured the stall current of my wheel assembly and found it to be around 5 A. The no-load current is 1 A. The calculated stall torque at the wheel is about 44 foot-pounds (ft-lb) of force after all the gearing. That may sound like a lot, but this robot carries three gel-cell batteries, and the batteries themselves are over 22 lbs. Besides the six motor/power connections, there are seven other control inputs. Two of these are relegated to the wheel encoders, and two are for the motor control mode. The last three are up for grabs, but have specific functions that you might need, depending on the control mode chosen. For instance, if you are using the controller for a remote control (RC) vehicle, you might want to use S3 for a flip input. This input reverses the direction controls when it detects that the vehicle has been flipped upside down, like in the Robot Wars TV show. …
Read the full article in the September 350 issue of Circuit Cellar
(Full article word count: 3231 words; Figure count: 4 Figures. plus 9 code Listings).
Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Note: We’ve made the October 2017 issue of Circuit Cellar
available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.