Servo - March 2008

RobotBASIC ID Command Code

rLocate 3 rForward 6

7

rTurn 12

13

rLook 48

49

rRange 192

193

rCompass 24 rBeacon 96 rPen 129 rSpeed 36 rGPS 66

Function Second

Byte

Initialize Zero

Move forward Amount to move Move backward Amount to move Turn right Degrees to turn Turn left Degrees to turn Camera (color detect) Right angle (degrees) Camera (color detect) Left angle (degrees) Ultrasonic ranger Right angle (degrees) Ultrasonic ranger Left angle (degrees) Compass Zero

Beacon detect Zero

Pen up/down Zero/non-zero Speed control Speed factor

GPS coordinates Zero

TABLE 1. These commands send a request for action to the target robot.

two bytes to the target robot. The first of these two bytes is an ID code to identify the command and the second byte is a parameter that is needed for some commands (the second byte will be zero if not needed). For example, the command rForward 10 will cause the byte 06 to be sent followed by 10, where 06 is the code for the forwarding command and 10 is the parameter representing the distance to forward. Table 1 shows details of the data sent by RobotBASIC for each

ADVANCED USERS

Although we designed the RobotBASIC protocol to be easy to use, we wanted to keep the system very flexible. It is possible to use our existing commands in totally different ways. The rSense( ) function, for example, is used on the simulator to read data from the line sensors. If you were building a firefighting robot that did not need line sensors but did need a heat sensor, you could program your real robot to send back HEAT data instead of LINE data when rSense( ) is used. Furthermore, if you use a red circle in the simulated environment to represent a fire, then even the simulated robot could use rSense( ) to locate and react to the fire.

In order to add even more flexibility, the standard internal serial commands support the wireless communication mode so that you can create subroutines to handle any sensor that might come along in the future or even create your own personal protocol, if you wish.

of the supported statements.

When the robot receives the two-byte command from the PC, its hardware-level control program must execute that command and then send back exactly five bytes to the PC. Except in the case of the GPS command, the first three of these bytes are the data from the robot’s bumper sensors, infrared perimeter sensors, and line sensors (or zero if some of these sensors do not exist in the robot).

A robot typically needs to react quickly to the data from these three sensors, which is why the protocol requires it to be returned after each command. The received information is stored in a buffer within RobotBASIC and is provided to the application program whenever it uses the functions rBumper(), rFeel(), or rSense().

The last two bytes (of the five bytes returned to the PC) are data that may be required, depending on the command. For example, rRange() expects some form of ranging sensor (sonar, infrared, etc.) to be read and the value of its reading to be returned in these last two bytes. The last two bytes represent a 16-bit integer where the most significant byte is to be received first and the least significant byte second. Data for other sensors — such as the compass or the camera — are also returned in these last two bytes. The actual devices used by the robot are immaterial because the details of the hardware are totally transparent to the language.

Obviously, the actual hardware-level control program will be unique for

any given robot, based on its capabilities and configuration. Nevertheless, we will show a typical shell program that illustrates the principles involved. Once you understand this code, you can write a program catered to your robot’s motors and sensors in a language appropriate for the microcontroller of your choice.

It can take significant effort to prepare a custom hardware-level control program for your robot, but remember, once this is finished, it never has to be done again (unless you add new sensors or change the design of your physical robot). Hopefully, in the near future, robot kits will be available that respond to the Robot BASIC protocol right out of the box.

Since all of the intelligence and problem-solving decisions reside in the RobotBASIC program, you have the power to create far more intelligent robots than could ever be done with a microcontroller-based machine. With RobotBASIC, you have a virtually unlimited space for both fixed and floating-point variables and arrays. You have modern control structures and powerful mathematical functions always available. You can debug all your code using a simulation and then use it on a real robot without translating code or downloading software. RobotBASIC provides all this and more, creating a near perfect environment for developing robot control programs. We believe this is the future of hobby robotics.

The Hardware-Level Control Program

The PBASIC program for the BASIC Stamp® 2 from Parallax ( www.Par allax.com) is an example of an appropriate hardware-level control program. The program is too long to print here but you can access it from the SERVO website ( www.servomagazine.com). Most of the routines in the shell program are not needed for this example, so only a debug statement has been inserted to indicate where the code to carry out necessary actions should be placed.