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

www.it-ebooks.info

Chapter 16: Autonomous Robots

Figure 16-16

Now that you have configured the connection, you should not need to do it again in the future, provided that the IP address of your eBox does not change. However, you will need to run CoreCon on the eBox every time you want to connect. Note also that you must connect within three minutes or the CoreCon client will time out.

Transferring Files to the eBox

You have several options for transferring files to and from the eBox. The easiest method is using a flash drive. The eBox has two USB ports on the front into which you can plug USB flash drives. When you plug in a flash drive it appears as a top-level folder in File Explorer called USB Storage. There is also a CompactFlash slot. (This is referred to as a CF slot but should not be confused with Compact Framework). A good investment might be a CF card and a universal USB flash card reader for your desktop. This will enable you to transfer large amounts of data.

The CF card slot in the eBox does not support hot swap, so if you want to use a CF card you should insert it before turning the power on. Then it appears as a folder called Hard Disk in the File Explorer. Hot swap is supported for USB flash drives, however.

An alternative method is via the Ethernet. You can set up the Visual Studio Remote Tools so that you can use them to access the eBox while you are developing your code. (When the Stinger is roaming free, you will not usually have a network connection unless you buy and install the optional WiFi card for the eBox).

Assuming that you have set up Visual Studio and established a connection to the eBox as in the previous section, you can click Target Remote Tools File Viewer. A File Viewer window will appears, similar to the one shown in Figure 16-17.

Figure 16-17 shows the file structure after the Stinger Drive-By-Wire service has been deployed to the eBox, which is apparent from the \Program Files\MRDS\bin folder. Also visible is the \Hard Disk folder, which is a CF card, and the \Windows\.NET CF 2.0 folder, which shows that the .NET Compact Framework is installed. You can copy files to or from the eBox using the arrow buttons in the toolbar.

Avoid the temptation to rush off and copy the entire contents of the bin\CF folder from your desktop installation of MRDS to the bin folder on your eBox. This might seem like a good idea in principle, but the next time you start DssHost on the eBox it will rebuild the service directory cache, which takes about 20 minutes on an eBox!

723

www.it-ebooks.info

Part IV: Robotics Hardware

Figure 16-17

It is advisable to only transfer the services that you need to your eBox. When you build a DssDeploy package, DssDeploy analyzes the dependencies between services and only includes the ones you need.

Building a Windows CE System Image

If you want to make changes to the Windows CE configuration, you have to build a new system image. This can be done using Platform Builder, which is a plug-in for Visual Studio. However, the eBox already has an OS image on it, so there should be no need to replace this unless you want different device driver support.

It is outside the scope of this book to explain in detail how to create a new Windows CE system image. Instructions are included in the Jump Start Kit. However, a few brief instructions are given below just to give you some idea of what is involved.

The basic procedure is as follows:

724

www.it-ebooks.info

Chapter 16: Autonomous Robots

such as Media Player, WordPad, Internet Explorer, etc. You must select the .NET Compact Framework 2.0 to support MRDS.

4. When you have completed the wizard, the operating system image will be built. Assuming that you called your OS Design project eBox2300, then the system image will be located in the following folder:

C:\WINCE600\OSDesigns\eBox2300\eBox2300\RelDir\

ICOP_eBox2300_60B_x86_Release.

This can take quite a long time. The resulting file, NK.BIN, is around 20MB in size.

Note that you can build either Debug or Release versions. The Debug version is intended for debugging device drivers and it expects to make a KITL (Kernel Independent Transport Layer) connection when it starts up. It can take an extremely long time before it gives up on this connection, so make sure that you build a Release version.

As shown earlier, you can edit the CONFIG.SYS and AUTOEXEC.BAT files to load any system image that you wish. You need to copy the new system image to the root directory on the eBox and then make the necessary changes. Be careful not to overwrite the existing NK.BIN because you might need this as a fallback in case your new OS image does not boot!

MS-DOS Filenames

When you edit or replace files on the eBox that are involved in booting, you must only use filenames in the old MS-DOS 8.3 format with uppercase letters. This is necessary because MS-DOS does not understand the new filename formats introduced in Windows 95 to support long names and mixed case.

If you make even such a minor change as renaming AUTOEXEC.BAT to Autoexec.bat, your eBox will not boot properly! In this case, you can use Clean Boot to go to MS-DOS and then rename the file. If you run a DIR command you will see a file called AUTOEX~1.BAT, which is the 8.3 version of the name containing lowercase characters. Rename this to AUTOEXEC.BAT and then reboot.

Likewise, be careful creating new system images because the filenames must also be in 8.3 format. For example, NKnew.bin will not work! Use NKNEW.BIN.

You can re-open your OS design again in Platform Builder at any time, change some of the options, and rebuild the OS image.

Running a Service on WinCE

Up to this point you have set up your eBox so that it can boot up, and it is configured to talk to your Stinger. Now it is time to try out your code, and even let the Stinger wander about on its own.

If you have followed through the chapter so far then you have already tested the code on your desktop and a PDA. That means you already have the necessary DssDeploy package for use on the eBox-2300

725

www.it-ebooks.info

Part IV: Robotics Hardware

because it is the same package you used on the PDA. If you didn’t read through the previous section “Creating a PDA Version of the Service,” you need to go back and read it now because there is a significant overlap.

Setting Up the Service

To begin, connect up a monitor, keyboard, mouse, and Ethernet to your eBox. (You can do this even if the eBox is attached to your Stinger.) Then follow these steps:

Files on the embedded hard drive are not volatile, but each time you reboot the eBox it expands the system image and overwrites any files already on the hard drive that have the same names as files in the image. This means you can actually add files to the Windows directory and they will stay there. However, if you change an existing file, it will be overwritten the next time you reboot.

3. Similar to the instructions for the PDA, copy all of the manifest and config files from promrds\ config to the bin folder.

4. Edit the StingerCF.Serializer.config.xml file. You can use WordPad for this. (Alternatively, you can edit it on your development PC and then transfer it over to the eBox.) You need to change the ComPort to 1.

If you want to test the service while the eBox is mounted on the Stinger and attached to a monitor and keyboard, you must also edit StingerCFDriveByWire.config

.xml and set MotorEnable to false. This enables you to run the service while you have the monitor and keyboard plugged into the eBox without worrying about the Stinger trying to run away!

An alternative is to put the Stinger up on blocks so that the wheels cannot touch the ground. Assuming that you disabled the motors, later you can set MotorEnable back to true. While the motors are disabled, messages are displayed on the console in the following format:

Dummy Motors: xx, yy

These messages show you what motor power would have been set and therefore give you an indication of what is happening.

Conversely, if you have something like the Parani SD100, then you can use Bluetooth and it isn’t necessary to disable the motors because the eBox doesn’t have to be attached to the Stinger for testing. You can leave the eBox on your desk and drive the Stinger wirelessly.

5. In the ProMRDS\CF folder is a batch file called RunStinger.cmd. Copy this into the root directory on the eBox. (You can put a copy in the bin folder as well if you want to.) It contains the following command (on one line):

726

www.it-ebooks.info

Chapter 16: Autonomous Robots

“\Program Files\MRDS\bin\cf.DssHost.exe” /p:50000 /t:50001 /m:StingerCFDriveByWire.manifest.xml

6. You can either execute this batch file or manually open a Command Prompt window, change directory to \Program Files\MRDS\bin, and then execute cf.dsshost.exe yourself.

Testing Operation of the Service

If you have set everything up properly, you will see messages from DssHost and eventually the GUI will appear. You can drive the robot around using the arrow keys on the keyboard or the buttons on the Form, or click the Wander checkbox to let it “wander” by itself, as shown in Figure 16-18.

Figure 16-18

In Figure 16-18, the Wander checkbox is ticked. In this mode the service displays the current Wander mode — in this case, Veer Right — as the robot moves around. The IR readings are also updated dynamically. These readings will change if you by place your hand in front of one or more of the sensors. This enables you to test various combinations of IR readings to ensure that the Wander mode is updated correctly.

Notice in Figure 16-18 the small window titled Microsoft.Ccr.Adapters.WinForms

.HiddenFormxxxxx. This is the Windows Forms Adapter. When you click Exit, the code sends a Shutdown message to the Windows Forms Adapter and this window disappears, along with the GUI.

727

www.it-ebooks.info

Part IV: Robotics Hardware

However, the DSS node might not shut down. If so, close the Command Prompt window and it will take

DssHost with it.

Autonomous Operation

When you run the robot on its own, there is no need for the Windows Form. In fact, the robot does not have a monitor when it is running autonomously so there is no point in displaying a Form. However, there is one more task to perform before you let the Stinger run free — you need to set up an auto-start command because you will not have a keyboard or monitor to initiate the service.

To make the robot run autonomously, follow these steps:

79#”\Program Files\MRDS\bin\MsrsAutoStart.exe” \Windows\cmd.exe /c \RunStinger.cmd

4. If you right-click the shortcut in File Explorer and select Properties, there is a tab in the Properties dialog labeled Shortcut. You can easily edit the command there. However, be aware that there is a limit to the length of the command (somewhere around 110 characters). This is why the shortcut executes the batch file RunStinger.cmd instead of the full cf.dsshost.exe command.

Look carefully at the command. It executes MsrsAutoStart.exe, which in turn executes the following command:

\Windows\cmd.exe /c \RunStinger.cmd

Notice that you must specify full paths for everything and that the batch file must be located in the root directory. The /c qualifier for cmd.exe means create a new command prompt.

This is a somewhat complicated procedure, but you can test it out easily — just reboot your eBox. Don’t select anything from the boot menu. It will time out and automatically select the default option. After a short delay Windows CE will boot and then the MsrsAutoStart dialog will appear (see Figure 16-19). You can cancel execution at this stage, although you should leave it to run to ensure that it works.

728

www.it-ebooks.info

Chapter 16: Autonomous Robots

Figure 16-19

When MsrsAutoStart has finished counting down, a Command Prompt window should appear and DssHost will start. Because you have enabled wandering and disabled the GUI, the robot should spontaneously start to display Dummy Motor messages on the screen. If it does not do this after it beeps, then wave your hand in front of each of the IR sensors to make sure that they register. Then it should start.

When you have reached this point, it is now time to let your creation run loose:

As the robot wanders around, you can “shepherd” it with your hands or feet by putting them in front of the sensors. If you have a test environment with walls, i.e., a “playpen,” then the robot should just wander around avoiding the walls. When you eventually get tired of playing with the robot, you have to catch it and turn it off.

Where to Go from Here

Rather than just being the end of the chapter, this is really the beginning of a new adventure. There are many, many changes that you can make to the services in this chapter to add more features, make them more robust, and so on. Here are a few suggestions:

You might want to make changes to the Wander behavior in the Stinger Drive-By-Wire service. It is not a very smart behavior. You can also fiddle with the parameters to see whether you can improve it.

729

www.it-ebooks.info

Part IV: Robotics Hardware

The Stinger CE has a Line Following kit that mounts under the front bumper. You might want to try your hand at writing a service that follows lines on the ground. The Stinger Drive-By-Wire service should be a good starting point.

You might also like to consider using a webcam for wandering. However, be warned that webcam support under WinCE is severely limited. About the only camera that will work is the Logitech Pro 5000 (and it must be exactly that model). In addition, the frame rate is not very good — you will only get about 3 or 4 frames per second even at low resolution.

Whenever you rebuild the service, you can run the batch file BuildStingerCFPackage.cmd to create a new DssDeploy package. If you do this, remember that you might have edited the config files on the eBox so you should transfer them back to your desktop PC and place them in the ProMRDS\Config folder. This ensures that the updated files are included in the DssDeploy package and you don’t accidentally revert them to the original versions.

You should regularly visit the RoboticsConnection website to see what new software they might have to offer. From time to time they might also run competitions.

Summary

After completing this chapter successfully you now have experience in developing MRDS services for mobile devices. Because it is quite a complex area, it is possible that you had a few little hiccups along the way. Unfortunately, it is more than possible, it is quite likely. As usual, Google is your friend. If you get stuck on a particular problem, use Google or search the MRDS Discussion Forums.

Now that you have a robot that is capable of exploring on its own, you can start to design more complex algorithms and behaviors. The Stinger has wheel encoders to help you measure distances, but these were not used in this chapter. It also has a PID (proportional-integral-derivative) mode of operation for the motors that is far more accurate than the PWM method used in this chapter.

The last chapter shows you how to write new services for devices that are not yet supported by MRDS. This might be your chance for a claim to fame.

730

www.it-ebooks.info

Part IV: Robotics Hardware

If you buy a small robot kit or one that is already built, there will most likely be some software available for it. Many of the hobby and educational robots on the market have active discussion forums, and the source code for software that runs on the robot is readily available. This should assist you if you need to write a monitor program.

The majority of small hobby and educational robots use what is called a PIC (programmable interface controller) or MCU (microcontroller unit) as the processor in their brick. A PIC is a complete system-on- a-chip (SOC) that includes CPU, clock, memory (volatile RAM for data and nonvolatile Flash ROM for programs), and I/O (digital, analog, or both). They have evolved from 8-bit to 16-bit and now 32-bit chips and come in a large variety of sizes — from as small as eight pins in a dual inline package (DIP) to surface mount chips with over 100 pins.

There is an active market for microcontroller chips on circuit boards for embedded systems, especially for use as robot controllers. The circuit board also needs an H-bridge or some power transistors to control motors or servos due to the high current requirements. If you are not familiar with hardware and you are thinking about building your own robot, this is an important point that you should understand: The outputs from a microcontroller cannot drive motors directly.

Microcontroller chips typically include RISC CPUs, which have small instruction sets. In a recent innovation, Parallax introduced the Propeller chip, which has eight CPUs, called cogs. This allows for parallel processing, or true multi-tasking, on a single chip. These chips are programmed in a language called Spin. The Spin Stamp is a direct replacement for the BASIC Stamp 2 in the Boe-Bot. Parallax provides Spin code that is a direct replacement for the PBASIC monitor program, but it does not use all of the cogs. Therefore, if you are adventurous, you can install a Propeller chip in your Boe-Bot and rewrite the monitor program to take full advantage of all eight cogs.

Note that there is a trend toward more powerful onboard processors, rather than PICs. For example, the Gumstix boards (www.gumstix.com) have Intel XScale processors and run Linux. Versions are available with built-in Bluetooth. Ethernet and USB connections are also available. To work with a robot, a plug-in board called the Robostix provides the necessary hardware interfaces. This is another whole market segment, however, and Linux-based robots are not covered here. Instead, we target PIC-based robots.

For the sake of completeness, it is worth mentioning another possible brick, the Sun SPOT (www.sunspotworld.com) from Sun Microsystems. Sun SPOTs have a 180 mHz ARM processor, built-in ZigBee radio, a USB interface, and run a Java Virtual Machine. They are intended for use in embedded systems. The key point about Linux or Java-based bricks is that, as the programmer, you have to write the monitor program to run on the brick. This topic is also beyond the scope of this book, but if you are a top-gun Java programmer, you might like to write a monitor program for a Sun SPOT and then create MRDS services for it. If you do, be sure to publicize it on the MRDS Discussion Forum.

With this background in mind, the following sections outline several options for your brick’s processor.

Microcontrollers

Microchip Technology (www.microchip.com) named their highly successful series of chips using the “PIC” prefix. The Hemisson robot, for example, uses a PIC16F877 chip. Although the Microchip name has become synonymous with microcontrollers, they are not the only manufacturer. Atmel (www.atmel.com)

732