Copyright © 2006 Penton Media, Inc., All rights reserved.
Printing of this document is for personal use only.
Reprints

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.

Continue on Page 2

Though this project employs the accelerometer as an angle detector, the direction will also change when the g force exceeds the threshold value it’s compared against in the state machine. This creates the possibility of running into an object also changing direction.

Two “Continuous Interface Valuators” (integer values) were added to hold the values of X-axis and Y-axis accelerometer readings. Known as XAxis and YAxis, respectively, they hold the values read by the program each time through the main program loop, which in this case is every 16.5 ms (64 Hz).

These two values are preserved between each loop for display and monitor purposes. Such an approach enables the developer to use the board-monitor function of PSoC Express to view the live data while the program is executing.

As a result, accelerometer values can be seen and visually connected to the state transitions they trigger. This allows a visual method to see if the program logic is correct. The completed accelerometer logic is located in the box marked X-Y Inputs (Fig. 3, again).

MOTION CONTROL LOGIC
The final state machine in this project manages the motioncontrol logic (shown in the box marked “Motion Control Logic” of Fig. 3). The line between “MachineState” and “Direction” represents the state of “MachineState” as an input to the “Direction” state machine. Robot motion remains stopped until the “MachineState” state transitions to “Run.” The “Direction” state machine serves several purposes.

First, it serves as the brains of the motion-control system, taking inputs from the “Accelerometer” and “MachineState” state machine to determine if motion should be applied, and if so, which direction the robot should move in. The states of the “Direction” state machine are also used as inputs to the motor-control H-bridge driver circuit. We’ll look at the motor logic shortly, but the “Direction” state machine contains everything needed to determine motion control and direction. Figure 5 shows the actual “Direction” state-machine logic.

Though Figure 5 appears very busy, this state machine really isn’t difficult to understand. As shown, the “Direction” state machine contains seven states: Stopped, Forward, Backward, FwdLeft, FwdRight, BackLeft, and BackRight.

A Discrete Interface Valuator (Byte Variable) named TurnCount counts the number of loops after the YAxis value leaves the triggered threshold range. When TurnCount reaches a given value, the motion state is changed back to Forward or Reverse, depending on the original direction of travel.

“Stopped” is the default state at power-up and transitions to “Forward” after a 10-second startup timer has expired. The robot continues to go forward until one of the accelerometer values exceeds its threshold value. The lines between each state have the evaluation expressions that will cause a transition from one state to another. This can be illustrated with “StoppedTo- Forward” logic (Fig. 6).

Each state transition requires a unique name, and it’s located in the first line. In this case, the name is “StoppedtoForward,” which is also the name displayed on the connector between the “Stopped” and “Forward” states. The next item is the expression that will force the transition from one state to another. It simply evaluates the value of “MachineState” and forces the transition when “MachineState” transitions to the “Run” state.

What isn’t illustrated in Figure 6 is that acceptable expressions are displayed as the line is typed. Thus, the developer doesn’t have to remember unique naming schemes, which in this example uses transition names and underscore characters. The two lists are the “from” transitions on the left and the “to” transitions on the right. So, the program will go “from” a “Stopped” state “to” a “Forward” state.

MOTOR CONTROL
The final piece to this system puzzle implements the motor-control logic, which will simply turn on and off different portions of the H-bridge based on the current state of the “ Direction” state machine. Let’s refer back to Figure 6.

The “Direction” state machine has connectors to the four motor-control blocks: “Left_Forward,” “Right_Forward,” “Left_ Reverse,” and “Right_Reverse.” These four connectors are outputs from the state machine used as inputs to each motor control above to determine if that motor should be on or off. There are only two motors, but the speed and direction of the motors can be controlled based on the “Direction” state machine.

Each leg of the H-bridge is controlled via pulse-width modulation (PWM). Though you may be familiar with how an H-bridge works, its context in this development tool is slightly different from most other embedded environments. Let’s walk through this H-bridge control in the context of PSoC Express.

Continue on Page 3

A PWM has two parameters—frequency and duty cycle. The frequency represents the PWM oscillation rate, and the duty cycle represents how much of that time is spent in the ON state. If the required pulse width is a 50% duty cycle at a frequency of 50 Hz, each pulse would be 20 ms in length, with an ON state of 10 ms as shown in the following calculation: (1000 ms/50 Hz) = 20-ms total pulse, 20-ms pulse/2 (50% of total pulse time) = 10 ms in the ON state.

In this development environment, the ON state can be either high or low, depending on whether the chosen PSoC Express driver is a “high side” or “low side” driver. To create the PWM, a generic “HIGH side” PWM driver was used. The Frequency is set to 1000 Hz (or 1 kHz), and the available duty cycles are “OFF,” “LOW,” “MED,” and “HIGH.”

For the project, only the “HIGH” duty cycle was used, which is 100%. So with a duty cycle of 100%, we’re pulling the motor-control line to an “ON” state all of the time, which means the motor is running at full speed. Figure 7 shows the lookup-table function for the left-side front motor.

BUILDING THE PROGRAM
The next step is to build the program. An interesting element to this tool is that a complete “C” program is created, compiled, and linked without any user input. The first step in this process is to configure I/O pins (Fig. 8).

For the sake of clarity, I’ve broken the pin assignments into six groups, starting with accelerometer input pins 35 and 36 as group number 1. Group number 2 consists of accelerometer output pins that are passed along the bus for future use. These are connected to pins 41 and 42. Group 3 is a single pin that controls the MP (Motor Power) LED on pin 23.

The Group 4 pins control the right-side H-bridge on pins 20 and 22. Group 5, attached to pins 12 and 15, controls the right side H-bridge. Group 6 provides the I2C Monitor on pins 16 and 18. After the pins are assigned, a single click generates code, compiles, links, and generates the hex file, ready to download.

PROGRAMMING THE PART
After a successful build, the next step is to program the device using a five-pin interface and small programmer connected to the header. The programming task is a separate program invoked within the development environment through a shell.

Consequently, the programming interface is already set to the proper part and programming port. Once programmed, the programming interface displays the status of the program and verify functions. Any errors during programming or verify cycles are displayed.

SIMULATING AND MONITORING THE SYSTEM
At this point, all inputs that will be acted on, plus the output control logic, have been finished. If it were a manual process, a compile, download, and debug execution of the target would then occur. But because it’s not manual, the next steps in the process are either to run a simulation or run the target system and monitor the results in the development program. For this article, the in-line monitor function of the development tool was used.

A simulation can be run at any point during the development cycle. The only requirement is that all of the logic be completed, which means no evaluation box has a partial expression. By the way, this tool checks for a complete expression before letting you to continue, so you will have to either complete or abandon a partial expression before continuing.

This tool also allows a “Live System” to be monitored via the I²C port on the target system’s programming header. The monitor display is almost identical to the simulation display. The main difference is that instead of entering “what-if” values, the displayed values are actually coming from the embedded system while it’s running. It’s also possible to chart and record variables while the system is running, for later playback or import into Excel.

CONCLUSION
Though opinions vary when it comes to visual embedded design tools, using this type of product with a mixed-signal processor offers many advantages. On the positive side, it allows focus to remain on the design of the solution, instead of the distraction of debugging simple coding errors.

On the negative side, the developer does incur a long learning curve that offsets any time saved on initially developed projects. Also, development is limited to supported components in the driver catalog, and performance is less than real time.

But in the end, the benefits outweigh the drawbacks when learning this type of design tool. Developing appliance panels, output displays, keyboards, and data collection from sensors are quick and easy to implement. The ability to monitor live data when the target is executing brings this type of tool almost up to par with source-level debugging. I say almost because of the initial learning curve.

Like it or not, this is the next generation of development tool. In time, it will become the new way of developing embedded systems. With mixed-signal capabilities and clock speeds many times what they were five or 10 years ago, in addition to larger on-board flash, many of the constraints facing tool and compiler vendors have vanished.