[Design View / Design Solution]
Mixed-Signal Processors Can Aid Visual Robotic Development
State-of-the-art tools make motion control and development a more abstract process.
A recent project for one of the exhibitors at the RoboDevelopment Conference and Expo 2007, held last October in San Jose, Calif., required our company to quickly develop a motion-control system for a tracked robot.
This isn’t complicated by any means, using many development tools currently available. In this case, though, the design was implemented using a visual design tool that required no manual coding at all. The goal was simple, and only three features had to be implemented:
Control of the H-bridge drivers to control forward, backward, left, and right motion
Control of the motor LED to visually indicate the current state of the system
Use of the accelerometer inputs to control direction and speed
I received one of the tracked robots with a sample application pre-installed. This program used a timer to change direction every three seconds. Since the unit has a twoaxis accelerometer, one of the inputs would be used to change the forward and reverse direction, while the other input would be used to control left and right. Forward and backward motion changes occur instantly while turning continues until the elevated track is lowered below the threshold elevation setting.
The tracked robot is used primarily for educational and hobby purposes (Fig. 1). It is controlled using a standard H-bridge driver, with a programmable system-on-a-chip (PSoC) mixed-signal processor comprising the brains of the unit. For this project, we went with the Cypress PSoC Express visual design studio due to its quickness, and the driver catalog supported all of the needed features. We then penciled out a quick design (Fig. 2).
Once the power switch is turned on, the unit goes through a 10-second initialization state. During that time, the motor LED flashes once per second. The user has 10 seconds to put the robot on a suitable surface before the motors start forward motion (unless the front is tilted higher than about 40 degrees). During initialization time, other startup tasks can also be completed without interfering with the startup cycle.
After the 10 seconds pass, a transition to the operational (yellow) state is indicated when the motors start going forward at full speed (except as noted above). When the X axis on the accelerometer goes above the value of 350 or below the value of –350, the forward and reverse direction changes. The Y axis, which is used for turning, triggers a turn when the value goes above 135 or below –135. The turn continues until the Y axis goes below 135 or above –135. If the motion prior to the turn was forward, the unit will go in reverse after coming out of the turn and vice versa if the direction prior to the turn was backward.
IMPLEMENTATION The project comprises two state machines—one for startup and another for motion. A single-shot timer starts when power is applied, runs for 10 seconds, and stops. Figure 3 shows the main design desktop.
Let’s begin with the “Startup State.” The “Startup” object is a “Discrete Interface Valuator” (or variable) that’s set to ON when power is applied. The “StartupDelay” component is a “Single Shot Delay” (or One Shot Timer) that triggers upon power-up. While “Startup” is ON and “StartupDelay” has not Elapsed, the “State” of “MachineState” remains at “Startup” as shown in state machine detail (Fig. 4).
When the “StartupDelay” expires, it will change to “Elapsed.” In turn, “MachineState” will transition from “Startup” state to “Run” state. While in “Startup” state, the Motor Power LED blinks once per second as a visual indicator. The “Startup” variable is available.
Thus, a “Startup” condition can be set by toggling the “Startup” variable and re-triggering the “StartupDelay” timer. The “Startup” variable can also prevent a “Startup” condition from re-triggering by simply turning “Startup” OFF after the initial “StartupDelay” elapses. This simple state machine offers considerable flexibility and control that can be implemented later.
ACCELEROMETER INPUTS The robot control board has a two-axis accelerometer that’s supported by a native PSoC Express driver. This simplifies the use of accelerometer inputs and opens up all types of possibilities for future expansion. And since PSoC Express has existing drivers for the accelerometer used, only the accelerometer pins need to be assigned to the PSoC to process the current accelerometer values.
In this case, the accelerometer inputs are provided as analog voltages and converted internal to the PSoC to a 16-bit signed integer value for each axis. Therefore, any value between –2000 and 2000 can be compared to determine the current accelerometer angle or g-force translation.
Reprints
