Задани на лабораторные работы. ПРК / Professional Microsoft Robotics Developer Studio

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

Sound and Voice Synthesis

MRDS includes support to play WAV files. However, this only works on devices (such as PCs) that can handle WAV files and have an audio system capable of playing different frequencies of sound. Even

if your robot does not have audio capability, you might still want to use sounds in your program to alert the user. Remember that the program is likely to be running on a PC that is remotely controlling the robot.

One unusual form of actuator is the Microsoft Text to Speech service. This can be used to add a voice to your robot, but the output plays on the PC controlling the robot, not the robot itself (unless it has an onboard PC).

Controllers

As mentioned previously, PID controllers are very popular for process control. These controllers have a set point, i.e., a desired value of the system output, and the objective is to hold that value as closely as possible. The controller calculates the difference between the desired value and the current value of the output (which is the error), and adjusts the input accordingly. In the case of a motor, the objective might be to run at a constant speed, so the set point is the specified speed (which can be changed as necessary).

Understanding a Closed-Loop Control System

Figure 13-14 shows a simplified closed-loop control system where the controller is not onboard the actual robot. The controller can issue commands to the robot and it receives sensor information. On the basis of this feedback, the controller calculates an updated value for the output and the loop continues in this fashion. Eventually the error should reach zero and the output will remain steady.

Figure 13-14

In Figure 13-14, the output to the actuator could be a power setting for a drive motor. The sensor in this case would be a wheel encoder, which measures rotations of the wheel. Wheel encoders are usually rated in terms of the number of “ticks” per revolution of the wheel. By counting ticks, the wheel speed can be determined.

The proportional component of the PID algorithm multiplies the error by a factor, called the proportional gain, so that the output is driven toward the desired value as quickly as possible. However, there is one problem with proportional control on its own — it often results in some residual offset from the desired value. (A discussion of the reason for this is beyond the scope of this chapter.)

593

www.it-ebooks.info

Part IV: Robotics Hardware

Integral control involves integrating the error over time. Again there is a multiplying factor for the gain. (In process control, this factor is often expressed as a time constant, but this is not important here.) Integration can easily be performed by keeping a running sum of the errors each time through the control loop. Note that the error can be positive or negative. One effect of integral control is to cause the output to oscillate around the set point until the error is eventually reduced to zero.

To try to make the output settle quickly, differential control multiplies the derivative of the error by a gain factor (also sometimes expressed as a time constant). The objective is to have a damping effect. Calculating the derivative of a signal is easy if the sensor updates arrive at a regular time intervals — you simply subtract the previous value from the new value and divide by the time interval. It is not even necessary to divide by the time interval if it is constant because it can simply be lumped into the differential gain factor.

To avoid being overly sensitive, most controllers have a small dead zone — an acceptable threshold for the error below which no changes are made to the signal sent to the actuator. Without a dead zone, an actuator tends to jitter or hunt around the correct value.

Even though the diagram in Figure 13-14 shows the PID controller separate from the robot, in practice this is not a good idea. If the communication between the controller and the robot is over a slow connection, there is a delay in obtaining the feedback from the sensor. This delay has a destabilizing effect on the control loop. If it is too long, it causes oscillations, which might increase in magnitude and eventually be catastrophic. This is a classic problem in control theory when the system being controlled has inherent delays. It is quite obvious that if the feedback signal is sufficiently out of phase with the controller output, then the calculated value of the error will be wrong.

Fast feedback is also important for fundamental operations such as DriveDistance and RotateDegrees that are defined for the DifferentialDrive service. These operations enable the robot to be moved precisely. For this reason, they might be implemented onboard the robot, rather than remotely.

Behavior-Based Control

PID control is applicable if you are trying to control an analog quantity. However, some control schemes are based on digital inputs, so they use Boolean logic. For example, the Boe-Bot has two IR sensors and two “whiskers.” Both of these are the equivalent of contact sensors, even though the IR sensor triggers without physical contact. The logic for avoiding obstacles is therefore very simple.

If you want to see how this is implemented on the Boe-Bot, go to the MRDS directory in Windows Explorer and navigate to samples\platforms\Parallax and open BASICStamp2.sln. Once Visual Studio has started, open BoeBotControl.cs from the Solution Explorer. Locate the ExecuteMain routine. (You can select it from the drop-down list of class members.) Inside this routine you should find code similar to the following.

The first part of the code checks the whiskers (wLeft and wRight) to determine whether they have been triggered. Depending on which combination of whiskers has been depressed, the robot is sent a

594

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

pre-defined command to execute backup, turn left, or turn right behavior. (The monitor program running on the Boe-Bot understands these commands and executes the necessary moves.)

if (_autonomousMode)

{

if (wFlag)

{

if (wLeft && wRight)

{

Maneuver(‘U’);

}

else if (!wLeft && wRight)

{

Maneuver(‘L’);

}

else if (wLeft && !wRight)

{

Maneuver(‘R’);

}

}

The next section of code checks the IR sensors (irLeft and irRight) to determine whether either of them has registered an obstacle. The logic is basically the same as for the whiskers, except that if no IR sensors have been triggered, then the robot moves forward, which causes it to keep wandering around. If a sensor is triggered, then the robot turns in an arc rather than turning on the spot as it does when a whisker is triggered:

if (irFlag)

{

if (irLeft && irRight)

{

autonDir = AutonomousDirection.BKWD;

}

else if (!irLeft && irRight)

{

autonDir = AutonomousDirection.LEFT;

}

else if (irLeft && !irRight)

{

autonDir = AutonomousDirection.RIGHT;

}

else

{

autonDir = AutonomousDirection.FWD;

}

595

www.it-ebooks.info

Part IV: Robotics Hardware

The last part of the code sets the speed of the motors. (In this implementation, 0 means full-speed clockwise, 200 is full-speed counterclockwise, and 100 is stopped. These values are interpreted by code running on the Boe-Bot, as covered earlier in this chapter. Note that the motors are mounted with their shafts facing in opposite directions, so you have to rotate them in opposite directions to drive in a straight line.)

switch (autonDir)

{

case AutonomousDirection.FWD:

{

pwmLeft = 200; pwmRight = 0;

} break;

case AutonomousDirection.LEFT:

{

pwmLeft = 0; pwmRight = 0;

} break;

case AutonomousDirection.RIGHT:

{

pwmLeft = 200; pwmRight = 200;

} break;

case AutonomousDirection.BKWD:

{

pwmLeft = 0; pwmRight = 200;

} break;

}

SendSpeed(pwmLeft, pwmRight);

}

}

This type of control can be described in words, or behaviors, rather than mathematical equations (like a PID controller) — for example, “if you see an obstacle on the left, veer to the right.” The exact definition of “veer” is up to the programmer, and choosing different values will make the robot behave differently. For example, if the programmer were paranoid and interpreted “veer” to mean “turn around and run away” then you would have a very shy robot.

Obviously, the variety of possible controllers is very large. A significant part of the effort in programming a robot is creating the control strategies and algorithms to make it perform the desired tasks, and then testing this code. Quite often, unexpected “emergent behaviors” appear when you combine a variety of different algorithms.

596

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

Summary

This chapter covered some of the basics of robotics hardware and outlined some of the robots that are available on the market and supported by MRDS. Depending on your finances, choose a robot or two, or perhaps you have been given a robot to work with. In any case, you should find that it falls into one of the categories listed in this chapter. Support under MRDS might be provided by Microsoft or the hardware vendor.

It is important to understand that Microsoft Robotics Developer Studio is a framework or platform for running robots. Microsoft makes the analogy between the Windows operating system for a PC and MRDS for a robot. In the same way that Windows requires each brand of PC to implement the standard BIOS calls for low-level hardware access, MRDS needs some low-level drivers. Microsoft does not intend to support every robot on the market — that will be left to the manufacturers of the different robots. If the robot is not supported, you need to write the services yourself. This is not a trivial task and it is not advisable for a novice roboticist to embark on this path.

The next few chapters demonstrate how to use several real robots, culminating in the development of new services for a robot.

597

www.it-ebooks.info

Part IV: Robotics Hardware

the robot, you need to rely on the sensor readings, or install a camera that can provide a video feed in real time. Small wireless cameras are available that can easily be attached to a robot and run off a 9V battery. They come with a wireless receiver with a composite video output, and might even provide audio. A Swann MicroCam is shown in Figure 14-1. Smaller “spy” cameras are also available from other manufacturers.

Figure 14-1

MRDS supports webcams, and the enhanced Dashboard can display the video from a webcam so you don’t have to write any code. All you need to do is buy a suitable camera and a video capture device that is compatible with DirectX. There are many USB video capture devices available on the market. Attach the camera to your robot, plug the capture device to the wireless receiver, and you have a live video feed that you can use to drive your robot when it is out of sight.

Setting Up Your Robot

The first step is obviously to build your robot! The instructions provided with each of the robots are quite clear. The time required to build the robot depends on your past experience, but it would be wise to allow at least a day to build it and get it working with MRDS.

Remote control requires a communications link. For both the LEGO NXT and the Parallax Boe-Bot, this link is provided via a virtual serial port over Bluetooth. The instructions for setting up Bluetooth are basically the same in both cases. You should read the LEGO NXT section even if you have a Boe-Bot because the Boe-Bot section is abbreviated.

Note that the examples in this chapter assume that you have set up the software for this book, available from the website (www.wrox.com and www.proMRDS.com). The files are copied into a folder called ProMRDS under your MRDS installation. These files are necessary to complete the examples in this chapter.

600

www.it-ebooks.info

Chapter 14: Remotely Controlling a Mobile Robot

Using a LEGO NXT Tribot with MRDS

The LEGO NXT Tribot can be built straight out of the box with a LEGO Mindstorms NXT kit using the instructions supplied with the kit. It has a two-wheel differential drive and a third castor, or jockey wheel, for balance. It should only take about an hour to build the robot.

If you have read the section on simulation, then you will already have seen the Tribot in the simulator. The simulated version has only a touch sensor at the front. However, the NXT kit comes with a range of sensors, and you can build onto the Tribot to create much more complex robots, as shown in Figure 14-2, which shows a Tribot loaded with sensors.

Figure 14-2

The NXT “brick” is a large block with an LCD display and buttons that contains an ARM processor and runs its own operating system. (Microsoft uses the term brick to refer to the central intelligence onboard any robot.) It takes six AA batteries, for a total of 9V. Fully loaded with sensors, it will chew through these batteries in a couple of hours. However, do not use rechargeable batteries because they only provide 1.2V (not 1.5V) even when fully charged.

The brick can accept up to four sensors that plug into the bottom and three motors that plug into the top. The black cables are clearly visible in Figure 14-2.

601

www.it-ebooks.info

Part IV: Robotics Hardware

The robot in Figure 14-2 has an ultrasonic sonar sensor in the front that is used to detect obstacles. (It looks like two eyes and is often used as part of a face in LEGO designs.) A touch sensor pokes out from underneath the ultrasonic sensor and is a last resort in case the ultrasonic sensor fails to see an obstacle.

On top of the robot, mounted on a stalk, is a HiTechnic Compass sensor. It should be well away from the motors and brick to avoid magnetic interference. It works indoors but is a little slow to respond, so it is a good idea to turn slowly or stop and wait after a turn before using the compass direction.

Support for the LEGO NXT was included in the original version of MRDS because of the popularity of LEGO. MRDS is not directly supported by LEGO because they sell their own Mindstorms software, which is effectively a competitor to VPL.

LEGO NXT Services Version 2

In October 2007, Microsoft released an update to the LEGO NXT services referred to as V2. These services are much more sophisticated than the older services, although the emphasis in the new release was on using VPL. They support the HiTechnic and MindSensors sensors and make more use of the wheel encoders.

To use the V2 services, you must make sure that your LEGO NXT brick has firmware version 1.05. You can download and install this using the LEGO Mindstorms software if necessary. The V2 services are significantly different from V1.5 in the way that they operate. This chapter covers using both the old and the new services.

Throughout this chapter you will see references to LEGO NXT services and LEGO NXT V2 services. You need to be careful to use the correct versions because they are incompatible with each other.

Establishing a Bluetooth Connection

Create a Bluetooth connection between your PC and the LEGO NXT Tribot so that you can control the robot. This is a one-time task — once you have set it up you will not need to do it again. This process is called pairing and it involves establishing the necessary security credentials — in this case a passkey — so that the Bluetooth device can talk to your PC.

You first need to install your Bluetooth device on your PC according to the manufacturer’s instructions. If Bluetooth was built into the PC when you bought it, this has probably been done for you. However, if you do not have Bluetooth, then you need to buy a suitable device. LEGO sells a USB-to-Bluetooth device (commonly called a dongle), but many other devices are available.

Note that Windows XP and Vista come with Bluetooth drivers from Microsoft, although problems have been reported in the past using these drivers. If your hardware came with a CD, install the software from the CD and don’t rely on the Microsoft drivers. In some cases this might result in two Bluetooth items in

602