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

www.it-ebooks.info

Part IV: Robotics Hardware

Industrial robots are not covered in this book, and it does not teach you how to build a robot starting from spare parts. It is definitely not suitable for designing and programming robots that might be used for handling hazardous materials or that operate in medical environments, especially if the application is life-critical. You should consider the robots in this book to be educational toys or research tools.

Safety Considerations Before Starting

Before you get started, be aware that working with real robots can be dangerous. There are many different safety issues, but the most important ones are as follows:

Your work environment: This is the most important. Make sure that it is well lit and properly ventilated, and that there is plenty of clearance around the robot before you start operating it.

Keep away from pets and children: As they say in the movies, you should never work with children or animals. Toddlers and pets might be fascinated by your robot and want to play with it. Robots often have sharp corners and protrusions and can do unexpected things if you interfere with them, especially if you rip their sensors off!

Keep a safe distance: Robots sometimes move without warning. Even adults can trip over and fall down if a robot drives in front of them at the wrong moment. This could result in serious injury to both the human and the robot. Similarly, robotic arms can move quite fast and easily poke you in the eye if you are not careful. Therefore, make sure that you give your robots plenty of room to move.

Wear safety goggles: If you are building a robot, you will have a lot of small components. Apart from the obvious risk to children from swallowing them, these small items might fly off suddenly if a tool slips. You should therefore wear eye protection whenever you assemble (or disassemble) a robot. Soldering presents a similar risk from molten solder flying through the air if you flick the tip of the soldering iron, as well as the chance of burns from the hot iron.

Read the manufacturer’s instructions: Always read the manufacturer’s instructions for a robot and follow any safety warnings. Never try to push it beyond its limits or use it for purposes for which it was not intended.

That should be enough of the doom and gloom. If you act sensibly, you should have an enjoyable and educational experience. It might even be entertaining.

Types of Robots

There are several different types of robots, but there are no universally recognized categories. Robots can be classified according to their purpose, abilities, and basic structure. Typically they are divided into categories such as mobile or stationary, autonomous or tethered, wheeled or legged, industrial versus domestic, and so on.

A common distinction is whether the robot is mobile or not. Robotic arms are usually stationary, although they can be attached to a mobile robot. Most hobby robots, however, have wheels and can run around and frighten your cat.

564

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

MRDS deals primarily with mobile robots — specifically, robots with two independently driven wheels, which are referred to as Differential Drive robots. Steering a differential drive robot is very simple because there are only two wheels. A vehicle with tracks or treads is much harder to steer because it relies on the tracks slipping in order to turn. A car (with four wheels) has what is called Ackermann steering and relies on turning only the front wheels, while the back wheels just follow along behind. A car, therefore, cannot turn on the spot, whereas a differential drive can.

One type of robot that is becoming popular is the humanoid robot. These robots are designed to look and operate similarly to a human. In other words, they have two legs (and usually arms and a head). However, they are a subset of the general category of legged robots, which include dogs (with 4 legs) or even spider-like robots (with 6 or 8 legs). One of the main areas of development for legged robots is walking gaits. As humans, we take it for granted that we can walk around on two feet, but teaching a robot to do the same and not fall over is quite difficult.

Although the Kondo KHR-1 Humanoid robot is one of the supported platforms in MRDS V1.5, it is only one of many different humanoid robots on the market. The walking abilities of these various robots vary dramatically. Many of them cannot get up when they fall over.

Articulated robotic arms use servo motors to move the joints and in some ways are similar to legged robots. No robotic arms are supported in MRDS V1.5, but Chapter 15 shows you how to use a Lynx 6 robotic arm using modified services from Lynxmotion.

Neither humanoid robots nor robots using Ackermann steering are covered in this book. The CoroBot simulation in Chapter 6 has four wheels but uses what is called skid steering.

Tethered Robots

Many robots have to be directly connected to a PC via a tether or umbilical cable. These robots are controlled by the PC and have little or no onboard intelligence. You do not download a program to the robot in this case because all of the control is performed on the PC. Robotics Tutorial 6 refers to these as remotely connected robots.

You might also hear the term teleoperation in relation to robots that use a tether. This means that a human remotely operates the robot. Using the Dashboard in MRDS or the Drive-by-Wire sample in Robotics Tutorial 4 are examples of teleoperation. In this case, the service on the PC does not perform any of the control logic — it is all left to the human operator.

Note that the tether does not have to be a physical connection between the PC and the robot. A wide variety of wireless solutions are available, such as Bluetooth, WiFi, and ZigBee. It could also be infrared, similar to a TV remote control or even a radio modem.

Note that most of the robots supported by MRDS are remotely controlled by a PC running MRDS services. When people first come across MRDS, they want to know how to use it to write programs to download into a robot. This is the way that the LEGO Mindstorms software works. For example, you can use the Mindstorms software to write code in a GUI environment that is similar to VPL and then download the code into the LEGO NXT brick for execution. The BASIC Stamp Editor is the equivalent software for the Boe-Bot, although you have to write programs in PBASIC.

565

www.it-ebooks.info

Part IV: Robotics Hardware

At the risk of being repetitive, MRDS does not work this way. It cannot generate code for loading into an ARM processor, a BASIC Stamp, or a PIC microcontroller. Instead, you (or the vendor) need to write a simple monitor program to run inside the robot. (The term “monitor” reflects the fact that it is not a full operating system but instead a small run-time environment with very basic functionality.) Then you write a service under MRDS that communicates with this monitor program to send commands to the actuators and receive input from the sensors.

Figure 13-1 shows this arrangement diagrammatically. Notice that the monitor program has direct access to the sensors and actuators, but the MRDS service does not. It must send and receive information via the Comms Link, which can become a bottleneck. Moreover, if the Comms Link is unreliable, or the connection keeps breaking, then the robot might become uncontrollable.

Figure 13-1

The Monitor Program

In Robotics Tutorial 6, the monitor program is referred to as an Onboard Remote Communication Interface. Microsoft has written the monitor programs for you (if necessary) for the supported robots, or the robots themselves already have appropriate onboard firmware:

LEGO NXT: When you first make a connection using MRDS, it automatically downloads and runs the necessary monitor program. Chapter 14 has examples for the NXT.

Boe-Bot: You have to load the monitor program (supplied by Parallax) into the BASIC Stamp yourself. The Boe-Bot is used in the examples in Chapter 14 and also discussed below.

The Lynx 6 robotic arm: This includes a small board called the SSC-32, which can control up to 32 servos. The firmware is already loaded into the onboard microcontroller when you get it. Chapter 15 covers the L6 arm.

Stinger: The Stinger robots have a Serializer board that controls all of the I/O and accepts commands via a serial port. This robot is discussed in Chapter 16.

Hemisson: These robots already have firmware on them that can be used to control the robot, as demonstrated in Chapter 17.

566

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

For the purposes of illustration, a simple monitor program is developed in Chapter 17 for the Integrator robot.

The monitor program must be written so that it is very responsive to requests from the MRDS service. If the monitor does a lot of “busy waits” as a way to introduce timing delays (in other words, it runs in tight loops doing nothing), then it might not be able to keep up with requests from MRDS.

Boe-Bot Monitor

As an example, consider the Boe-Bot monitor program. The BASIC Stamp used in the Boe-Bot is single-threaded. To generate the appropriate signals for the servo motors that drive the wheels, it has to output pulses of the correct duration and repeat them at a rate that is close to 50 Hz. The protocol that has been defined for the Boe-Bot, therefore, requires the PC to continuously send a command until it is acknowledged by the robot because the robot is mostly busy sending pulses to the motors. (A full explanation of the Boe-Bot protocol is available in the documentation on the Parallax website.)

The following code is the main loop in the Boe-Bot monitor program, which is called BoeBotControlFormsrs.bs2 and is included in the software available from Parallax. The code is written in PBASIC, the native language of the BASIC Stamp, but it is quite easy to understand.

If you have installed the Parallax software, then you can double-click the filename in Windows Explorer and the BASIC Stamp Editor, shown in Figure 13-2, should start up, because there is a file association with the bs2 file type.

Figure 13-2

567

www.it-ebooks.info

Part IV: Robotics Hardware

You must scroll down through the code to find the Main Routine, shown here:

‘ -----[ Main Routine ]-------------------------------------------------------

DO

The main loop checks whether the Bluetooth adapter has disconnected, and if so it jumps to Reset. Then it issues timed pulses on the two motor control pins 13 and 12 using the PULSOUT command. The variables tLeft and tRight are the durations of the pulses and can be changed by sending a Set_Servo_Speed command to the robot. In between pulsing, the code reads from the serial port with a timeout using the SERIN command. If this command times out, it jumps back to the label Resume at the top of the loop. However, if it succeeds, the program pulses the motors once more and then continues.

Note that the Boe-Bot uses continuous rotation servo motors. The pulse width durations range from 650 (1.3ms), which is full-speed clockwise, to 850 (1.7ms), which is full-speed counterclockwise. A value of 750 (1.5ms) results in the servo staying still. (If no pulses are received, the servo also stops.)

This requirement to continuously send pulses is a significant limitation of the BASIC Stamp. In contrast, many of the PIC microcontrollers on the market can generate PWM (pulse width modulation) signals automatically — all you have to do is load the relevant registers with the timing parameters.

The following section of code checks for a restart command from the PC. If this isn’t found, then it determines which of the various command codes was received from the PC by using the LOOKDOWN statement, and then executes a computed GOSUB to call the corresponding subroutine. The names of the subroutines are self-explanatory:

GOTO Request_Connect

ENDIF

LOOKDOWN buffer2,[32, 33, 64, 65, 96, 97, 98,

128, 129, 130,

160, 161, 162], routine

ON routine GOSUB Set_Servo_Speed, Maneuver,

Get_Ir, Get_Whiskers,

Speaker_Tone, Set_Pins, Delay,

568

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

Enable_Digital_Sensors, Enable_Ir, Enable_Whiskers,

Disable_Digital_Sensors, Disable_Ir, Disable_Whiskers.

‘Load digital sensor values into buffer byte 3 for return message. IF flagDigSens = 1 THEN GOSUB Digital_Sensors

‘Increment message index for reply. Next message from PC has to use

‘reply’s buf[1].

msgIndex = msgIndex + 1 buffer1 = msgIndex

SEROUT 1, 84, [STR buffer \5]

LOOP

The last part of the loop reads the digital sensors if they are enabled, and then it constructs a reply packet to be sent to the PC. This is an acknowledgment and includes a sequence number (msgIndex) so that the PC can verify that no packets have been dropped. Finally, it loops back to the top again, which immediately pulses the motors to keep them operating.

Ideally, the monitor program should use interrupts, but this is highly dependent on the hardware architecture. PIC microcontrollers and more sophisticated processors such as the ARM can handle interrupts. When an interrupt occurs as a result of an external signal, the processor saves the context (register values and processor state) and jumps to an interrupt handler. The handler does whatever is necessary and then restores the processor context so that the previously executing program can resume. This enables a primitive form of multi-tasking to be implemented. The main loop does not need to poll continuously for characters arriving on the serial port, for example, because the interrupt handler can assemble packets so that they only have to be processed once a complete packet is received.

There are two fundamentally different ways to handle sensor data: Either the monitor can periodically send updates or the MRDS service can poll the robot whenever it needs data. There are arguments both for and against each of these options, so it becomes the developer’s decision.

In the preceding Boe-Bot code, you can see that the values of the digital sensors, which in this case are the whiskers and the IR sensors, can be sent back to the PC as part of every command acknowledgment. This way, the PC is usually current with the latest sensor information.

Clearly, it is not reasonable for the MRDS service running on the host computer to expect to obtain sensor values instantaneously. There is some transmission delay while a request is sent to the robot, and then the monitor has to read the sensor value(s) and send back the data. Depending on the type of connection and the speed of the CPU in the robot, this can take a few milliseconds or even tenths of a second. This means that there is an upper limit on the number of times per second that you can expect to get updates to sensor data. Stale data is a common problem in robotics.

Boe-Bot Evasive Behavior

Another issue to be aware of is that controlling the movements of a robot precisely from a remotely connected PC is difficult due to the delays involved in transmitting commands and getting feedback on what the robot is doing. Therefore, the Boe-Bot has some pre-programmed behaviors that are designed specifically to get it out of trouble if it encounters an obstacle, e.g., a whisker is depressed.

The following code implements these evasive behaviors by using timed loops to move certain distances. The PAUSE command makes the program wait for a specified number of milliseconds. Notice

569

www.it-ebooks.info

Part IV: Robotics Hardware

that the delay is 20 ms, which means that the loops execute at 50 Hz. The first loop causes the Boe-Bot to move backward. The rest of the CASE statements handle the different turn directions:

‘-----[ Subroutine - Maneuver ]----------------------------------------------

‘Preprogrammed maneuver example. Current setup allows:

‘“U” - Back up then U-turn

‘“R” - Back up then right turn

‘“L” - Back up then left turn

Maneuver:

FOR temp = 0 TO 35

PULSOUT 13, 650

PULSOUT 12, 850

PAUSE 20

NEXT

SELECT buffer3

CASE “U”

FOR temp = 0 TO 40

PULSOUT 13, 650

PULSOUT 12, 650

PAUSE 20

NEXT

CASE “R”

FOR temp = 0 TO 20

PULSOUT 13, 850

PULSOUT 12, 850

PAUSE 20

NEXT

CASE “L”

FOR temp = 0 TO 20

PULSOUT 13, 650

PULSOUT 12, 650

PAUSE 20

NEXT

ENDSELECT

RETURN

One of the side-effects of these tight loops is that the Boe-Bot does not read from the serial port while they are being executed. This means that it is effectively “deaf” for the duration of a behavior. This is obviously not desirable, but at the same time it does make it much easier to program simple wandering behaviors.

The Communications Link

The Comms Link between the PC (MRDS service) and the robot (monitor program) is an important factor in the overall performance of the system. This can be a serial connection in the case of a tethered robot with an umbilical cable, or a wireless connection. Common types of wireless (radio) connections include IEEE 802.11b or 802.11g (also called WiFi), Bluetooth, or ZigBee. Even with a wireless connection, the usual approach is to simulate a serial (COM port) connection.

570

www.it-ebooks.info

Chapter 13: Using MRDS with Robotics Hardware

The LEGO NXT brick has built-in Bluetooth. For the Boe-Bot it is available as an optional extra circuit board that plugs into the robot. The Scribbler robot has a serial port into which you can plug a Serial-to- Bluetooth device (called a dongle). See Chapters 16 and 17 for examples using a Sena dongle.

In fact, any robot with a serial port can quickly and easily be converted to wireless operation. The software on the robot doesn’t even need to know that Bluetooth is involved because the Bluetooth device establishes a virtual serial port connection.

Most PCs these days, especially laptops and PDAs, have built-in Bluetooth. Even if your PC does not have Bluetooth, there are many USB-to-Bluetooth dongles on the market and all PCs now have USB ports. The range of Bluetooth is quite good, and certainly adequate for experimenting with robots. For example, a LEGO NXT Tribot can be controlled up to 30 meters away using a laptop.

Setting up a Bluetooth connection, however, can be full of trials and tribulations. With the large number of different manufacturers making Bluetooth hardware, incompatibilities are possible. Look for advice on the Internet about which brands of Bluetooth devices are known to work with your robot before buying a device and wasting a lot of time trying to get it to work. Unfortunately, in some cases you just have to “suck it and see.”

The quality of Bluetooth devices on the market varies considerably. Many people have had problems getting particular brands of Bluetooth devices to talk to each other. This shouldn’t happen if the devices conform to the Bluetooth specification, but it does. Several different brands of Bluetooth devices are used in this book and are therefore known to work.

If you purchase a Surveyor SRV-1, one of your options is ZigBee. ZigBee radio is a fairly new technology. It is similar to Bluetooth in a lot of ways, but not compatible with Bluetooth. Usually you install the drivers on your PC, plug in a USB-to-ZigBee device, and you are ready to start talking to the robot. You might need to select a channel, but for this you must read the instructions that came with the robot.

ZigBee is designed to support more nodes than Bluetooth (a maximum of eight nodes), and ZigBee can even be used in mesh networks. The ZigBee standard is set by a consortium, but it is basically the same as IEEE 802.15.4. It can operate in three different frequency bands, but it commonly uses the 2.4 GHz band, like Bluetooth, and has a similar range. Because it offers fewer functions (called profiles in Bluetooth), the ZigBee stack is much simpler than Bluetooth. The intended purpose of ZigBee is for low- data-rate, low-power applications such as devices that are always on. Bluetooth has a slightly better data rate, but it is still slow compared to WiFi. The main point in favor of Bluetooth over ZigBee is that it is available in so many devices these days, such as laptops and PDAs.

To set up a WiFi link, you must either use a so-called ad-hoc or peer-to-peer connection with fixed IP addresses or you need a Wireless Access Point to operate in that is called infrastructure mode. A Wireless Access Point (WAP) can issue addresses via DHCP. However, if the robot gets different addresses each time it is turned on, this makes communicating with it more complicated. It is far preferable to hard-code the IP address on the robot.

571

www.it-ebooks.info

Part IV: Robotics Hardware

If you are trying to operate in a corporate environment, you might run into quite restrictive policies regarding connecting to the building’s wireless network and you might not be allowed to hard-code an address. Access might be limited to known MAC addresses, or you might be required to install special software that establishes a VPN (virtual private network) in order to use encryption to ensure security. You might find it easier to buy your own wireless access point, although the “network police” might find you because you might interfere with the corporate network. Of course, if you are working at home, then you will need to set up your own wireless network anyway.

If you have a robot with an onboard PC, the setup is similar to your desktop or laptop. However, for the embedded WiFi cards used on some robots, you have to follow the manufacturer’s instructions and it simply might not be possible to configure the robot to work with a corporate network. A discussion about how to set up wireless networks, and advice on the wide range of scenarios, is outside the scope of this book.

Autonomous Robots

The most important distinction for this book is whether a robot is autonomous or not. An autonomous robot has an onboard computer capable of running Microsoft Robotics Developer Studio. The computer might be running Windows CE, Embedded XP, or even Vista. Typical hardware ranges from SBCs (single-board computers) to PDAs (personal digital assistants) and laptops.

SBCs come in a variety of formats. One of the earliest was PC104, an industry standard specification for a small embedded PC. However, manufacturers such as VIA Technologies have developed their own formats for small computers, including nano-ITX and pico-ITX. The pico-ITX boards are less than 10 cm square (about 4 inches) and have low power requirements, but they are still full x86-based PCs.

Programming under Windows CE requires additional skills beyond simply programming under Windows XP or Vista. The CE environment only supports a subset of .NET called the Compact Framework (CF). In addition, you have to transfer your programs from your development machine to the target PC on the robot. See Chapter 16 for more information.

Even though the PC is located directly on the robot, it still needs an interface board to control the actuators and read from the sensors. This controller board might contain a PIC microcontroller and have its own communications protocol. Therefore, a monitor program might still be required.

The Sumo robots used in a competition sponsored by Microsoft at the MEDC conference in 2007 were autonomous robots. They were based on the iRobot Create with an eBox-2300 PC mounted on top and a Logitech webcam. The onboard PC talks directly to the robot using a serial port.

The ICOP eBox is available in a Jump Start Kit that runs Windows CE. See www.icoptech.com/ products_detail.asp?ProductID=272. This same PC is used on the Stinger CE robot discussed in Chapter 16.

It is possible to monitor the operations of an autonomous robot remotely, or even to give it supervisory instructions. In this case, the onboard computer directly controls the robot, but higher-level strategies are implemented in a separate computer. Communication is usually via WiFi, which has become quite popular due to its low cost and good range. A WiFi card can be purchased as an optional extra for the eBox-2300.

572