Graduation Project: Roverbot - Thesis

Customized Mobile Robot System

Chapter 1: Introduction Mobile Robots are a class of unmanned ground vehicles that can be controlled by a human operator from a distance over some form of a communication link. Such robots have plethora of applications ranging from inspection and maintenance in industry to surveillance and reconnaissance in law enforcement. In all aforementioned cases, these vehicles provide access to places that are unsafe or impossible for humans to reach. The need for such robots is varied and specific, so fulfilling them means custom building systems or buying and customizing existing systems which are both expensive options. The main aspect of our project is software for controlling a robot over a wireless network and retrieving video and other streaming data like GPS over the same network. The objective of this project is to create and test a prototype of a software framework for control and communication of mobile robots which can be adapted to work with various robotic vehicles and network infrastructures. After successful demonstration of this project, it is possible to customize the software to the client’s needs at a low cost. The software framework is modular to enable flexibility in which independent modules like the communications module and control module can be modified without affecting each other. Such flexibility allows the system to address the needs of a larger range of clients. For example, the software functions independent of the network infrastructure provided that it is IP enabled. The software also allows the integration of other sensors and hardware such as compass, gyroscope, and sonar depending on the client’s needs. The achieved system may be used in different fields such as military applications, mineral & submarine, searching for unexploded objects. The ministry of defense, research institutions, and any party that has an existing hardware platform but needs some form of customization in software.

1

Customized Mobile Robot System

Figure 1 (Description of the project) This Figure shows the description of our project which used in the robot End windows CE 6.0 platform builder operating system and the hard ware is ebox 4300 and there are peripherals like iRobot, GPS and Webcam. On The other hand the control computer used Linux operating System and the hardware is Personal computer and controlled the robot by joystick.

Figure 2 (Description of the project in details)

2

Customized Mobile Robot System

In this figure we explain in detail what happen inside the system .Since each hardware part has special API to make it work in the ebox. On the other hand, in the PC has the graphical user interface to show what the robot do and to link between them we used communication library with TCP/UDP protocol.

 Project Description Software Requirements OS

Windows CE compatible Hardware Requirements

Supported interfaces

Serial, USB, Ethernet

Communication Specifications Network layer

IP

Transport Layer

TCP/UDP Transmitted Data Specifications

Minimum video frame quality

256*192 pixels

Minimum video frame rate

10 fames/s

Control Specification Minimum remote controllability

Forward, backward and rotational velocity

Table 1.1 – Initial specification for the project The table above shows the initial specifications for the project. Real time video, sensor feedback, and real time control of vehicle mobility which are vital features necessary to make mobile robots feasible were all achieved. Any delay between video capture on the robot and the time when it is displayed, is unnoticeable. There is a small delay present from

3

Customized Mobile Robot System

when the user issues a command to move and when the robot responds, this was not a problem due to the relatively slow speed of the robot. Since the on time delivery of a packet within a maximum delay is not a service provided by an IP network, we have no control over the transport delay. However, during the demonstration, this delay was in no way an issue. As far as minimizing the delay involved in encoding, decoding, and processing returned data, this too was achieved. This was allowed by the fact that any necessary processing, like interpreting raw data from sensors was done at the more powerful computer at the control interface and not the embedded computer on the robot. Furthermore, the quality of the data sent back including video frames, GPS and sensors, were close to, when not the maximum allowed by the sensor. More specifically, the frames were of better resolution at 320*240 pixels, than originally specified. Although the original specification of 10 frames per second wasn’t met in the demonstration, the demonstrated 5 frames per second was sufficient to safely control the robot and furthermore, the frame rate can be increased with a minor change in the video streaming software. Similarly the sample rates for the sensor and GPS receiver are also 5 per second and are sufficient and can still be changed with minor changes in the software. The embedded computer that used (e-Box) provided sufficient processing power and memory and so processing speed and memory requirements was satisfied. Furthermore, the resources available on the computer would allow the current set of applications to be supplemented with more servers for more sensors and peripherals. Finally, the design enables scalability as described in section of the proposal. Scalability is providing support for the integration of new software and hardware into the system. Because the server for each sensor is a separate application, addition of more sensors and software to handle them and act as their server should be possible without any significant effect on other parts of the system. Furthermore, the flexibility of the code, enabled by its modularity was also demonstrated when the same communication library and library for controlling the robot was used with minimum modifications, on a different project involving the same robot and a completely different hardware platform 4

Customized Mobile Robot System

and software environment (Linux running on gumstix.) And as already stated, provided that TCP is supported by the software environment and type of network can be used in lower layers. Overall, with the exceptions noted, all the specifications for the software were satisfied. The test platform for testing the software framework was also built. The original specifications for it are shown in the table below. Embedded computer specifications Interfaces

Rs232 serial, USB,802.11a/b/g

Communication

Network with multiple or large coverage 802.11 wireless access point

Peripherals Webcam

Must provide at least 10 frames per second that are 256*192 pixels

GPS

Must support a serial or USB interface

Mobility Requirements Degrees of freedom

Forward , backward and rotation

Table 1.2 – Initial specification for the test platform

Presented in the table below are the actual hardware specifications for the test platform.

5

Customized Mobile Robot System

Table 1.3 – Hardware specification

The proposed software framework consists mainly of two applications, the application at the robot end and the one at the control interface end. The architectures of the processes that make up the application are described in later sections. These applications will in turn use the services provided by the operating system. For our test platform, the software at the robot end will run on an embedded computer board called the eBox, and the one at the control interface will run on a regular Linux box.

 Motivation A wide range of readymade robot applications are available in the market for predefined tasks. However, none of the available robot-based products can be adapted according to the actual client’s needs. For example, it is not possible to modify the task of the robot and/or integrate any additional peripherals such as sensor or GPS modules to the robot; also it can only work in a fixed environment according to its design. The targeted customers of our project are such clients that require the service of customizing their software framework based on 6

Customized Mobile Robot System

their needs. We are now able to provide this service because of the modular and layered nature of our systems and protocols that we have successfully demonstrated in our project. The main contribution of this project is the synergy and integration between simple software and hardware modules to perform complex and tedious tasks. The market segment of the proposed solution is larger due to its flexibility and modularity. Henceforth, greater sales with lower marketing costs are expected.

 Thesis Contributions The project has demonstrated a set of basic principles to enable rapid development of robotic systems: scalability, abstraction, real-time, and modularity. Scalability means providing support for the integration of new software and hardware into the system. Scalability, therefore, allows older designs to be modified for newer applications with reduced development time. Abstraction allows software development independent of hardware or the underlying system. This approach allows for reduced development time, as less time has to be spent on researching the underlying hardware and system. Real-time principle is the selection of an appropriate real-time operating system such as Windows CE. Such operating systems also provide many services and abstractions that will help reduce development time. Modularity allows reasonable software design that makes the software reusable. This approach helps reduce development and testing time by reducing complexity and amount of code. Furthermore, modularity also helps to reduce the code footprint of the software. The rapid development and modular design that these principles enable are vital for the proposed service.

7

Customized Mobile Robot System

Although companies like iRobot and Foster Miller robotics provide a number of platforms and a large number of versions for various applications, their designs are somewhat inflexible and are not designed to enable modification of software or hardware without significant effort. Another important factor in the design of mobile robots includes reliable and real-time communication, preferably over long distances. Research has demonstrated the viability of using long range, wireless, and packetswitching services like GPRS for applications of teleportation and telemetry. Unlike RF and fiber used by conventional TGVs like MATILDA, the use of widely deployed packet switched services like GPRS can allow the use of existing infrastructure and control over longer distances. The product features are listed below.  Software is easily adaptable for modifications  Various sensors can be implemented in the software  Communication and control of robot over a wireless network The prototype features includes the product features listed above and the features listed below.     

Video feedback from robot GPS data from robot Motion sensor data from robot Graphical User Interface on a remote station for control of robot Data displayed in the Graphical User Interface

The prototype provides control of the iRobot Create over a wireless network, and sends video images, GPS data and motion sensor data from the robot to the remote controlling computer.

8

Customized Mobile Robot System

 Thesis Outlines This thesis consists of 3 parts in 7 Chapters; the current chapter is the first one. Part 1: “The Robot End” consists of two chapters. Chapter one describes the robot hardware (eBox & iRobot). Chapter 2 illustrates the robot embedded software and description of creating an OS image by Windows CE 6.0 Platform Builder and the four processes handled by the eBox. Part 2 introduces “Computer End” software that run on the PC and the four processes handled by the PC are demonstrated at chapter 4. Part3 describes “Networking”. The wireless networks are described concretely and the Wi-Fi wireless network are described in chapter 5. A simulation for what happened in the real time is described in chapter 8. Finally the thesis is concluded in chapter 7. Then the used references are listed according to the referring order. Appendix includes the data sheets of the used component are also attached at the end of this thesis.

9

Customized Mobile Robot System

Chapter 2: Robot Hardware 2.1 Introduction The development and testing of our software framework was done on a hardware platform that the team assembled. The rationale behind the choice of hardware will be discussed later. The control interface only consists of a Linux box with generic peripherals. The robot consists of a Create robot from iRobot and an eBox embedded computer, with wireless capability. The eBox has to communicate with the Open Interface on the robot with a serial connection. Furthermore, the entire hardware platform including the eBox and the sensors has to draw power from the Create Robot. Both of these can be done using the DB25 connector in the cargo bay of the robot, which provides connection to switched power as well as the serial Open Interface. 2.2 The Robot Hardware Two problems were detected during the analysis of hardware requirements. The first problem was due to the fact that the switched power source is unregulated and is at a much higher voltage than what is required by the eBox. The second problem was due to the serial connection on the connector being TTL level rather than RS232 as required by the eBox. To get around this, the Robot E-box Hardware Interface (REHI) was designed. This consists of a PCB, some electrical components and chips that implement two circuits, one to perform efficient power regulation and the second to convert signals from TTL level to RS232 level serial. The latter simply used a MAX232 level converter. The power regulator includes a Texas Instrument PTN78 series DC/DC power module that helps maintain a stable output voltage for the eBox. The REHI also contains large filtering capacitors, for absorbing transient spikes from the power source. The eBox is connected to the REHI power output using a regular eBox power cable. Everything else is powered from the eBox.

10

Customized Mobile Robot System

The peripherals connected to the eBox include a Phidgets board and sensor, a webcam and a GPS receiver. Other than the GPS receiver and the robot, everything else is connected to the eBox over standard USB cables. The dataflow between hardware is shown in figure (2.1)

Figure 2.1 – Hardware Dataflow Top level system diagram Shown in figure (2.2) the top level system diagram. All hardware attached to the iRobot Create which is the system’s main platform that carries all parts. The REHI “Robot E-Box Hardware Interface” is the intermediate linking between the e-Box and the iRobot Create because of reasons discussed. Peripheral devices like webcam and the Phidgets board with their peripherals are connected to the e-Box through standard USB. Remote controlling computer is connected to the system through Wi-Fi networking by the included Wi-Fi card in the e-Box.

11

Customized Mobile Robot System

Figure 1.2 – Top level system diagram

Figure 2.3 – Hardware connectivity

12

Customized Mobile Robot System

Like the Create Robot, the serial interface on the GPS receiver is a TTL Serial interface and so another MAX232 chip is necessary to interface the GPS receiver and the eBox. Furthermore the GPS receiver is still powered over the USB cable. 2.3 Codes and Standards DB9 RS232 Serial ports were used to access serial devices. Because both of the devices had TTL serial interfaces, MAX232 chips had to be used to convert between the two levels. Standard USB was also used to access the Phidgets board and webcam as well as to power the GPS receiver. 2.4 Constraints, alternatives, and tradeoffs The Create robot from i-Robot was chosen because it is significantly cheaper than other similar platforms on the market and still provided the range of motion and interface for control that satisfies our need. This imposed constraints on the size of hardware that can be placed on it as well as the power consumption since that hardware would draw power from the Create’s battery. The e-Box was chosen as the embedded computer on the robot, as it best satisfied these constraints. Because there is no processor intensive operation performed at the robot, an FPGA would have been an unnecessary cost and would have consumed more power. Alternative embedded computers like the Gumstix could also have been used; however they have fewer ports available to access hardware. Finally the e-Box is more durable than either of those alternatives. An embedded computer like the e-Box has limited memory and processing power.

13

Customized Mobile Robot System

Figure 2.4 – The eBox Interface

The iRobot Create

14

Customized Mobile Robot System

Figure 2.5 – Hardware Assembly

15

Customized Mobile Robot System

Figure 2.6 – The REHI Circuit The REHI circuit is the link between the irobot and the ebox and it has two component max232 to convert between two levels (Parallel / Serial) and the power regulator (PTN 78020W).

16

Customized Mobile Robot System

Chapter 3: Robot Embedded Software 3.1 Introduction In chapter 1, we displayed the embedded robot hardware will be used in the project. This chapter displays the embedded software that runs the proposed hardware. 3.1.1 Real Time Embedded Systems with Windows CE 3.1.1.1 Introduction An embedded system is a computer device programmed to carry out specific tasks. Most of the time these systems have to handle real time operations and they use a real time operating system. The most popular real time operating system today is Windows CE. This operating system is optimized for small storage systems, such as embedded systems. This chapter focuses on the commercial applications of real time embedded systems implemented using Windows CE. It also identifies the special features of Windows CE and steps to implementing an embedded system using Windows CE. 3.1.1.2 Commercial Applications Advances in technology have made embedded systems inexpensive, and they are used in many electronic devices. One of the most common uses of embedded systems is in automation. Other uses include cellular phones, toys, cameras, planes, automobiles, mobile robots, trains, space vehicles, PDAs, home appliances and many more. Based on the device and user specifications the application and task are determined, and then developed through different hardware and software implementations. Some systems require a real-time response. For example an electric toothbrush would require a timer for pulsing and rotating the bristles. And if the brush does not respond within the required time then it could harm the user. Such time constraint systems can be implemented to

17

Customized Mobile Robot System

increase human safety in space exploration vehicles or to ensure accurate functioning in autopilot aircrafts. The uses of embedded system are endless. 3.1.1.3 Underlying Technology A high number of automation applications of robotics and machinery controls require strict timing constraints. To handle this, Microsoft invented Windows CE - a real-time embedded operating system that performs specific tasks for small memory systems. A study showed that Windows CE was capable of meeting 95% of systems realtime needs.

18

Customized Mobile Robot System

The many optimized features of CE include a unified kernel is capable of handling more than 32,000 processes with a 2GB of virtual memory space. A set of useful device drivers have been included. It is compatible with existing Win32 applications, and the architecture has reduced system overhead significantly. Visual Studio 2005 now has the Windows CE platform builder, which makes application development easy. 3.1.1.4 Development Tools  Visual Studio Late versions of Microsoft Visual Studio support projects for Windows CE / Windows Mobile, producing executable programs and platform images either as an emulator or attached by cable to an actual mobile device. A mobile device is not necessary to develop a CE program. The .NET Compact Framework supports a subset of the .NET Framework with projects in C#, and VB.NET, but not Managed C++. CodeGear Delphi Prism, which runs in Visual Studio, also supports the .NET Compact Framework and thus can be used to develop mobile applications. It employs the Oxygene compiler created by RemObjects, which targets the .NET, .NET Compact Framework and Mono. Its command-line compiler is available free of charge.  Free Pascal and Lazarus Free Pascal introduced the Windows CE port in version 2.2.0, targeting ARM and x86 architectures. Later the Windows CE header files were translated for use with Lazarus, an RAD software package based on Free Pascal. Windows CE applications are designed and coded in the Lazarus IDE and compiled with an appropriate cross compiler.  Platform Builder This programming tool is used for building the platform (BSP + Kernel), device drivers (shared source or custom made) and also the application. This is a one step environment to get the system up and running. One can also use Platform Builder to export an SDK (software development kit) for the target microprocessor (SuperH, X86, MIPS, ARM etc.) to be used with another associated tool set named below.

19

Customized Mobile Robot System

 Embedded Visual C++ The Embedded Visual C++ tool is for development of embedded application for Windows CE based devices. This tool can be used standalone using the SDK exported from Platform Builder or using the Platform Builder using the Platform Manager connectivity setup.

3.2 Windows Embedded CE 6.0 is the sixth major release of Windows Embedded Operating System targeted to enterprise specific tools such as industrial controllers and consumer electronics devices like digital cameras. Windows Embedded CE 6.0 features a completely redesigned kernel, which supports over 32,768 processes, up from 32 process support of the previous versions. Each process receives 2GB of virtual address space, up from 32MB. Windows Embedded CE 6.0 includes partial source code. Windows Embedded CE 6.0 is also the basis of Windows Mobile 7, codenamed "Photon". Features   

   

 

Some System components (such as file system, gwes, device driver manager) have been moved to the kernel space. The system components which now run in kernel have been converted from EXEs to DLLs, which get loaded into kernel space. New Virtual Memory Model. The lower 2GB is the process VM space and is private per process. The upper 2GB is the kernel VM space. New Device Driver Model that supports both User Mode and Kernel Mode Drivers. The 32 process limit has been raised to 32,768 processes. The 32 megabyte virtual memory limit has been raised to the total virtual memory (Up to 2GB of private VM is available per process). The Platform Builder IDE is integrated into Microsoft Visual Studio 2005, allowing a single development environment for both platform and application development. Read-only support for UDF 2.5 file system. Support for Microsoft's upcoming exFAT file system. 20

Customized Mobile Robot System

  

802.11i (WPA2) and 802.11e (QoS) wireless standards, and multiple radio support. CE 6.0 works with x86, ARM, SH4 and MIPS based processor architectures. New Cellcore components to enable devices to easily make data connections and initiate voice calls through cellular networks.

3.3 Building Blocks Two of the main components of an embedded system using Windows CE are device drivers and the application. Some embedded systems require the integration of other electronic devices, and Windows CE has device drivers to manage the operation of these devices. It has built-in drivers for audio, battery, keyboard, mouse, serial, PC Card, and USB drivers. Drivers for other devices such as sensors can be downloaded or implemented. An application can be easily developed in C/C++ that runs on Windows CE based device using the APIs. If the embedded system will be communicating with another PC, then a PC interface also needs to be implemented in CE. In our senior design project, we will be integrating a sonar sensor and a webcam. Drivers for these devices will have to be downloaded. And a PC interface will have to be implemented also.

21

Customized Mobile Robot System

3.4 The OS Image The windows CE OS image that would run on the e-Box, first had to be configured before building. Without going into too much detail, these are some of the configurations used in Platform Builder: • Project based on Industrial Device and Internet Appliance • ROM only file system • Hive Based Registry • ATAPI PCI Support • USB Host Support • 802.11 Wireless networking support • VNT VNWLC6 Wireless LAN (VIA) driver • Shared Source Web Cam Driver written by Douglas Boling Finally we modified the default registry to use Software FIFO with ISR for both serial ports to allow for Fast Serial Port incoming data handling. 3.5 Software Architecture at Robot End There are currently 4 independent processes that run at the robot end. One of these processes, “ControlTheRobot” handles serial communication with the robot and also acts as a server to the remote controller, while the rest of the processes each handle a different input peripheral like sonar, GPS and video and also act as the respective servers for the remote controller. The use of separate processes for independent functionalities has a number of advantages. Mainly it reduces the complexity of the overall design, exploiting Windows CE’s multiprocessing capability. Adding additional sensors or removing them is a matter of just adding or removing these independent server applications. The design of the individual processes is also modular consisting of several libraries to support different functionalities like serial communication with the robot and socket communications. “Socklib” is a library common to most of our applications and is used to implement the server and client. The main purpose of the libraries is to abstract the hardware and details of the underlying system. These libraries also provide modularity and

22

Customized Mobile Robot System

allow the software framework to be more adaptable. For example, if the robot is changed than only the library handling communication with the robot will have to be changed. Because the applications are written in C++, the design, especially that of the “ControlTheRobot” application, takes advantage of the Object Oriented nature of the language. More specifically inheritance and abstract classes are used to enable the above described adaptability. 3.5.1 Conclusion Real Time Embedded Systems are used in many electronic devices and the real-time response requirements are best met by Windows CE Operating System. Application development is made simple by CE, and its optimized features make it an ideal OS for embedded systems. Our senior design project will require a real-time embedded system that would perform the specific task of controlling a robot's sensors and movement, and Windows CE would the ideal OS for the application. This embedded system will communicate the computer end through a wireless network. 3.5.2 Classes and Libraries Used 3.5.2.1 ControlTheRobot Subproject Description The overall structure of the “ControlTheRobot” process is shown in the flow chart below. On startup, the application initializes the serial port, the robot and the server. These steps are key to the operation of this application and if any of them fail, the program has to quit. Once this stage is complete, the application enters an infinite loop where it constantly waits for a client and once connected, services the client until the connection is closed for some reason. Once connected the server waits for commands from the client and attempts to execute them. If the command is to “close”, the server closes the application and waits for the next client. If the receive fails, it may also imply that the connection is closed and the robot then waits for the next client.

23

Customized Mobile Robot System

Figure 3.1: Overall Structure for ControlTheRobot

24

Customized Mobile Robot System

Code Files Used

Code File

Description

AbstractCommandFactory.h/.cpp

These two files set the foundation for the well known design pattern: Command Factory

IRobotCommandFactory.cpp

A concrete implementation of the AbstractCommandFactory for the iCreate Robot

Buffer.cpp

Data structure to hold the incoming command message from the RemoteController

CommandExecuter.cpp

Makes use of the command factory design pattern

CommandImpl.cpp

A sample implementation of the EC_Command abstract command.

connection.cpp

Class to encapsulate the network connection

ConnectionManager.cpp

Class to handle instatiation of Connection their termination

ConnectionSocket.cpp

Light wrapper around windows SOCKET

25

Customized Mobile Robot System

Abstract command EC_Command.cpp

OpenInterface.cpp

Provides the iCreate Robot On Interface commands from a cleaner contained namespace

Excutive.cpp

Includes _tWinMain, the message loop, and the main functionality

Socklib.cpp

Networking functions

Table 3.1: List of code files used for the ControlTheRobot process ControlTheRobot - UML ControlTheRobot::BatteryCapacitySensorCmd +BatteryCapacitySensorCmd() +~BatteryCapacitySensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::BatteryChargeSensorCmd +BatteryChargeSensorCmd() +~BatteryChargeSensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::BatteryTemperatureSensorCmd +BatteryTemperatureSensorCmd() +~BatteryTemperatureSensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::Buffer -m_pBuffer : char * -m_CommandID : long -m_CommandParameters : char * -m_size : unsigned int +Buffer(in size : unsigned int, in Buffer : char*) +~Buffer() +GetCommandID() : long +GetSize() : unsigned int +CopyParamsTo(in buffer : char*) -Buffer()

26

Customized Mobile Robot System

ControlTheRobot::CAbstractCommandFactory +CAbstractCommandFactory() +~CAbstractCommandFactory() +GetCommand(in ID : CommandID) : EC_AbstractCommand * #Clear()

ControlTheRobot::CCommandExecuter -m_pCommandFactory : CAbstractCommandFactory * +CCommandExecuter(in commandFactory : CAbstractCommandFactory*) +~CCommandExecuter() +Execute(in ID : long, in paramSize : unsigned int, in parameters : char*)

ControlTheRobot::CConnection -m_Socket : SOCKET -m_Address : sockaddr_in -m_RemoteControllerSocket : SOCKET -m_RemoteControllerAddress : sockaddr_in +CConnection() +~CConnection() +InitChannel() +CloseChannel() +NextMessageBuffer() : Buffer *

ControlTheRobot::CConnectionException +CConnectionException() +CConnectionException(in msg : const char*) +setMessage(in msg : const char*)

ControlTheRobot::CConnectionManager +m_RemoteControllerIP : CIPAddress +CConnectionManager() +~CConnectionManager() +QueryControllerAddress() : CIPAddress

ControlTheRobot::CConnectionSocket -m_socket : SOCKET -m_SocketAddress : sockaddr_in -m_IPAddress : in_addr +CConnectionSocket() +~CConnectionSocket()

27

Customized Mobile Robot System

ControlTheRobot::CEyeCreateRobot -m_bInitialized : bool -m_Connection : CConnection -m_CommandFactory : CIRobotCommandFactory +CEyeCreateRobot() +~CEyeCreateRobot() +Start() : bool +Shutdown() +ExecuteAnyPendingCommand() +IsInitialized() : bool -ExecuteCommand(in ID : long) -Forward() -Backward() -TurnLeft(in angle : unsigned short) -TurnRight(in angle : unsigned short) -Stop() -CloseConnection()

ControlTheRobot::CIPAddress +CIPAddress() +~CIPAddress()

ControlTheRobot::CIRobotCommandFactory -m_CommandMap : map +GetCommand(in ID : CommandID) : EC_AbstractCommand * #Clear() +CIRobotCommandFactory() +~CIRobotCommandFactory()

ControlTheRobot::CMotionCommand +CMotionCommand() +~CMotionCommand()

ControlTheRobot::ControlCmd +ControlCmd() +~ControlCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::CoverCmd +CoverCmd() +~CoverCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::CurrentSensorCmd +CurrentSensorCmd() +~CurrentSensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

28

Customized Mobile Robot System

ControlTheRobot::DriveCmd +DriveCmd() +~DriveCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::DriveDirectCmd +DriveDirectCmd() +~DriveDirectCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::EC_AbstractCommand #m_Parameters : char * #m_ParamBufferLength : unsigned int +EC_AbstractCommand() +~EC_AbstractCommand() +Execute(in paramLength : unsigned int, in params : char*) +SetParameters(in paramLength : unsigned int, in params : char*)

ControlTheRobot::EnterFullModeCmd +EnterFullModeCmd() +~EnterFullModeCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::EnterSafeModeCmd +EnterSafeModeCmd() +~EnterSafeModeCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::LowSideDriversCmd +LowSideDriversCmd() +~LowSideDriversCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::SendIRCmd +SendIRCmd() +~SendIRCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::SensorsCmd +SensorsCmd() +~SensorsCmd() +Execute(in paramLength : unsigned int, in params : char*)

29

Customized Mobile Robot System

ControlTheRobot::StartCmd +StartCmd() +~StartCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::StopCmd +StopCmd() +~StopCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::ThreadBase #m_ThreadCtx : ThreadContext #m_pThreadFunc : LPTHREAD_START_ROUTINE +ThreadBase() +~ThreadBase() +Start(in arg : void* = 0) : DWORD +Stop(in bForceKill : bool = false) : DWORD +GetExitCode() : DWORD #EntryPoint(in pArg : LPVOID) : DWORD #Run(in arg : LPVOID) : DWORD #BeforeRun() #AfterRun() #BeforeStop() #AfterStop()

«struct»ControlTheRobot::ThreadContext +m_hThread : HANDLE +m_dwTID : DWORD +m_pUserData : LPVOID +m_pParent : LPVOID +m_dwExitCode : DWORD +ThreadContext()

30

Customized Mobile Robot System

«utility»ControlTheRobot::Utility +g_hInst : HINSTANCE +g_hWndCommandBar : HWND +theRobot : CEyeCreateRobot +gBuffer : Buffer * = NULL +hSerialPort : HANDLE +WinMain(in hInstance : HINSTANCE, in hPrevInstance : HINSTANCE, in lpCmdLine : LPWSTR, in nShowCmd : int) : int +MyRegisterClass(in hInstance : HINSTANCE, in szWindowClass : LPTSTR) : ATOM +InitInstance(in hInstance : HINSTANCE, in nCmdShow : int) : BOOL +WndProc(in hWnd : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : LRESULT +About(in hDlg : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : INT_PTR +TheTimerProc(in hwnd : HWND, in message : UINT, in idTimer : UINT_PTR, in dwTime : DWORD) +MyRegisterClass(in hInstance : HINSTANCE, in szWindowClass : LPTSTR) : ATOM +InitInstance(in hInstance : HINSTANCE, in nCmdShow : int) : BOOL +WndProc(in hWnd : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : LRESULT +About(in hDlg : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : INT_PTR +TheTimerProc(in hwnd : HWND, in message : UINT, in idTimer : UINT_PTR, in dwTime : DWORD) +Initialize() : bool +Shutdown() +StartRobot() : bool +SetBaud(in baud : BaudRate) +Control() +EnterSafeMode() +EnterFullMode() +Spot() +Cover() +Demo(in demo : DemoCode) +Drive(in velocity : unsigned short, in radius : unsigned short) +Stop() +LEDs(in whichLEDs : Byte, in color : Byte, in intensity : Byte) +PlaySong(in songNumber : Byte) +Sensors(in packetID : SensorPacketID) +CoverAndDock() +LowSideDrivers(in control : Byte) +PWM_LowSideDrivers(in lsd0dutycycle : Byte, in lsd1dutycycle : Byte, in lsd2dutycycle : Byte) +DriveDirect(in rightwheelvelocity : short, in leftwheelvelocity : short) +DigitalOutputs() +Stream() +QueryList() +PauseResumeStream() +SendIR(in value : Byte) +Script() +PlayScript() +ShowScript() +WaitTime(in time : Byte) +WaitDistance(in distance : short) +WaitAngle(in angle : short) +WaitEvent(in eventCode : EventCode) +BumpsAndWheelDropsSensor(in value : Byte &) +WallSensor(in value : Byte &) +CliffLeftSensor(in value : Byte &) +CliffRightSensor(in value : Byte &) +CliffFrontLeftSensor(in value : Byte &) +CliffFromRightSensor(in value : Byte &) +VirtualWallSensor(in value : Byte &) +LowSideDriverAndWheelOvercurrentsSensor(in value : Byte &) +InfraRedSensor(in value : Byte &) +ButtonsSensor(in value : Byte &) +DistanceSensor(in value : short &) +AngleSensor(in value : short &) +ChargingStateSensor(in state : Byte &) +VoltageSensor(in value : short &) +CurrentSensor(in value : short &) +BatteryTemperatureSensor(in value : Byte &) +BatteryChargeSensor(in value : short &) +BatteryCapacitySensor(in value : short &) +WallSignalSensor(in value : short &) +CliffLeftSignalSensor(in value : short &) +CliffFrontLeftSignalSensor(in value : short &) +CliffFrontRightSignalSensor(in value : short &) +CliffRightSignalSensor(in value : short &) +GetUserDigitalInputs(in userInput : Byte &) +GetUserAnalogInputs(in userInput : short &) +GetChargingSourcesAvailable(in sources : Byte &) +GetOIMode(in mode : Byte &) +GetSongNumber(in songNumber : Byte &) +GetSongPlaying(in playingSong : Byte &) +GetNumberOfStreamPackets(in number : Byte &) +GetRequestedVelocity(in velocity : short &) +GetRequestedRadius(in radius : short &) +GetRequestedRightVelocity(in velocity : short &) +GetRequestedLeftVelocity(in velocity : short &) +Forward(in velocity : short) +Backward(in velocity : short) +InitializeSongs() +getAddrByName(in name : char*) : in_addr +initServer(in port : int, in servSock : SOCKET*, in ServAddr : sockaddr_in*) : int +connectToServer(in pSock : SOCKET*, in port : unsigned short, in passedIPAddr : in_addr) : int +waitForClient(in servSock : SOCKET, in clntSock : SOCKET*, in ClntAddr : sockaddr_in*) : int +sendByte(in Sendable : char, in clntSock : int) : int +sendAddr(in Sendable[] : char, in clntSock : int) : int +getByte(in sock : SOCKET) : char +getAddr(in addr : in_addr*, in sock : SOCKET) : int +registerServer() : int +getRegServAddr(in servAddr : in_addr*, in blocking : char) : int +receiveBPP(in ppbuffer : char**, in sock : SOCKET) : int +transmitBPP(in size : int, in message : char*, in sock : SOCKET) : int

31

Customized Mobile Robot System

ControlTheRobot::VoltageSensorCmd +VoltageSensorCmd() +~VoltageSensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::WaitAngleCmd +WaitAngleCmd() +~WaitAngleCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::WaitDistanceCmd +WaitDistanceCmd() +~WaitDistanceCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::WaitEventCmd +WaitEventCmd() +~WaitEventCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::WaitTimeCmd +WaitTimeCmd() +~WaitTimeCmd() +Execute(in paramLength : unsigned int, in params : char*)

ControlTheRobot::WallSignalSensorCmd +WallSignalSensorCmd() +~WallSignalSensorCmd() +Execute(in paramLength : unsigned int, in params : char*)

32

Customized Mobile Robot System

3.5.2.2 eBox GPS Subproject Description As displayed in chapter 1 the proposed hardware includes a GPS receiver used to determine the longitude, latitude, and altitude for the robot. A subproject is required to be created to control over these tasks. GPS module API was used to facilitate this task in this subproject. Code Files Used eBox_GPStest.cpp

Main windows message loop initialization, Reads the GPS and sends it to the RemoteController Initialize Phidgets and instantiate the API pointers from the DLL using The usual windows include file to be precompiled

PhidgetFunctionPointers.cpp

stdafx.cpp

Table 2.2: List of code files used for the eBox_GPS process UML of eBox – GPS «utility»Utility +g_hInst : HINSTANCE +g_hWndCommandBar : HWND +WinMain(in hInstance : HINSTANCE, in hPrevInstance : HINSTANCE, in lpCmdLine : LPWSTR, in nShowCmd : int) : int +MyRegisterClass(in hInstance : HINSTANCE, in szWindowClass : LPTSTR) : ATOM +InitInstance(in hInstance : HINSTANCE, in nCmdShow : int) : BOOL +WndProc(in hWnd : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : LRESULT +About(in hDlg : HWND, in message : UINT, in wParam : WPARAM, in lParam : LPARAM) : INT_PTR

33

Customized Mobile Robot System

3.5.2.3 VideoSender

CameraCode.cpp

mjpeg2bmp.cpp

VideoSender.cpp

Make usage of the camera device driver written by Doug Boling, with one convenience function added by the team Makes a BMP from a MJPEG stream Implements tWinMain, the message loop, as well as grabbing the frame and sending it to the RemoteController

Table 2.3: List of code files used for the VideoSender process

3.5.2.4 Sensors Implements tWinMain, the message loop, and grabbing sensor data and sending it to the RemoteController Initialize Phidgets and instantiate the API pointers from the DLL using GetProcAddress() Networking functions

Sensors.cpp

PhidgetFunctionPointers.cpp Socklib.cpp

Table 2.4: List of code files used for the Sensors process

34

Customized Mobile Robot System

Chapter 4: Computer End software 4.1 Introduction This chapter displays Remote Control application that will remotely control the robot through Wi-Fi network and provides services to move robot through a joystick, receive stream of video images, receive sonar sensor data and coordinates of GPS. 4.2 Description of Control Interface The QT library was used in the development of the GUI. Unlike the multi processed nature of the framework at the robot end, this is not feasible at the control interface end, since both the video and the sensor data will have to be presented in the same GUI, which must also allow the user to give commands to control the robot. Modularity is still permitted however, by utilizing classes and encapsulation as well as independent panes on a main window. Connection to the robot is first established by entering the e-Box’s IP address into the dialog box and clicking OK. If the IP address is valid, connection is established, and data is immediately streamed back and displayed. The picture of the GUI is presented in figure The top four views display data sent back by the robot. The top left is the video sent back by the webcam at approximately 5 frames per second. The top right and center left panes display latitude/longitude and altitude data respectively. Lastly, the center right panel plots the sensor data. More detailed GPS data is presented on the bottom left and center including heading. Finally, the arrows on the bottom right allow the robot to be controlled.

35

Customized Mobile Robot System

4.3 Control Interface Class Hierarchy Other than the main window, which is the main parent class, the panels displaying the video, latitude/longitude and sensor data are child classes called view classes that inherit from the QFrame class. The view classes mentioned are in turn parent classes of thread classes. These thread classes spawn threads responsible for connecting to the correct data server at the robot end, receiving data from those servers, and passing the data up the class hierarchy to the appropriate class to be interpreted and displayed represents the hierarchical structure of the more important classes in the program.

Figure 4.1: Control Interface Class Hierarchy When the user attempts to establish a connection, a relevant method is invoked in the three View classes previously mentioned, that in turn spawn threads starting with the run function in its child thread class. After establishing connection, these threads handle the receipt of data on the opened connections. When data is received by a given thread, any necessary processing is performed (e.g. parsing the string sent back by the GPS server) and the relevant information passed up to the parent class that in turn updates its display. In the case of the “GPS View” class, data is also passed to the “Main Window” class, which in turn passes it back down to the Compass and Plot View classes to display the GPS data in more detail. Finally, the “Main Window” class also has to handle user related events like mouse clicks on the navigation buttons. When such 36

Customized Mobile Robot System

events occur, it passes the information about which button was clicked to the CreateRobot class, which in turn transmits commands to the robot. When the user clicks on disconnect command in the menu, the “Main Window” invoke the necessary methods in the view classes, which in turn raise specific flags. When these flags are raised, the threads that poll the flag close the connection to the servers and terminate. 4.4 Data Receiving Threads The run methods executed by the data receiving threads in the Control Interface have a general structure that is a complement to the structure of the data servers, discussed in shows the flow chart representing its structure. As shown in the figure, once connected, the thread receives data from the server, updates the relevant display and checks the “Stop requested” flag. If the flag is set, the connection is closed and the thread is stopped. Otherwise, it continues to try to receive more data from the server.

Figure 4.2: Flow chart of data receiving threads

37

Customized Mobile Robot System

The code and associated documentation for both the robot end servers and the Control Interface, is available on the included CD. Technical Information  RemoteController Application (ANSI C++)  Development tool: Qt SDK “Nokia Corporation”  License: GNU – Open Source 4.5 CPP Files + Respective Header Libraries CPP Files main.cpp ConnectionDialog.cpp EyeCreateRobot.cpp GPSDataThread.cpp GPSSentences.cpp gpsview.cpp ImageView.cpp MainWindow.cpp plotview.cpp SensorsView SensorsDataThread.cpp VideoFrameThread.cpp

Description Implements the required main() function, initiates the QApplication and the MainWindow objects Offers a dialog box to the user to choose a robot address from a list, or to enter an IP address Encapsulate the iCreate Robot functionality in a class The thread that handles opening the socket and waiting for GPS data Class to extract information from the NMEA phrases A QFrame derived class that displays the GPS path A QFrame derived class that displays the video feedback The top level Frame that owns all the views, menus and controls A QFrame derived class to display any raw data as a curve A specialized view to render the sensor's data The thread that handles opening the socket and waiting for the sensor data The thread that handles opening the socket and waiting for the video frame

Table 4.1: List of code files used for the RemoteController application

38

Customized Mobile Robot System

4.5.1 main.cpp Description The main.cpp Implements the required main() function, instantiate the QApplication and the MainWindow objects. Classes and Libraries Used QApplication The QApplication class manages the GUI application's control flow and main settings. QApplication contains the main event loop, where all events from the window system and other sources are processed and dispatched. It also handles the application's initialization and finalization, and provides session management. In addition, it handles most system-wide and application-wide settings. Code Block #include

QPushButton The QPushButton widget provides a command button. The push button, or command button, is perhaps the most commonly used widget in any graphical user interface. Push (click) a button to command the computer to perform some action, or to answer a question. Typical buttons are OK, Apply, Cancel, Close, Yes, No and Help. Code Block #include

39

Customized Mobile Robot System

4.5 .2 MainWindow.cpp Description The MainWindow.cpp implements the Main UI for the RemoteController Application. UML

MainWindow -m_DataUpdateTimer : QTimer * -m_ForwardTimer : QTimer * -m_BackwardTimer : QTimer * -m_RightTurnTimer : QTimer * -m_LeftTurnTimer : QTimer * -compass : QwtCompassNoMouse * -m_connectionDialog : ConnectionDialog -m_availableRobots : QStringList -theRobot : CreateRobot +MainWindow(in parent : QWidget*) +~MainWindow() +displayError(in error : int, in strError : const QString &) +on_actionOpen_Connection_triggered() +on_actionClose_Connection_triggered() +on_actionList_Robots_triggered() +on_actionExit_triggered() +on_RightButton_clicked() +on_ForwardButton_clicked() +on_LeftButton_clicked() +on_ReverseButton_clicked() +on_RightButton_pressed() +on_RightButton_released() +on_ForwardButton_pressed() +on_ForwardButton_released() +on_LeftButton_pressed() +on_LeftButton_released() +on_ReverseButton_pressed() +on_ReverseButton_released() -MoveBackward() -TurnRight() -TurnLeft() -RemindDataThreads() -StopMotion() -QueryRelayForAvailableRobots() -CreateCompassWidget()

Classes and Libraries Used QDebug 40

Customized Mobile Robot System

The QDebug class provides an output stream for debugging information. QDebug is used whenever the developer needs to write out debugging or tracing information to a device, file, string or console. Code Block #include

QTimer The QTimer class provides repetitive and single-shot timers. The QTimer class provides a high-level programming interface for timers. To use it, create a QTimer, connect its timeout() signal to the appropriate slots, and call start(). From then on it will emit thetimeout() signal at constant intervals. Code Block #include

QLayout The QLayout class is the base class of geometry managers. This is an abstract base class inherited by the concrete classes QBoxLayout, QGridLayout,QFormLayout, and QStackedLayout. Code Block #include

QWidget The QWidget class is the base class of all user interface objects. The widget is the atom of the user interface: it receives mouse, keyboard and other events from the window system, and paints a representation of itself on the screen. Every widget is rectangular, and they are sorted 41

Customized Mobile Robot System

in a Z-order. A widget is clipped by its parent and by the widgets in front of it. Code Block #include

QMainWindow The QMainWindow class provides a main application window. Code Block QMainWindow

QGirdLayout The QGridLayout class lays out widgets in a grid. QGridLayout takes the space made available to it (by its parent layout or by the parentWidget()), divides it up into rows and columns, and puts each widget it manages into the correct cell. Code Block QGridLayout

QPalette The QPalette class contains color groups for each widget state. A palette consists of three color groups: Active, Disabled, and Inactive. All widgets in Qt contain a palette and use their palette to draw themselves. This makes the user interface easily configurable and easier to keep consistent. Code Block QPalette

42

Customized Mobile Robot System

QMap The QMap class is a template class that provides a skip-list-based dictionary. Code Block QMap

QString The QString class provides a Unicode character string. QString stores a string of 16-bit QChars, where each QChar corresponds one Unicode 4.0 character. (Unicode characters with code values above 65535 are stored using surrogate pairs, i.e., two consecutive QChars.) Code Block QString

QColor The QColor class provides colors based on RGB, HSV or CMYK values. A color is normally specified in terms of RGB (red, green, and blue) components, but it is also possible to specify it in terms of HSV (hue, saturation, and value) and CMYK (cyan, magenta, yellow and black) components. In addition a color can be specified using a color name. The color name can be any of the SVG 1.0 color names. Code Block QColor

43

Customized Mobile Robot System

QDialog The QDialog class is the base class of dialog windows. Code Block QDialog

4.5.3 MainWindow.ui Description This is the Main Window GUI that provides 4 grids for each video images, GPS data, sensor data and navigation options.

44

Customized Mobile Robot System

UML

Ui_MainWindow +actionOpen_Connection : QAction * +actionClose_Connection : QAction * +actionList_Robots : QAction * +actionExit : QAction * +centralwidget : QWidget * +widget_2 : QWidget * +VideoFrame : ImageView * +GPSFrame : GPSView * +PlotFrame : PlotView * +SensorsFrame : SensorsView * +widget : QWidget * +RightButton : QPushButton * +ForwardButton : QPushButton * +LeftButton : QPushButton * +ReverseButton : QPushButton * +LongitudeEdit : QLCDNumber * +LatitudeEdit : QLCDNumber * +AltitudeEdit : QLCDNumber * +label : QLabel * +label_2 : QLabel * +label_3 : QLabel * +CompassHolder : QWidget * +label_4 : QLabel * +groupBox : QGroupBox * +NoGPSFixRB : QRadioButton * +GPSFixRB : QRadioButton * +DGPSFixRB : QRadioButton * +label_5 : QLabel * +label_6 : QLabel * +label_7 : QLabel * +GPSTimeLCD : QLCDNumber * +menubar : QMenuBar * +menuConnection : QMenu * +statusbar : QStatusBar * +setupUi(in MainWindow : QMainWindow*) +retranslateUi(in MainWindow : QMainWindow*)

45

Customized Mobile Robot System

Preview

4.5.4 ConnectionDialog.ui Description This window allows connection to robot through a given IP.

46

Customized Mobile Robot System

UML Ui_ConnectionDialog +buttonBox : QDialogButtonBox * +availableRobotsCB : QComboBox * +robotIPAddressEdit : QLineEdit * +robotsListRB : QRadioButton * +provideIPAddressRB : QRadioButton * +setupUi(in ConnectionDialog : QDialog*) +retranslateUi(in ConnectionDialog : QDialog*)

4.5.5 EyeCreateRobot.cpp Description The EyeCreateRobot.cpp encapsulates the iCreate Robot functionality in a class. UML

CreateRobot -socket : QTcpSocket -host : QString -port : quint16 -connected : bool +CreateRobot(in parent : QObject* = NULL) +~CreateRobot() +ConnectTo(in host : QString, in port : quint16) : bool +disconnect() +Forward() +Backward() +Left() +Right() +Stop() -TransmitMessage(in length : unsigned int, in message : char*)

Classes and Libraries Used QObject The QObject class is the base class of all Qt objects. Code Block

47

Customized Mobile Robot System

#include

4.5.6 plotview.ui Description PlotView Class allows adding plots for sensor and GPS data in the main window. UML Ui_PlotViewClass +setupUi(in PlotViewClass : QWidget*) +retranslateUi(in PlotViewClass : QWidget*)

4.5.7 plotview.cpp Description The plotview.cpp is a QFrame derived class to display any raw data as a curve

UML

48

Customized Mobile Robot System

PlotView -crv : QwtPlotCurve -index : int -maxData : int -minData : int -xval[120] : double -yval[120] : double -xMap : QwtScaleMap -yMap : QwtScaleMap +PlotView(in parent : QWidget* = 0) +~PlotView() +newData(in val : float) +newData(in data : char*, in size : int) +shiftDown(in rect : QRect &, in offset : int) +drawContents(in p : QPainter*) +paintEvent(in Parameter1 : QPaintEvent*)

Classes and Libraries Used QFrame The QFrame class is the base class of widgets that can have a frame. Code Block QFrame QRect The QRect class defines a rectangle in the plane using integer precision. A rectangle is normally expressed as an upper-left corner and a size. The size (width and height) of a QRect is always equivalent to the mathematical rectangle that forms the basis for its rendering. Code Block QRect

QPaintEvent The QPaintEvent class contains event parameters for paint events.

49

Customized Mobile Robot System

Paint events are sent to widgets that need to update themselves, for instance when part of a widget is exposed because a covering widget was moved. Code Block QPaintEvent

QColor The QColor class provides colors based on RGB, HSV or CMYK values. A color is normally specified in terms of RGB (red, green, and blue) components, but it is also possible to specify it in terms of HSV (hue, saturation, and value) and CMYK (cyan, magenta, yellow and black) components. In addition a color can be specified using a color name. The color name can be any of the SVG 1.0 color names. Code Block QColor

QBrush The QBrush class defines the fill pattern of shapes drawn by QPainter. A brush has a style, a color, a gradient and a texture. Code Block QBrush

QPainter The QPainter class performs low-level painting on widgets and other paint devices. Code Block

50

Customized Mobile Robot System

QPainter

QPaintEngine The QPaintEngine class provides an abstract definition of how QPainter draws to a given device on a given platform. Code Block QPaintEngine

4.5.8 VideoFrameThread.cpp Description The thread that handles opening the socket and waiting for the video frame UML

VideoFrameThread -m_parent : ImageView * -m_FrameData : char * -hostName : QString -port : quint16 -mutex : QMutex -cond : QWaitCondition -stopRequested : bool -connected : bool +VideoFrameThread(in parent : ImageView* = 0) +~VideoFrameThread() +setRobotAddress(in address : const QString &) +stop() +quitRunning() +isConnected() : bool +requestNewFrame() +run() +error(in socketError : int, in message : const QString &) +connectedToRobot()

51

Customized Mobile Robot System

Classes and Libraries Used QThread The QThread class provides platform-independent threads. Code Block #include QString The QString class provides a Unicode character string. Code Block #include

QTcpSocket The QTcpSocket class provides a TCP socket.

Code Block #include

QDataStream The QDataStream class provides serialization of binary data to a QIODevice. A data stream is a binary stream of encoded information which is 100% independent of the host computer's operating system, CPU or byte order. For example, a data stream that is written by a PC under Windows can be read by a Sun SPARC running Solaris. The QDataStream class implements the serialization of C++'s basic data types, like char, short, int, char *, etc. Serialization of more complex data is accomplished by breaking up the data into primitive units. Code Block 52

Customized Mobile Robot System

#include

QMutexLocker The QMutexLocker class is a convenience class that simplifies locking and unlocking mutexes. Code Block #include

4.5.9 ImageView.cpp Description A QFrame derived class that displays the video feedback UML

ImageView -graphicsView : QGraphicsView * -label : QLabel * -imageLabel : QLabel * -m_pixmap : QPixmap -m_Image : QImage -m_byteArray : QByteArray -n_Name : QString -m_imageFileName : QString -m_FrameData : char * -m_thread : VideoFrameThread +ImageView(in parent : QWidget* = 0) +connectTo(in address : const QString &) +disconnect() +newFrameData(in frameData : const unsigned char*, in size : int) +SocketErrorHandler(in socketError : int, in message : const QString &) +ConnectionEstablished()

Classes and Libraries Used QtGUI The QtGui module extends QtCore with GUI functionality

53

Customized Mobile Robot System

Code Block #include

QString The QString class provides a Unicode character string. Code Block #include

QWidget The QWidget class is the base class of all user interface objects. Code Block #include

QFrame The QFrame class is the base class of widgets that can have a frame. Code Block #include

QLabel The QLabel widget provides a text or image display Code Block #include

54

Customized Mobile Robot System

QPallette The QPalette class contains color groups for each widget state Code Block #include

QSizePolicy The QSizePolicy class is layouts attribute describing horizontal and vertical resizing policy. Code Block #include QGraphicsView The QGraphicsView class provides a widget for displaying the contents of a QGraphicsScene. Code Block #include

QPainter The QPainter class performs low-level painting on widgets and other paint devices. Code Block #include

QGridLayout The QGridLayout class lays out widgets in a grid Code Block #include

55

Customized Mobile Robot System

QAbstractSocket The QAbstractSocket class provides the base functionality common to all socket types. Code Block #include

QMessageBox The QMessageBox class provides a modal dialog for informing the user or for asking the user a question and receiving an answer. Code Block #include

QPixmap The QPixmap class is an off-screen image representation that can be used as a paint device. Code Block #include

4.5.10 GPSSentences.cpp Description Class to extract information from the NMEA phrases

56

Customized Mobile Robot System

UML

GPSSentence +m_sentencetext : QString +valid : bool +m_GPSPoint : GPS_Point +time : QString +validity : QString +Latitude : QString +NS : QString +Longitude : QString +EW : QString +Altitude : QString +units : QString +fixQuality : QString +numSatellites : QString +HorizontalDilutionOfPrecision : QString +speedOverGround : QString +courseMadeGood : QString +UTCDateOfFix : QString +MagneticVariation : QString +MV_EW : QString +checksum : QString +GPSSentence(in str : QString) +~GPSSentence() +setSentence(in str : const QString &) +isValid() : bool +getGPSPoint() : GPS_Point -GPSSentence() -extractInfo()

Classes and Libraries Used QStringList The QStringList class provides a list of string. Code Block #include

QString The QString class provides a Unicode character string. Code Block #include

57

Customized Mobile Robot System

4.5.11 GPSView.cpp Description A QFrame derived class that displays the GPS path UML

GPSView -graphicsView : QGraphicsView * -scene : QGraphicsScene * -label : QLabel * -zoomSlider : QSlider * -m_theGPS_Path : GPS_Path -boundingBox : QGraphicsRectItem * -m_thread : GPSDataThread -GPSInfo : GPSSentence -m_parent : MainWindow * +GPSView(in parent : QWidget* = 0) +view() : QGraphicsView * +newGPSData(in data : const char*, in size : quint32) +connectTo(in address : const QString &) +disconnect() +setParent(in parent : MainWindow*) +paintEvent(in event : QPaintEvent*) -setResetButtonEnabled() -setupMatrix() -toggleAntialiasing() -zoomIn() -zoomOut() -ConnectionEstablished() -populateScene() -clearScene()

Classes and Libraries Used QWidget The QWidget class is the base class of all user interface objects. Code Block #include

QFrame The QFrame class is the base class of widgets that can have a frame.

58

Customized Mobile Robot System

Code Block #include

QLabel The QLabel widget provides a text or image display Code Block #include

QGraphicsView The QGraphicsView class provides a widget for displaying the contents of a QGraphicsScene. QGraphicsView visualizes the contents of a QGraphicsScene in a scrollable viewport. To create a scene with geometrical items, see QGraphicsScene's documentation. QGraphicsView is part of The Graphics View Framework. Code Block #include

QPainter The QPainter class performs low-level painting on widgets and other paint devices. Code Block #include QFile The QFile class provides an interface for reading from and writing to files. Code Block 59

Customized Mobile Robot System

#include

QAbstractSocket The QAbstractSocket class provides the base functionality common to all socket types. Code Block #include

QMessageBox The QMessageBox class provides a modal dialog for informing the user or for asking the user a question and receiving an answer. Code Block #include QPixmap The QPixmap class is an off-screen image representation that can be used as a paint device. Code Block #include

4.5.12 GPSDataThread.cpp Description The thread that handles opening the socket and waiting for GPS data

60

Customized Mobile Robot System

UML

GPSDataThread -m_parent : GPSView * -hostName : QString -port : quint16 -mutex : QMutex -cond : QWaitCondition -stopRequested : bool -m_GPSData : char * -connected : bool +GPSDataThread(in parent : GPSView* = 0) +~GPSDataThread() +setRobotAddress(in address : const QString &) +stop() +isConnected() : bool +startAcquiringGPSData(in hostName : const QString &, in port : quint16) +run() +quitRunning() +wakeUpAndWork() +error(in socketError : int, in message : const QString &)

Classes and Libraries Used QtNetwork The QtNetwork module offers classes that allow you to write TCP/IP clients and servers Code Block QT += network #include

QFrame The QFrame class is the base class of widgets that can have a frame. Code Block #include

QThread The QThread class provides platform-independent threads. 61

Customized Mobile Robot System

Code Block #include

QMutexLocker The QMutexLocker class is a convenience class that simplifies locking and unlocking mutexes. Code Block #include

QTcpSocket The QTcpSocket class provides a TCP socket. QTcpSocket is a convenience subclass of QAbstractSocket that allows you to establish a TCP connection and transfer streams of data. Code Block #include

QDataStream The QDataStream class provides serialization of binary data to a QIODevice. A data stream is a binary stream of encoded information which is 100% independent of the host computer's operating system, CPU or byte order. For example, a data stream that is written by a PC under Windows can be read by a Sun SPARC running Solaris. The QDataStream class implements the serialization of C++'s basic data types, like char, short, int, char *, etc. Serialization of more complex data is accomplished by breaking up the data into primitive units. Code Block 62

Customized Mobile Robot System

#include

4.5.13 ConnectionDialog.cpp Description Offers a dialog box to the user to choose a robot address from a list, or to enter an IP address UML ConnectionDialog -robotAddress : QString -IPAddress : QHostAddress +ConnectionDialog(in parent : QWidget*) +~ConnectionDialog() +populateWithRobotsAddresses(in list : const QStringList &) +currentSelection() : QString +SetRobotAddress(in index : int) +on_robotsListRB_toggled(in value : bool) +on_provideIPAddressRB_toggled(in value : bool) -validateIPAddressFormat() : bool

Classes and Libraries Used QWidget The QWidget class is the base class of all user interface objects. The widget is the atom of the user interface: it receives mouse, keyboard and other events from the window system, and paints a representation of itself on the screen. Every widget is rectangular, and they are sorted in a Z-order. A widget is clipped by its parent and by the widgets in front of it. Code Block #include

63

Customized Mobile Robot System

QDialog The QDialog class is the base class of dialog windows. A dialog window is a top-level window mostly used for short-term tasks and brief communications with the user. QDialogs can provide a return value, and they can have default buttons. QDialogs can also have a QSizeGrip in their lower-right corner, usingsetSizeGripEnabled() Code Block #include

QComboBox The QComboBox widget is a combined button and popup list. A QComboBox provides a means of presenting a list of options to the user in a way that takes up the minimum amount of screen space. A combobox is a selection widget that displays the current item, and can pop up a list of selectable items. A combobox may be editable, allowing the user to modify each item in the list. Code Block #include

QString The QString class provides a Unicode character string QString stores a string of 16-bit QChars, where each QChar corresponds one Unicode 4.0 character. (Unicode characters with code values above 65535 are stored using surrogate pairs, i.e., two consecutive QChars.)

Code Block 64

Customized Mobile Robot System

#include

QLineEdit The QLineEdit widget is a one-line text editor. A line edit allows the user to enter and edit a single line of plain text with a useful collection of editing functions, including undo and redo, cut and paste, and drag and drop. By changing the echoMode() of a line edit, it can also be used as a "write-only" field, for inputs such as passwords.

Code Block #include

QHostAddress The QHostAddress class provides an IP addressThis class holds an IPv4 or IPv6 address in a platform- and protocol-independent manner. QHostAddress is normally used with the QTcpSocket,QTcpServer, and QUdpSocket to connect to a host or to set up a server.

Code Block #include

65

Customized Mobile Robot System

4.5.14 SensorsView.cpp Description A specialized view to render the sensor's data

UML

SensorsView -crv : QwtPlotCurve -index : int -maxData : int -minData : int -xval[120] : double -yval[120] : double -xMap : QwtScaleMap -yMap : QwtScaleMap -m_thread : SensorsDataThread +SensorsView(in parent : QWidget* = 0) +~SensorsView() +newData(in val : float) +newData(in data : char*, in size : int) +connectTo(in address : const QString &) +disconnect() +shiftDown(in rect : QRect &, in offset : int) +drawContents(in p : QPainter*) +paintEvent(in Parameter1 : QPaintEvent*)

Classes and libraries used QWidget

66

Customized Mobile Robot System

The QWidget class is the base class of all user interface objects. it receives mouse, keyboard and other events from the window system, and paints a representation of itself on the screen. Every widget is rectangular, and they are sorted in a Z-order. A widget is clipped by its parent and by the widgets in front of it. Code Block #include

QFrame The QFrame class is the base class of widgets that can have a frame. Code Block QFrame(parent)

Qt Gui Module QColor The QColor class provides colors based on RGB, HSV or CMYK values Code Block #include

QRect The QRect class defines a rectangle in the plane using integer precision.

Code Block #include

67

Customized Mobile Robot System

QPaintEvent The QPaintEvent class contains event parameters for paint events. Code Block #include

QBrush Class The QBrush class defines the fill pattern of shapes drawn by QPainter Code Block #include

QPainter The QPainter class performs low-level painting on widgets and other paint devices. Code Block #include

QPaintEngine The QPaintEngine class provides an abstract definition of how QPainter draws to a given device on a given platform. Code Block #include

QFont

68

Customized Mobile Robot System

The QFont class specifies a font used for drawing text Code Block #include

QThread The QThread class provides platform-independent threads. Code Block #include

4.5.15 SensorsDataThread.cpp Description The thread that handles opening the socket and waiting for the sensor data Classes and Libraries Used QtNetwork Library The QtNetwork module offers classes that allow you to write TCP/IP clients and servers. Code Block #include

QThread The QThread class provides platform-independent thread. 69

Customized Mobile Robot System

Code Block #include

QMutexLocker The QMutexLocker class is a convenience class that simplifies locking and unlocking mutexes. Code Block #include

QTcpSocket Class The QTcpSocket class provides a TCP socket

QDataStream The QDataStream class provides serialization of binary data to aQIODevice. Code Block #include

70

Customized Mobile Robot System

UML SensorsDataThread -m_parent : SensorsView * -hostName : QString -port : quint16 -mutex : QMutex -cond : QWaitCondition -stopRequested : bool -m_SensorsData : char * -connected : bool +SensorsDataThread(in parent : SensorsView* = 0) +~SensorsDataThread() +setRobotAddress(in address : const QString &) +stop() +isConnected() : bool +startAcquiringGPSData(in hostName : const QString &, in port : quint16) +run() +quitRunning() +wakeUpAndWork() +error(in socketError : int, in message : const QString &)

4.6 Constraints, Alternatives and Tradeoffs C++ was chosen as the language for writing the robot end code. It has the advantage of running faster than programs like JAVA that require services from other programs like C# or JAVA and .Net or JVM respectively. Furthermore writing the code in C++ makes it more portable since there are C++ compilers available for most platforms. Finally, unlike C, C++ provides Object Oriented abstractions that make writing and modifying code easier. C++ was also used to develop the Control Interface software with the QT library. Using C++ has all the advantages listed above and furthermore, QT is supported on Windows and many Unix based systems like Linux and Macs. JAVA could have been used as the alternative. Finally, linux was used at the Control Interface since unlike Windows the use of the QT library is free on Linux. MS robotics Studio could have been used at both ends as an alternative; however, it imposes limits on the flexibility of the system. More

71

Customized Mobile Robot System

specifically, it has to run on a Windows system and coding for it has to be done in one of the languages available in Visual Studio.

4.7 Common Linux Features a) Multiuser  Linux maintains multiple user accounts, and allows multiple users to log in and use the system simultaneously.  Different users can set different working environments (e.g., different desktop interfaces). b) Multitasking  Linux can manage to run multiple programs at the same time.  It can run background processes called daemons. c) Graphical User Interface (X Window System)  Linux supports a powerful framework for graphical applications interface. This framework is called X Window System (or simply X).  There are several desktop environments and many desktop managers. (Red Hat provides several desktop managers, but focuses on GNOME and KDE desktop environments.

d) Hardware support  Linux supports nearly all types of hardware (e.g., floppy disk drives, CD-ROMs, removable disks).

e) Networking connectivity  Linux supports a variety of communication devices (e.g., LAN cards, modems, and serial devices).

72

Customized Mobile Robot System

 Linux supports a variety of communication protocols in all the layers (e.g., TCP/IP for the Internet, IPX for Novell networks). f) Network servers Linux is stable, so it can run servers to provide services to clients g) Application support  Linux is compatible with POSIX and several application programming interfaces (APIs), so there are many freewares and sharewares for execution on Linux.

73

Customized Mobile Robot System

Chapter 5: Networking 5.1 Introduction After reading the previous chapters, now we have knowledge about embedded system (hardware &software) and the remote control application now we want to know about how to communicate between them through wireless network There are a lot of chooses for wireless network like Bluetooth, RF, InfraRed (IRDA), Wi-Fi, WI-MAX, ZigBee, GSM, GPRS, 3/4G)

5.1.1 Bluetooth Bluetooth is an open wireless protocol for exchanging data over short distances from fixed and mobile devices, creating personal area networks (PANs). It was originally conceived as a wireless alternative to RS232 data cables. It can connect several devices, overcoming problems of synchronization. Bluetooth uses a radio technology called frequency-hopping spread spectrum, which chops up the data being sent and transmits chunks of it on up to 79 frequencies. In its basic mode, the modulation is Gaussian frequency-shift keying (GFSK). It can achieve a gross data rate of 1 Mb/s. Bluetooth provides a way to connect and exchange information between devices such as mobile phones, telephones, laptops, personal computers, printers, Global Positioning System (GPS) receivers, digital cameras, and video game consoles through a secure, globally unlicensed Industrial, Scientific and Medical (ISM) 2.4 GHz short-range radio frequency bandwidth. The Bluetooth specifications are developed and licensed by the Bluetooth Special Interest Group (SIG). The Bluetooth SIG consists of companies in the areas of telecommunication, computing, networking, and consumer electronics.

74

Customized Mobile Robot System

Bluetooth is a standard and communications protocol primarily designed for low power consumption, with a short range (power-class-dependent: 1 meter, 10 meters, 100 meters) based on low-cost transceiver microchips in each device. Bluetooth makes it possible for these devices to communicate with each other when they are in range. Because the devices use a radio (broadcast) communications system, they do not have to be in line of sight of each other.

Class

Maximum Permitted Power Range mW (dBm) (approximate)

Class 1 100 mW (20 dBm)

~100 meters

Class 2 2.5 mW (4 dBm)

~10 meters

Class 3 1 mW (0 dBm)

~1 meter

Version

Data Rate

Version 1.2

1 Mbit/s

Version 2.0 + EDR 3 Mbit/s

Bluetooth and Wi-Fi have many applications in today's offices, homes, and on the move: setting up networks, printing, or transferring presentations and files from PDAs to computers. Both are versions of unlicensed wireless technology. Wi-Fi is intended for resident equipment and its applications. The category of applications is outlined as WLAN, the wireless local area

75

Customized Mobile Robot System

networks. Wi-Fi is intended as a replacement for cabling for general local area network access in work areas. Bluetooth is intended for nonresident equipment and its applications. The category of applications is outlined as the wireless personal area network (WPAN). Bluetooth is a replacement for cabling in a variety of personally carried applications in any ambience.

Wi-Fi Wi-Fi is a traditional Ethernet network, and requires configuration to set up shared resources, transmit files, and to set up audio links (for example, headsets and hands-free devices). Wi-Fi uses the same radio frequencies as Bluetooth, but with higher power, resulting in a stronger connection. Wi-Fi is sometimes called "wireless Ethernet." This description is accurate, as it also provides an indication of its relative strengths and weaknesses. Wi-Fi requires more setup but is better suited for operating full-scale networks; it enables a faster connection, better range from the base station, and better security than Bluetooth. Features 

Broadcast Channel: enables Bluetooth information points. This will drive the adoption of Bluetooth into mobile phones, and enable advertising models based around users pulling information from the information points, and not based around the object push model that is used in a limited way today.



Topology Management: enables the automatic configuration of the piconet topologies especially in scatternet situations that are becoming more common today. This should all be invisible to the users of the technology, while also making the technology just work.



QoS improvements: enable audio and video data to be transmitted at a higher quality, especially when best effort traffic is being transmitted in the same piconet.

76

Customized Mobile Robot System

Security Bluetooth implements confidentiality, authentication and key derivation with custom algorithms based on the SAFER+ block cipher. In Bluetooth, key generation is generally based on a Bluetooth PIN, which must be entered into both devices. This procedure might be modified if one of the devices has a fixed PIN, e.g. for headsets or similar devices with a restricted user interface. During pairing, an initialization key or master key is generated, using the E22 algorithm The E0 stream cipher is used for encrypting packets, granting confidentiality and is based on a shared cryptographic secret, namely a previously generated link key or master key. Those keys, used for subsequent encryption of data sent via the air interface, rely on the Bluetooth PIN, which has been entered into one or both devices. In September 2008, the National Institute of Standards and Technology (NIST) published a Guide to Bluetooth Security that will serve as reference to organization on the security capabilities of Bluetooth and steps for securing Bluetooth technologies effectively. While Bluetooth has its benefits, it is susceptible to denial of service attacks, eavesdropping, man-in-the-middle attacks, message modification, and resource misappropriation. Users/organizations must evaluate their acceptable level of risk and incorporate security into the lifecycle of Bluetooth devices. To help mitigate risks, included in the NIST document are security checklists with guidelines and recommendations for creating and maintaining secure Bluetooth piconets, headsets, and smart card readers. Bluejacking Bluejacking is the sending of either a picture or a message from one user to an unsuspecting user through Bluetooth wireless technology. Common applications include short messages (e.g., "You’ve just been bluejacked!"). Bluejacking does not involve the removal or alteration of any data from the device Radio frequency (RF) is a frequency or rate of oscillation within the range of about 3 Hz to 300 GHz. This range corresponds to frequency of alternating current electrical signals used to produce and detect radio waves. Since most of this range is beyond the vibration rate that most

77

Customized Mobile Robot System

mechanical systems can respond to, RF usually refers to oscillations in electrical circuits. Electrical currents that oscillate at RF have special properties not shared by direct current signals. One such property is the ease with which they can ionize air to create a conductive path through air. This property is exploited by 'high frequency' units used in electric arc welding, although strictly speaking these machines do not typically employ frequencies within the HF band. Another special property is an electromagnetic force that drives the RF current to the surface of conductors, known as the skin effect. Another property is the ability to appear to flow through paths that contain insulating material, like the dielectric insulator of a capacitor. The degree of effect of these properties depends on the frequency of the signals. RF is suitable for this project's impelementations but on narrow areas, low viedo rates. So can not use RF.

5.1.2 ZigBee ZigBee is a specification for a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4-2003 standard for wireless personal area networks (WPANs), such as wireless headphones connecting with cell phones via short-range radio. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking. The ZigBee Alliance is a group of companies which maintain and publish the ZigBee standard.

78

Customized Mobile Robot System

5.1.3 Infrared (IR) Infrared radiation is electromagnetic radiation whose wavelength is longer than that of visible light (400-700 nm), but shorter than that of terahertz radiation (100 µm - 1 mm) and microwaves (~30,000 µm). Infrared radiation spans roughly three orders of magnitude (750 nm and 100 µm). Direct sunlight has a luminous efficacy of about 93 lumens per watt of radiant flux, which includes infrared (47% share of the spectrum), visible (46%), and ultra-violet (only 6%) light. Bright sunlight provides luminance of approximately 100,000 candela per square meter at the Earth's surface. Infrared can send control signals via robot but robot must be straight towards the infrared controlling unit, no viedo can be sent. so can not use IR. Between tens of applications use IR, IR data transmission is also employed in short-range communication among computer peripherals and personal digital assistants. These devices usually conform to standards published by IrDA, the Infrared Data Association. Remote controls and IrDA devices use infrared light-emitting diodes (LEDs) to emit infrared radiation which is focused by a plastic lens into a narrow beam. The beam is modulated, i.e. switched on and off, to encode the data. The receiver uses a silicon photodiode to convert the infrared 79

Customized Mobile Robot System

radiation to an electric current. It responds only to the rapidly pulsing signal created by the transmitter, and filters out slowly changing infrared radiation from ambient light. Infrared communications are useful for indoor use in areas of high population density. IR does not penetrate walls and so does not interfere with other devices in adjoining rooms. Infrared is the most common way for remote controls to command appliances. Free space optical communication using infrared lasers can be a relatively inexpensive way to install a communications link in an urban area operating at up to 4 gigabit/s, compared to the cost of burying fiber optic cable. Infrared lasers are used to provide the light for optical fiber communications systems. Infrared light with a wavelength around 1,330 nm (least dispersion) or 1,550 nm (best transmission) are the best choices for standard silica fibers. IR data transmission of encoded audio versions of printed signs is being researched as an aid for visually impaired people through the RIAS (Remote Infrared Audible Signage) project

5.1.4 Wi-Fi Wi-Fi is a trademark of the Wi-Fi Alliance for certified products based on the IEEE 802.11 standards. This certification warrants interoperability between different wireless devices. The term Wi-Fi is often used by the public as a synonym for wireless LAN (WLAN); but not every wireless LAN product has a Wi-Fi certification, which may be because of certification costs that must be paid for each certified device type. Wi-Fi is supported by most personal computer operating systems, many game consoles, laptops, smartphones, printers, and other peripherals Wi-Fi uses both single carrier direct-sequence spread spectrum radio technology (part of the larger family of spread spectrum systems) and multi-carrier OFDM (Orthogonal Frequency Division Multiplexing) radio technology. The regulations for unlicensed spread spectrum enabled the 80

Customized Mobile Robot System

development of Wi-Fi, its onetime competitor HomeRF, Bluetooth, and many other products such as some types of cordless telephones. A Wi-Fi enabled device such as a PC, game console, mobile phone, MP3 player or PDA can connect to the Internet when within range of a wireless network connected to the Internet. The coverage of one or more interconnected access points — called a hotspot — can comprise an area as small as a single room with wireless-opaque walls or as large as many square miles covered by overlapping access points. Wi-Fi technology has served to set up mesh networks, for example, in London both architectures can operate in community networks

Operational Advantages of Wi-Fi Wi-Fi allows local area networks (LANs) to be deployed without wires for client devices, typically reducing the costs of network deployment and expansion. Spaces where cables cannot be run, such as outdoor areas and historical buildings, can host wireless LANs. Wireless network adapters are now built into most laptops. The price of chipsets for Wi-Fi continues to drop, making it an economical networking option included in even more devices. Wi-Fi has become widespread in corporate infrastructures. Different competitive brands of access points and client network interfaces are inter-operable at a basic level of service. Products designated as "Wi-Fi Certified" by the Wi-Fi Alliance are backwards compatible. Wi-Fi is a global set of standards. Unlike mobile telephones, any standard Wi-Fi device will work anywhere in the world. Wi-Fi is widely available in more than 220,000 public hotspots and tens of millions of homes and corporate and university campuses worldwide. The current version of Wi-Fi Protected Access encryption (WPA2) is not easily defeated, provided strong passwords are used. New protocols for Quality of Service (WMM) make Wi-Fi more suitable for latency-sensitive applications (such as voice and video), and power saving mechanisms (WMM Power Save) improve battery operation. With this advantages we recommened with wi-fi in this project.

81

Customized Mobile Robot System

IEEE 802.11 is a set of standards carrying out wireless local area network (WLAN) computer communication in the 2.4, 3.6 and 5 GHz frequency bands. They are implemented by the IEEE LAN/MAN Standards Committee IEEE 802 . Wi-Fi’s General Description The 802.11 family includes over-the-air modulation techniques that use the same basic protocol. The most popular are those defined by the 802.11b and 802.11g protocols, and are amendments to the original standard. 802.11-1997 was the first wireless networking standard, but 802.11b was the first widely accepted one, followed by 802.11g and 802.11n. Security was originally purposefully weak due to export requirements of some governments, and was later enhanced via the 802.11i amendment after governmental and legislative changes. 802.11n is a new multi-streaming modulation technique that is still under draft development, but products based on its proprietary pre-draft versions are being sold. Other standards in the family (c–f, h, j) are service amendments and extensions or corrections to previous specifications. 802.11b and 802.11g use the 2.4 GHz ISM band, operating in the United States under Part 15 of the US Federal Communications Commission Rules and Regulations. Because of this choice of frequency band, 802.11b and g equipment may occasionally suffer interference from microwave ovens, cordless telephones and Bluetooth devices. Both 802.11 and Bluetooth control their interference and susceptibility to interference by using spread spectrum modulation. Bluetooth uses a frequency hopping spread spectrum signaling method (FHSS) while 802.11b/g use the direct sequence spread spectrum signaling (DSSS) and orthogonal frequency division multiplexing (OFDM) methods respectively. 802.11a uses the 5 GHz U-NII band, which, for much of the world, offers at least 19 non-overlapping channels rather than the 3 offered in the 2.4 GHz ISM frequency band Propagation around objects such as walls and furniture tends to be better at higher frequencies This is because higher frequencies scatter more, which helps them get around objects .However penetration is better with lower frequencies. Better or worse performance with higher or lower frequencies (channels) may be realized, depending on the environment. Wi-Fi generally reflects around objects rather than going through them.

82

Customized Mobile Robot System

The segment of the radio frequency spectrum used varies between countries. In the US, 802.11a and 802.11g devices may be operated without a license, as allowed in Part 15 of the FCC Rules and Regulations. Frequencies used by channels one through six (802.11b) falls within the 2.4 GHz amateur radio band. Licensed amateur radio operators may operate 802.11b/g devices under Part 97 of the FCC Rules and Regulations, allowing increased power output but not commercial content or encryption. Mobility in Wi-Fi Because of the very limited practical range of Wi-Fi, mobile use is essentially confined to such applications as inventory taking machines in warehouses or retail spaces, barcode reading devices at check-out stands or receiving / shipping stations. Mobile use of Wi-Fi over wider ranges is limited to move, use, as for instance in an automobile moving from one hotspot to another (Wardriving). Other wireless technologies are more suitable as illustrated in the graphic. Threats to Security of Wi-Fi The most common wireless encryption standard, Wired Equivalent Privacy or WEP, has been shown to be easily breakable even when correctly configured. Wi-Fi Protected Access (WPA and WPA2), which began shipping in 2003, aims to solve this problem and is now available on most products. Wi-Fi Access Points typically default to an "open" (encryption-free) mode. Novice users benefit from a zero-configuration device that works out of the box, but this default is without any wireless security enabled, providing open wireless access to their LAN. To turn security on requires the user to configure the device, usually via a software graphical user interface (GUI). Wi-Fi networks that are open (unencrypted) can be monitored and used to read and copy data (including personal information) transmitted over the network, unless another security method is used to secure the data, such as a VPN or a secure web page. (See HTTPS/Secure Socket Layer.)

83

Customized Mobile Robot System

Wi-Fi Hardware Standard Devices A wireless access point (WAP) connects a group of wireless devices to an adjacent wired LAN. An access point is similar to a network hub, relaying data between connected wireless devices in addition to a (usually) single connected wired device, most often an Ethernet hub or switch, allowing wireless devices to communicate with other wired devices. Wireless adapters allow devices to connect to a wireless network. These adapters connect to devices using various external or internal interconnects such as PCI, miniPCI, USB, ExpressCard, Cardbus and PC card. Most newer laptop computers are equipped with internal adapters. Internal cards are generally more difficult to install. Wireless routers integrate a Wireless Access Point, Ethernet switch, and internal Router firmware application that provides IP Routing, NAT, and DNS forwarding through an integrated WAN interface. A wireless router allows wired and wireless Ethernet LAN devices to connect to a (usually) single WAN device such as cable modem or DSL modem. A wireless router allows all three devices (mainly the access point and router) to be configured through one central utility. This utility is most usually an integrated web server which serves web pages to wired and wireless LAN clients and often optionally to WAN clients. This utility may also be an application that is run on a desktop computer such as Apple's AirPort. Wireless network bridges connect a wired network to a wireless network. This is different from an access point in the sense that an access point connects wireless devices to a wired network at the datalink layer. Two wireless bridges may be used to connect two wired networks over a wireless link, useful in situations where a wired connection may be unavailable, such as between two separate homes. Wireless range extenders or wireless repeaters can extend the range of an existing wireless network. Range extenders can be strategically placed to elongate a signal area or allow for the signal area to reach 84

Customized Mobile Robot System

around barriers such as those created in L-shaped corridors. Wireless devices connected through repeaters will suffer from an increased latency for each hop. Additionally, a wireless device connected to any of the repeaters in the chain will have a throughput that is limited by the weakest link between the two nodes in the chain from which the connection originates to where the connection ends. Embedded systems Embedded serial-to-Wi-Fi module Wi-Fi availability in the home is on the increase. This extension of the Internet into the home space will increasingly be used for remote monitoring .Examples of remote monitoring include security systems and tele-medicine. In all these kinds of implementation, if the Wi-Fi provision is provided using a system running one of operating systems mentioned above, then it becomes unfeasible due to weight, power consumption and cost issues. Increasingly in the last few years (particularly as of early 2007), embedded Wi-Fi modules have become available which come with a real-time operating system and provide a simple means of wireless enabling any device which has and communicates via a serial port. This allows simple monitoring devices – for example, a portable ECG monitor hooked up to a patient in their home – to be created. This Wi-Fi enabled device effectively becomes part of the internet cloud and can communicate with any other node on the internet. The data collected can hop via the home's Wi-Fi access point to anywhere on the internet. These Wi-Fi modules are designed so that designers need minimal Wi-Fi knowledge to wireless-enable their products. Network Security The main issue with wireless network security is its simplified access to the network compared to traditional wired networks such as Ethernet. With wired networking it is necessary to either gain access to a building, physically connecting into the internal network, or break through an external firewall. Most business networks protect sensitive data and systems by attempting to disallow external access. Thus being able to

85

Customized Mobile Robot System

get wireless reception provides an attack vector, if encryption is not used or can be defeated. Attackers who have gained access to a Wi-Fi network can use DNS spoofing attacks very effectively against any other user of the network, because they can see the DNS requests made, and often respond with a spoofed answer before the queried DNS server has a chance to reply. Securing methods A common but unproductive measure to deter unauthorized users is to suppress the AP's SSID broadcast, "hiding" it. This is ineffective as a security method because the SSID is broadcast in the clear in response to a client SSID query. Another unproductive method is to only allow computers with known MAC addresses to join the network. MAC address are easily spoofed. If the eavesdropper has the ability to change his MAC address, then he may join the network by spoofing an authorized address. Wired Equivalent Privacy (WEP) encryption was designed to protect against casual snooping, but is now considered completely broken. Tools such as AirSnort or aircrack can quickly recover WEP encryption keys. Once it has seen 5-10 million encrypted packets, AirSnort can determine the encryption password in under a second; newer tools such as aircrack-ptw can use Klein's attack to crack a WEP key with a 50% success rate using only 40,000 packets. To counteract this in 2002, the Wi-Fi Alliance blessed Wi-Fi Protected Access (WPA) which uses TKIP as a stopgap solution for legacy equipment. Though more secure than WEP, it has outlived its designed lifetime, has known attack vectors and is no longer recommended. In 2004 the full IEEE 802.11i (WPA2) encryption standards were released. If used with a 802.1X server or in pre-shared key mode with a strong and uncommon passphrase WPA2 is still considered secure, as of 2009.

86

Customized Mobile Robot System

Protocols 802.11-1997 (802.11 legacy) The original version of the standard IEEE 802.11 was released in 1997 and clarified in 1999, but is today obsolete. It specified two net bit rates of 1 or 2 megabits per second (Mbit/s), plus forward error correction code. It specified three alternative physical layer technologies: diffuse infrared operating at 1 Mbit/s; frequency-hopping spread spectrum operating at 1 Mbit/s or 2 Mbit/s; and direct-sequence spread spectrum operating at 1 Mbit/s or 2 Mbit/s. The latter two radio technologies used microwave transmission over the Industrial Scientific Medical frequency band at 2.4 GHz. Some earlier WLAN technologies used lower frequencies, such as the U.S. 900 MHz ISM band. Legacy 802.11 with direct-sequence spread spectrum was rapidly supplemented and popularized by 802.11b.

802.11a Release date Op. Frequency Throughput (type.) Net bit rate (max.) Gross bit rate (max.)

October 1999 5 GHz

27 Mbit/s

54 Mbit/s

72 Mbit/s

The 802.11a standard uses the same data link layer protocol and frame format as the original standard, but an OFDM based air interface (physical layer). It operates in the 5 GHz band with a maximum net data rate of 54 Mbit/s, plus error correction code, which yields realistic net achievable throughput in the mid-20 Mbit/s Since the 2.4 GHz band is heavily used to the point of being crowded, using the relatively un-used 5 GHz band gives 802.11a a significant advantage. However, this high carrier frequency also brings a disadvantage: The effective overall range of 802.11a is less than that of 802.11b/g; and in theory 802.11a signals cannot penetrate as far as those for 802.11b because they are absorbed more readily by walls and 87

Customized Mobile Robot System

other solid objects in their path due to their smaller wavelength. In practice 802.11b typically has a higher distance range at low speeds (802.11b will reduce speed to 5 Mbit/s or even 1 Mbit/s at low signal strengths). However, at higher speeds, 802.11a typically has the same or higher range due to less interference. 802.11b Release date Frequency band Throughput (type.) Net bit rate (max.)

October 1999 2.4 GHz

~5 Mbit/s

11 Mbit/s

802.11b has a maximum raw data rate of 11 Mbit/s and uses the same media access method defined in the original standard. 802.11b products appeared on the market in early 2000, since 802.11b is a direct extension of the modulation technique defined in the original standard. The dramatic increase in throughput of 802.11b (compared to the original standard) along with simultaneous substantial price reductions led to the rapid acceptance of 802.11b as the definitive wireless LAN technology. 802.11b devices suffer interference from other products operating in the 2.4 GHz band. Devices operating in the 2.4 GHz range include: microwave ovens, Bluetooth devices, baby monitors and cordless telephones. 802.11g Release date Op. Frequency Throughput (type.) Net bit rate (max.) Gross bit rate (max.)

June 2003

2.4 GHz

~22 Mbit/s

54 Mbit/s

128 Mbit/s

In June 2003, a third modulation standard was ratified: 802.11g. This works in the 2.4 GHz band (like 802.11b), but uses the same OFDM based transmission scheme as 802.11a. It operates at a maximum physical layer bit rate of 54 Mbit/s exclusive of forward error correction codes, or about 22 Mbit/s average throughputs. 802.11g hardware is 88

Customized Mobile Robot System

fully backwards compatible with 802.11b hardware and therefore is encumbered with legacy issues that reduce throughput when compared to 802.11a by ~21%. The then-proposed 802.11g standard was rapidly adopted by consumers starting in January 2003, well before ratification, due to the desire for higher data rates, and reductions in manufacturing costs. By summer 2003, most dual-band 802.11a/b products became dual-band/tri-mode, supporting a, and b/g in a single mobile adapter card or access point. Details of making b and g work well together occupied much of the lingering technical process; in an 802.11g network, however, activity of an 802.11b participant will reduce the data rate of the overall 802.11g network. Like 802.11b, 802.11g devices suffer interference from other products operating in the 2.4 GHz band.

802.11-2007 In 2003, task group TGma was authorized to "roll up" many of the amendments to the 1999 version of the 802.11 standard. REVma or 802.11ma, as it was called, created a single document that merged 8 amendments (802.11a,b,d,e,g,h,i,j) with the base standard. Upon approval on March 08, 2007, 802.11REVma was renamed to the current base standard IEEE 802.11-2007. 802.11n 802.11n is a proposed amendment which improves upon the previous 802.11 standards by adding multiple-input multiple-output (MIMO) and many other newer features. The TGn workgroup is not expected to finalize the amendment until December 2009.Enterprises, however, have already begun migrating to 802.11n networks based on Draft 2 of the 802.11n proposal. A common strategy for many businesses is to set up 802.11b and 802.11g client devices while gradually moving to 802.11n clients as part of new equipment purchases. Release date

Op. Frequency

Throughput (type.) Net bit rate (max.)

89

Customized Mobile Robot System

January 2010 (est.) 5 GHz and/or 2.4 GHz 144 Mbit/s

600 Mbit/s

Channels and international compatibility 802.11 divide each of the above-described bands into channels, analogously to how radio and TV broadcast bands are carved up but with greater channel width and overlap. For example the 2.4000–2.4835 GHz band is divided into 13 channels each of width 22 MHz but spaced only 5 MHz apart, with channel 1 centered on 2.412 GHz and 13 on 2.472 GHz to which Japan adds a 14th channel 12 MHz above channel 13. Availability of channels is regulated by country, constrained in part by how each country allocates radio spectrum to various services. At one extreme Japan permits the use of all 14 channels (with the exclusion of 802.11g/n from channel 14), while at the other Spain allowed only channels 10 and 11 and France allowed only 10, 11, 12 and 13 (now both countries follow the European model of allowing channels 1 through 13). Most other European countries are almost as liberal as Japan, disallowing only channel 14, while North America and some Central and South American countries further disallow 12 and 13. For more details on this topic, see List of WLAN channels. Besides specifying the centre frequency of each channel, 802.11 also specify (in Clause 17) a spectral mask defining the permitted distribution of power across each channel. The mask requires that the signal be attenuated by at least 30 dB from its peak energy at ±11 MHz from the centre frequency, the sense in which channels are effectively 22 MHz wide. One consequence is that stations can only use every fourth or fifth channel without overlap, typically 1, 6 and 11 in the Americas, 1, 5, 9 and 13 in Europe, etc. Another is that channels 1-13 effectively require the band 2.401–2.483 GHz, the actual allocations being, for example, 2.400–2.4835 GHz in the UK, 2.402–2.4735 GHz in the US, etc. Since the spectral mask only defines power output restrictions up to ±22 MHz from the center frequency to be attenuated by 50 dB, it is often assumed that the energy of the channel extends no further than these limits. It is more correct to say that, given the separation between channels 1, 6, and 11, the signal on any channel should be sufficiently 90

Customized Mobile Robot System

attenuated to minimally interfere with a transmitter on any other channel. Due to the near-far problem a transmitter can impact a receiver on a "non-overlapping" channel, but only if it is close to the victim receiver (within a meter) or operating above allowed power levels. Although the statement that channels 1, 6, and 11 are "non-overlapping" is limited to spacing or product density, the 1–6–11 guideline has merit. If transmitters are closer together than channels 1, 6, and 11 (for example, 1, 4, 7, and 10), overlap between the channels may cause unacceptable degradation of signal quality and throughput. However, overlapping channels may be used under certain circumstances. This way, more channels are available

5.1.5 WiMAX WiMAX meaning Worldwide Interoperability for Microwave Access, is a telecommunications technology that provides wireless transmission of data using a variety of transmission modes, from point-to-multipoint links to portable and fully mobile internet access. The technology provides up to 3 Mbit/s broadband speed without the need for cables. The technology is based on the IEEE 802.16 standard (also called Broadband Wireless Access). The name "WiMAX" was created by the WiMAX Forum, which was formed in June 2001 to promote conformity and interoperability of the standard. The forum describes WiMAX as "a standards-based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL The terms "fixed WiMAX", "mobile WiMAX", "802.16d" and "802.16e" are frequently used incorrectly. Correct definitions are the following: 



802.16-2004 is often called 802.16d, since that was the working party that developed the standard. It is also frequently referred to as "fixed WiMAX" since it has no support for mobility. 802.16e-2005 is an amendment to 802.16-2004 and is often referred to in shortened form as 802.16e. It introduced support for mobility, amongst other things and is therefore also known as "mobile WiMAX".

91

Customized Mobile Robot System

Comparison with Wi-Fi Comparisons and confusion between WiMAX and Wi-Fi are frequent because both are related to wireless connectivity and Internet access. 

 



WiMAX uses spectrum to deliver a point-to-point connection to the Internet. Different 802.16 standards provide different types of access, from portable (similar to a cordless phone) to fixed (an alternative to wired access, where the end user's wireless termination point is fixed in location.) Wi-Fi uses unlicensed spectrum to provide access to a network. Wi-Fi is more popular in end user devices. WiMAX and Wi-Fi have quite different quality of service (QoS) mechanisms. WiMAX uses a mechanism based on connections between the base station and the user device. Each connection is based on specific scheduling algorithms. Wi-Fi has a QoS mechanism similar to fixed Ethernet, where packets can receive different priorities based on their tags. For example VoIP traffic may be given priority over web browsing. Wi-Fi runs on the Media Access Control's CSMA/CA protocol, which is connectionless and contention based, whereas WiMAX runs a connection-oriented MAC.

Both 802.11 and 802.16 define Peer-to-Peer (P2P) and ad hoc networks, where an end user communicates to users or servers on another Local Area Network (LAN) using its access point or base station Uses The bandwidth and range of WiMAX make it suitable for the following potential applications:    



Connecting Wi-Fi hotspots to the Internet. Providing a wireless alternative to cable and DSL for "last mile" broadband access. Providing data and telecommunications services. Providing a source of Internet connectivity as part of a business continuity plan. That is, if a business has both a fixed and a wireless Internet connection, especially from unrelated providers, they are unlikely to be affected by the same service outage. Providing portable connectivity.

92

Customized Mobile Robot System

Broadband Access Companies are closely examining WiMAX for last mile connectivity.The resulting competition may bring lower pricing for both home and business customers or bring broadband access to places where it has been economically unavailable. WiMAX access was used to assist with communications in Aceh, Indonesia, after the tsunami in December 2004. All communication infrastructures in the area, other than amateur radio, was destroyed, making the survivors unable to communicate with people outside the disaster area and vice versa. WiMAX provided broadband access that helped regenerate communication to and from Aceh. In addition, WiMAX was donated by Intel Corporation to assist the FCC and FEMA in their communications efforts in the areas affected by Hurricane Katrina. In practice, volunteers used mainly self-healing mesh, VoIP, and a satellite uplink combined with Wi-Fi on the local link. Subscriber units (Client Units) WiMAX subscriber units are available in both indoor and outdoor versions from several manufacturers. Self-install indoor units are convenient, but radio losses mean that the subscriber must be significantly closer to the WiMAX base station than with professionallyinstalled external units. As such, indoor-installed units require a much higher infrastructure investment as well as operational cost (site lease, backhaul, maintenance) due to the high number of base stations required to cover a given area. Indoor units are comparable in size to a cable modem or DSL modem. Outdoor units are roughly the size of a laptop PC, and their installation is comparable to the installation of a residential satellite dish. With the potential of mobile WiMAX, there is an increasing focus on portable units. This includes handsets (similar to cellular smartphones), PC peripherals (PC Cards or USB dongles), and embedded devices in laptops, which are now available for Wi-Fi services. In addition, there is much emphasis from operators on consumer electronics devices such as Gaming consoles, MP3 players and similar devices. It is notable that WiMAX is more similar to Wi-Fi than to 3G cellular technologies.

93

Customized Mobile Robot System

Current certified devices can be found at the WiMAX Forum web site. This is not a complete list of devices available as certified modules are embedded into laptops, MIDs (Mobile Internet Devices), and private labeled devices. Mobile handset applications Sprint Nextel announced in mid-2006 that it would invest about US$ 5 billion in a WiMAX technology buildout over the next few years. Since that time Sprint has faced many setbacks that have resulted in steep quarterly losses. On May 7, 2008, Sprint, Imagine, Google, Intel, Comcast, and Time Warner announced a pooling of an average of 120 MHz of spectrum and formation of a new company which will take the name Clearwire. The new company hopes to benefit from combined services offerings and network resources as a springboard past its competitors. The cable companies will provide media services to other partners while gaining access to the wireless network as a Mobile virtual network operator. Google will contribute Android handset device development and applications and will receive revenue share for advertising and other services they provide. Clearwire Sprint and current Clearwire gain a majority stock ownership in the new venture and ability to access between the new Clearwire and Sprint 3G networks. Some details remain unclear including how soon and in what form announced multi-mode WiMAX and 3G EV-DO devices will be available. This raises questions that arise for availability of competitive chips that require licensing of Qualcomm's IPR. Some analysts have questioned how the deal will work out: Although fixed-mobile convergence has been a recognized factor in the industry, prior attempts to form partnerships among wireless and cable companies have generally failed to lead to significant benefits to the participants. Other analysts point out that as wireless progresses to higher bandwidth, it inevitably competes more directly with cable and DSL, thrusting competitors into bed together. Also, as wireless broadband networks grow denser and usage habits shift, the need for increased backhaul and media service will accelerate, therefore the opportunity to leverage cable assets is expected to increase.

94

Customized Mobile Robot System

Backhaul/access network applications WiMAX is a possible replacement candidate for cellular phone technologies such as GSM and CDMA, or can be used as an overlay to increase capacity. It has also been considered as a wireless backhaul technology for 2G, 3G, and 4G networks in both developed and poor nations. In North America, backhaul for urban cellular operations is typically provided via one or more copper wire line T1 connections, whereas remote cellular operations are sometimes backhauled via satellite. In most other regions, urban and rural backhaul is usually provided by microwave links. (The exception to this is where the network is operated by an incumbent with ready access to the copper network, in which case T1 lines may be used). WiMAX is a broadband platform and as such has much more substantial backhaul bandwidth requirements than legacy cellular applications. Therefore traditional copper wire line backhaul solutions are not appropriate. Consequently the use of wireless microwave backhaul is on the rise in North America and existing microwave backhaul links in all regions are being upgraded. Capacities of between 34 Mbit/s and 1 Gbit/s are routinely being deployed with latencies in the order of 1ms. In many cases, operators are aggregating sites using wireless technology and then presenting traffic on to fiber networks where convenient. Deploying WiMAX in rural areas with limited or no internet backbone will be challenging as additional methods and hardware will be required to procure sufficient bandwidth from the nearest sources — the difficulty being in proportion to the distance between the end-user and the nearest sufficient internet backbone. Technical information WiMAX is a term coined to describe standard, interoperable implementations of IEEE 802.16 wireless networks, similar to the way the term Wi-Fi is used for interoperable implementations of the IEEE 802.11 Wireless LAN standard. However, WiMAX is very different from Wi-Fi in the way it works.

95

Customized Mobile Robot System

MAC layer/data link layer In Wi-Fi the media access controller (MAC) uses contention access — all subscriber stations that wish to pass data through a wireless access point (AP) are competing for the AP's attention on a random interrupt basis. This can cause subscriber stations distant from the AP to be repeatedly interrupted by closer stations, greatly reducing their throughput. In contrast, the 802.16 MAC uses a scheduling algorithm for which the subscriber station needs to compete only once (for initial entry into the network). After that it is allocated an access slot by the base station. The time slot can enlarge and contract, but remains assigned to the subscriber station, which means that other subscribers cannot use it. In addition to being stable under overload and over-subscription the 802.16 scheduling algorithm can also be more bandwidth efficient. The scheduling algorithm also allows the base station to control QoS parameters by balancing the time-slot assignments among the application needs of the subscriber stations. Physical layer The original version of the standard on which WiMAX is based (IEEE 802.16) specified a physical layer operating in the 10 to 66 GHz range. 802.16a, updated in 2004 to 802.16-2004, added specifications for the 2 to 11 GHz range. 802.16-2004 was updated by 802.16e-2005 in 2005 and uses scalable orthogonal frequency-division multiple access (SOFDMA) as opposed to the orthogonal frequency-division multiplexing (OFDM) version with 256 sub-carriers (of which 200 are used) in 802.16d. More advanced versions, including 802.16e, also bring multiple antenna support through MIMO. See: WiMAX MIMO. This brings potential benefits in terms of coverage, self installation, power consumption, frequency re-use and bandwidth efficiency. 802.16e also adds a capability for full mobility support. The WiMAX certification allows vendors with 802.16d products to sell their equipment as WiMAX certified, thus ensuring a level of interoperability with other certified products, as long as they fit the same profile. Most commercial interest is in the 802.16d and 802.16e standards, since the lower frequencies used in these variants suffer less from inherent signal attenuation and therefore give improved range and in-building

96

Customized Mobile Robot System

penetration. Already today, a number of networks throughout the world are in commercial operation using certified WiMAX equipment compliant with the 802.16d standard.

Future development Mobile WiMAX based upon 802.16e-2005 has been accepted as IPOFDMA for inclusion as the sixth wireless link system under IMT-2000. This can hasten acceptance by regulatory authorities and operators for use in cellular spectrum. WiMAX II, 802.16m will be proposed for IMTAdvanced 4G. The goal for the long term evolution of both WiMAX and LTE is to achieve 100 Mbit/s mobile and 1 Gbit/s fixed-nomadic bandwidth as set by ITU for 4G NGMN (Next Generation Mobile Network) systems through the adaptive use of MIMO-AAS and smart, granular network topologies. 3GPP LTE and WiMAX-m are concentrating much effort on MIMO-AAS, mobile multi-hop relay networking and related developments needed to deliver 10X and higher Co-Channel reuses multiples. Since the evolution of core air-link technologies has approached the practical limits imposed by Shannon's Theorem, the evolution of wireless has embarked on pursuit of the 3X to 10X+ greater bandwidth and network efficiency by advances in the spatial and smart wireless broadband networking technologies.

97

Customized Mobile Robot System

5.1.6 General packet radio service (GPRS) GPRS is a packet oriented mobile data service available to users of the 2G cellular communication systems global system for mobile communications (GSM), as well as in the 3G systems. In the 2G systems, GPRS provides data rates of 56-114 kbit/s. GPRS data transfer is typically charged per megabyte of traffic transferred, while data communication via traditional circuit switching is billed per minute of connection time, independent of whether the user actually is using the capacity or is in an idle state. GPRS is a best-effort packet switched service, as opposed to circuit switching, where a certain quality of service (QoS) is guaranteed during the connection for nonmobile users. 2G cellular systems combined with GPRS are often described as 2.5G, that is, a technology between the second (2G) and third (3G) generations of mobile telephony. It provides moderate speed data transfer, by using unused time division multiple access (TDMA) channels in, for example, the GSM system. Originally there was some thought to extend GPRS to cover other standards, but instead those networks are being converted to use the GSM standard, so that GSM is the only kind of network where GPRS is in use. GPRS is integrated into GSM Release 97 and newer releases. It was originally standardized by European Telecommunications Standards Institute (ETSI), but now by the 3rd Generation Partnership Project (3GPP). GPRS was developed as a GSM response to the earlier CDPD and i-mode packet switched cellular technologies. Services GPRS upgrades GSM data services providing:      

Multimedia messaging service (MMS) Short message service (SMS) Push to talk over cellular (PoC/PTT) Instant messaging and presence—wireless village Internet applications for smart devices through wireless application protocol (WAP) Point-to-point (P2P) service: inter-networking with the Internet (IP) 98

Customized Mobile Robot System



Future enhancements: flexibility to add new functions, such as more capacity, more users, new accesses, new protocols, new radio networks.

If SMS over GPRS is used, an SMS transmission speed of about 30 SMS messages per minute may be achieved. This is much faster than using the ordinary SMS over GSM, whose SMS transmission speed is about 6 to 10 SMS messages per minute

Protocols supported GPRS originally supported (in theory) internet protocol (IP), point-topoint protocol (PPP) and X.25 connections. The last has been typically used for applications like wireless payment terminals, although it has been removed from the standard. X.25 can still be supported over PPP, or even over IP, but doing this requires either a router to perform encapsulation or intelligence built in to the end-device/terminal; e.g., user equipment (UE). In practice, the mobile built-in browser uses IPv4. In this mode PPP is often not supported by the mobile phone operator, while IPv6 is not yet popular. But if the mobile is used as a modem to the connected computer, PPP is used to tunnel IP to the phone. This allows an IP address to be assigned dynamically to the mobile equipment. When TCP/IP is used, each phone can have one or more IP addresses allocated. GPRS will store and forward the IP packets to the phone during cell handover (when you move from one cell to another). A radio noise induced pause can be interpreted by TCP as packet loss, and cause a temporary throttling in transmission speed.

99

Customized Mobile Robot System

Hardware Class A Can be connected to GPRS service and GSM service (voice, SMS), using both at the same time. Such devices are known to be available today. Class B Can be connected to GPRS service and GSM service (voice, SMS), but using only one or the other at a given time. During GSM service (voice call or SMS), GPRS service is suspended, and then resumed automatically after the GSM service (voice call or SMS) has concluded. Most GPRS mobile devices are Class B. Class C Are connected to either GPRS service or GSM service (voice, SMS). Must be switched manually between one or the other service. A true Class A device may be required to transmit on two different frequencies at the same time, and thus will need two radios. To get around this expensive requirement, a GPRS mobile may implement the dual transfer mode (DTM) feature. A DTM-capable mobile may use simultaneous voice and packet data, with the network coordinating to ensure that it is not required to transmit on two different frequencies at the same time. Such mobiles are considered pseudo-Class A, sometimes referred to as "simple class A". Some networks are expected to support DTM in 2007. GPRS is technology in which speed is a direct function of the number of TDMA time slots assigned, which is the lesser of (a) what the particular cell supports and (b) the maximum capability of the mobile device expressed as a GPRS multislot class. USB GPRS modems use a terminal-like interface USB 2.0 and later, data formats V.42bis, and RFC 1144 and external antennas. Modems can be added as cards (for laptops) or external USB devices which are similar in shape and size to a computer mouse

100

Customized Mobile Robot System

5.1.7 3GSM, 3.5G, 3.75G and 4G Data rates ITU has not provided a clear definition of the data rate users can expect from 3G equipment or providers. Thus users sold 3G service may not be able to point to a standard and say that the rates it specifies are not being met. While stating in commentary that "it is expected that IMT2000 will provide higher transmission rates: a minimum speed of 2 Mbit/s and maximum of 14.4 Mbit/s for stationary users, and 348 kbit/s in a moving vehicle, the ITU does not actually clearly specify minimum or average rates or what modes of the interfaces qualify as 3G, so various rates are sold as 3G intended to meet customers’ expectations of broadband speed. Security 3G networks offer a greater degree of security than 2G predecessors. By allowing the UE to authenticate the network it is attaching to, the user can be sure the network is the intended one and not an impersonator. 3G networks use the KASUMI block crypto instead of the older A5/1 stream cipher. However, a number of serious weaknesses in the KASUMI cipher have been identified. In addition to the 3G network infrastructure security, end to end security is offered when application frameworks such as IMS are accessed, although this is not strictly a 3G property. Evolution from 2G 2G networks were built mainly for voice data and slow transmission. From 2G to 2.5G The first major step in the evolution to 3G occurred with the introduction of General Packet Radio Service (GPRS). So the cellular services combined with GPRS became' 2.5G.' GPRS could provide data rates from 56 kbit/s up to 114 kbit/s. It can be used for services such as Wireless Application Protocol (WAP) access, Multimedia Messaging Service (MMS), and for Internet communication services such as email and World Wide Web access. GPRS data transfer 101

Customized Mobile Robot System

is typically charged per megabyte of traffic transferred, while data communication via traditional circuit switching is billed per minute of connection time, independent of whether the user actually is utilizing the capacity or is in an idle state. From 2.5G to 2.75G (EDGE) GPRS networks evolved to EDGE networks with the introduction of 8PSK encoding. Enhanced Data rates for GSM Evolution (EDGE), Enhanced GPRS (EGPRS), or IMT Single Carrier (IMT-SC) is a backward-compatible digital mobile phone technology that allows improved data transmission rates, as an extension on top of standard GSM. EDGE can be considered a 3G radio technology and is part of ITU's 3G definition, but is most frequently referred to as 2.75G. EDGE was deployed on GSM networks beginning in 2003—initially by Cingular (now AT&T) in the United States. EDGE is standardized by 3GPP as part of the GSM family, and it is an upgrade that provides a potential three-fold increase in capacity of GSM/GPRS networks. The specification achieves higher data-rates by switching to more sophisticated methods of coding (8PSK), within existing GSM timeslots. EDGE can be used for any packet switch Evolution towards 4G Both 3GPP and 3GPP2 are currently working on further extensions to 3G standards, named Long Term Evolution and Ultra Mobile Broadband, respectively. Being based on an all-IP network infrastructure and using advanced wireless technologies such as MIMO, these specifications already display features characteristic for IMT-Advanced (4G), the successor of 3G. However, falling short of the speed requirements for 4G (which is 1 Gbit/s for stationary and 100 Mbit/s for mobile operation), these standards are classified as 3.9G or Pre-4G. 3GPP plans to meet the 4G goals with LTE Advanced, whereas Qualcomm has halted development of UMB in favour of the LTE family. Issues Although 3G was successfully introduced to users across the world, some issues are debated by 3G providers and users: 

Expensive input fees for the 3G service licenses & agreements 102

Customized Mobile Robot System

 

     

Numerous differences in the licensing terms Large amount of debt currently sustained by many telecommunication companies, which makes it a challenge to build the necessary infrastructure for 3G Lack of member state support for financially troubled operators Expense of 3G phones Lack of buy-in by 2G mobile users for the new 3G wireless services Lack of coverage, because it is still a new service High prices of 3G mobile services in some countries, including Internet access (see flat rate) Current lack of user need for 3G voice and data services in a handheld device

5.2 Berkeley Sockets The following are some general information about Berkeley Sockets: 1. Developed in the early 1980s at the University of California at Berkeley. There are no longer any major alternatives. Other major alternative was TLI (Transport Layer Interface). There are communications tools that are built on tool of Berkeley sockets. (E.g. RPC ) 2. It is an API and Its implementation is usually requires kernel code 3. It is the defacto standard for communications programming. 4. There are higher level tools for programs that span more than one machine. RPC, DCOM and windows remoting are examples. 6. Used for point-to-point communications between computers through an inter-systems pipe. Namely can use the UNIX read, write, close, select, etc. system calls. 7. Supports broadcast. This is where the same message may be delivered to multiple systems on a network without additional overhead. 8. Available on every UNIX system that I know of and somewhat available in WIN32.

103

Customized Mobile Robot System

9. Build for client/server development. That is having one system provide a service to other systems. Berkeley sockets support two types of communications. These sit on top of the TCP Internet datagrams. TCP - connection oriented, stream, reliable. UDP - connectionless, record oriented, unreliable. Question: Why would anyone use a form of communication that is not reliable? Answer: Speed. Answer: Ability to broadcast. Why choose Berkeley sockets? The Berkeley sockets API is widely supported on a large number of languages on various programming environments, with minimum changes in the interface. Even though higher level communication interfaces that may help reduce development time are provided in .Net class libraries or JAVA, they are only specific to .NET or JAVA. Moreover, use of Berkeley sockets allows greater portability of code with minimum changes and therefore doesn’t depend on a specific operating system or support from other programs like the JVM or the .Net framework. Such portability gives greater flexibility in the choice of hardware (because of reduced requirements in minimum performance), operating system and language which allows us to better meet the specific needs and preferences of future customers. Lastly, the group has the skills and experiences base in using the sockets interface in C that eliminated any learning curve associated with other communications interfaces and in turn reduced the development time. Programming Aspects of Berkeley Sockets Uses the TCP/IP protocol.

104

Customized Mobile Robot System

What are sockets? They represent end points for communications. In the UNIX world, they are file descriptors. Thus we can use system calls like read and write to receive and send data. In order to communicate with a program on another computer, we have to identify the computer and specify the program. We specify the computer by giving its IP address. The program that we want to communicate with is identified by a port number. The port number is a positive integer that is advertised by the program that is waiting for a connection. More on this later. The following are the major system calls supplied by Berkeley sockets and UNIX to perform TCP communications. There are other calls that we will use and calls to support UDP. These will be presented later. 1. Socket - creates a socket for network communications. Returns a file descriptor for the socket. 2. Connect - called by the client process to establish a connection between it and a server process. Need the server’s address and port number. The file descriptor from the socket call is one of the arguments. Once the connection is made, this file descriptor may be used for communications. 3. Write - to send data on the connection. If connection broken your program will receive a SIGPIPE signal or an error is returned. (The SIGPIPE signal does not occur immediately. What is the implication of this?) 4. Read - to get data that was sent on the connection. It returns the number of bytes read. 0 is returned if the connection broken. (NOTE: WIN32 gives an error return.). 5. Close - to de-allocate the socket. 6. Bind - used by server process to associate an end-point address with a socket. Must include the port and server address with this

105

Customized Mobile Robot System

call. This is like advertising the service. This socket is called the listening socket. Note: there are some port numbers that are referred to as well-known ports. See /etc/services for a list. A good habit is to always select port numbers that are greater than 7000.

7. Listen - used by server process to indicate that it is ready to receive connections. The listening socket must be specified in this call. Another parameter is the queue length for those. Parameter values are not always guaranteed to be used. At one time, regardless of the value of this parameter SUN uses 5. Note that the select system call will consider a listening socket with a connection waiting to be ready to read. 8. Accept - called by the server process to accept a connection. If no client is trying to connect the call will block. 9. Select - used to determine if there is data available on a socket or if there is a client queued up for a connection to a server. Can also be used to determine if a write is possible. 10. Gethostbyaddr-used to perform a DNS lookup on a given IP address. 11. getpeername-used to getportnumber and IP address of the remote host that the socket is connected to Use of socket calls in a program Client: Socket  connect  write  read  close ^ | |______| Server: Socket  bind  listen  accept  read  write  close

106

Customized Mobile Robot System

^ ^ | | |_______|______|______|

107

Customized Mobile Robot System

Chapter 6: Simulation & Demonstration To show the functionality of our project, we customized the software for teleoperation of the iRobot Create, and showed that control of the robot was possible while receiving accurate data over the network. During our demonstration we were able to verify the following for our prototype

Table 6.1: Demonstration verification All the prototype specifications listed in section 2 were successfully met. Feedback from webcam, GPS and sonar showed that we are capable of integrating various other components at the client’s request. The webcam was connected through a USB port, and the GPS sensor was connected through a serial port, and since some of our client’s components might use either port, we have showed that our software can implement hardware successfully through USB or serial port.

108

Customized Mobile Robot System

Simulation System was successfully simulated on 2 computers. Simulation was performed by the Microsoft Robotics Developer Studio “MRDS” 2008 Standard Edition with update R2 – Visual Simulation Environment. The Microsoft Robotics Developer Studio (Microsoft RDS, MRDS) is a Windows-based environment for robot control and simulation. It is aimed at academic, hobbyist, and commercial developers and handles a wide variety of robot hardware. RDS is based on CCR (Concurrency and Coordination Runtime), a .NETbased concurrent library implementation, for managing asynchronous, parallel tasks using message-passing and DSS (Decentralized Software Services), a lightweight services-oriented runtime, which allows the orchestration of multiple services to achieve complex behaviors. Features include: a visual programming tool, Microsoft Visual Programming Language, for creating and debugging robot applications, web-based and windows-based interfaces, 3D simulation (including hardware acceleration), easy access to a robot's sensors and actuators and support for a number of languages including C# and Visual Basic .NET, JScript, and IronPython. Microsoft Robotics Developer Studio includes support for packages to add other services to the suite. Those currently available include Soccer Simulation and Sumo Competition by Microsoft, and a communitydeveloped Maze Simulator, a program to create worlds with walls that can be explored by a virtual robot. Components There are four main components in RDS:    

CCR (Concurrency and Coordination Runtime) DSS (Decentralized Software Services) VPL (Visual Programming Language) VSE (Visual Simulation Environment)

109

Customized Mobile Robot System

CCR and DSS are also available separately for use in commercial applications that require a high level of concurrency and/or must be distributed across multiple nodes in a network. Tools The tools that allow to develop a MRDS application contain a graphical environment (Microsoft Visual Programming Language : VPL), command line tools allow to deal with Visual Studio projects (VS Express version is enough) in C#, C++ or VB.NET), support for script languages such as IronPython and 3D simulation tools. 

Visual Programming Language is a graphical development environment that allow a service and activity catalog. o They can interact graphically; a service or an activity is represented by a block that has inputs and outputs that just need to be dragged from the catalog to the diagram. o Linking can be done with the mouse, it allows to define if signals are simultaneous or not, permits to perform operations on transmitted values... o VPL also allow generating the code of new "macro" services from diagrams created by users. o It is possible in VPL to easily customize services for different hardware elements.



MRDS 3D simulation environment allows to simulate the behavior of robots in a virtual world using NVIDIA PhysX technology (3D engine) that includes advanced physics.



There are 3 small simulation environments in the standard and academic edition of MRDS, these environments are limited versions of the larger generic simulation environments developed by SimplySim o Apartment (also available in the express edition) o Outdoor o Urban

MRDS supports the iRobotCreate entity, hence it’s a perfect choice for simulation to provide rapid development of simulation procedure.

110

Customized Mobile Robot System

Simulation Scenario The Simulation Environment is composed of the following components: 







The Simulation Engine Service - is responsible for rendering entities and progressing the simulation time for the physics engine. It tracks of the entire simulation world state and provides the service/distributed front end to the simulation. The Managed Physics Engine Wrapper - abstracts the user from the low level physics engine API, provides a more concise, managed interface to the physics simulation. The AGEIA™ PhysX™ Technology - enables hardware acceleration through the AGEIA™ PhysX™ processor (Available in PhysX™ Accelerator add-in cards for PCs). Entities - represent hardware and physical objects in the simulation world. A number of entities come predefined with the RDS and enable users to quickly assemble them and build rich simulated robot platforms in various virtual environments.

You can choose to interact only with the managed physics engine API if you don't want any visualization. However, it is strongly recommended that you always use the simulation engine service and define custom entities that disable rendering. This greatly simplifies persistence of state, inspection and debugging of simulation code. The rendering engine uses the programmable pipeline of graphics accelerator cards, conforming to Directx9 Pixel/Vertex Shader standards. Running project goes from the DSS Command Prompt using the following command: bin\dsshost32 /port: 50000 /manifest:"samples\config\SimulationTutorial2.manifest.xml" By default, Visual Studio is configured to start each sample automatically. Step 1: Load Required References  

SimulatedBumper.Y2006.M05.Proxy SimulatedDifferentialDrive.2006.M06.Proxy 111

Customized Mobile Robot System

 

SimulatedLRF.Y2006.M05.Proxy SimulatedWebcam.Y2006.M09.Proxy

To satisfy the requirements, the following additional using statements have been added. Service Start Step 2: Define an Environment Entity with Multiple Shapes The TableEntity class derives from MultiShapetEntity and specifies a collection of box shapes to define a table. The entity definition is at the bottom of SimulationTutorial2.cs: Some things to pay particular attention to when defining your own entity: 



Use a custom constructor to specify the physical parameters and shapes. If you capture the simulation state and load from a state file, the default constructor will be invoked and it will re-create the same exact entity using the serialized values. Derive from one of the existing entities if you don't need complex behavior. MultiShapeEntity supports objects that are composed of lists of boxes or spheres. At the end of the constructor, you'll notice that shapes are added to the BoxShapes list, defined in the base class. The base class now takes care of initialization, frame updates and rendering.

Step 3: Create a Modular Robot Entity and Simulated Hardware Services

The Simulation Environment comes with a few pre-defined entities that model wheeled robots with a differential drive and support children entities for a few optional sensors. The simulation starts two robots, but we will only describe one here since the other is similar. The following method creates an instance of the MobileRobots iRobotCreate entity, which trivially extends the DifferentialDriveEntity. The modular simulated robot is created in three stages: 112

Customized Mobile Robot System

1. Create the motor base with the differential drive. Note that the platform specific entity is nothing more than a derivation of the DifferentialDriveEntity with a custom constructor that set the physical dimensions for the physics shapes. No other code is custom between the two. 2. Create the LaserRangeFinderEntity and instantiate a simulated laser range finder service that will use it as its virtual hardware. 3. Create the BumperArrayEntity with two bumpers and instantiate the simulated bumper service. 4. Create the CameraEntity and instantiate a simulated webcam service that uses alternate render targets to capture real time rendering of the scene from the simulation. After the laser, bumper, and camera are created it’s noticeable that they are inserted as children to the motor base entity: The simulation engine plus the VisualEntity base class take care of initializing and properly updating and rendering the child entities each frame. The following steps explain each entity creation method in more detail. Differential Drive Entity The parent entity is a differential drive motor base with the physics shape dimensions of the iRobotCreate. Pay close attention to the name of the entity. This is how a simulation service finds the entity it needs to run. The CreateEntityPartner method creates a service partner that lets the service know what entity it needs to bind to at runtime. Laser Range Finder Entity The following code snippet shows you how to create the laser entity and start its associated service. Again, pay close attention to the entity name and make sure that name matches the partner name. One interesting thing about this sensor entity is that it must be placed on top of the motor base (using the relative pose). For modular robots, sensors and additional hardware must be specified in terms of the parent entity and in a loosely coupled manner.

113

Customized Mobile Robot System

Bumper Array Entity This section shows you how to build a bumper array entity using just two shapes placed in front of and behind the motor base. The Pioneer mesh used actually shows 10 bumpers total, but they are approximated by using just two. Again, note the relative pose for the bumper shapes. The bumper array entity uses contact notifications from the physics engine to report collisions with other shapes in the physics simulation. A shape can only report collisions if the following field is set to true

Camera Entity This section shows you how to add a realtime camera in the simulation that captures the scene from the perspective of a camera entity. The camera is mounted on the motor base (it's added as a child of the DifferentialDrive entity), so it moves when the robot moves. It simulates a USB or wireless webcam attached to a mobile robot, proving a very common and useful simulated sensor that can be utilized for vision processing and other tasks. The simulation engine now supports multiple instances of the new CameraEntity, which can operate in two modes: 1. Realtime Mode - The CameraEntity can render the entire scene from its perspective concurrently with any other camera (including the default user camera). This mode is useful for modeling a webcam sensor. Realtime cameras have a high rendering cost since they essentially duplicate all rendering of the scene. 2. Non-Realtime Mode - The CameraEntity renders only when it's selected as the active camera in the simulation, allowing the simulation UI to render the scene from multiple perspectives, in sequence. It does not have an added performance cost if it's used as the only rendering target.

114

Customized Mobile Robot System

Step 4: Simulation Services and Entity Partnerships Partnering with Services with the Entity that simulates the hardware It's very important to note the creation of a simulation service that partners with the simulation entity and will emulate a differential drive in the above methods. The entity name is important since this is how the simulated service finds the entity during its startup. The entity name is supplied as a partner since this is similar to how we would specify configuration to a hardware-specific service for the real differential drive service. The CreateService method below instructs the runtime to create an instance of a service of a given contract, supplying a partner element as part of its service information. The implementation of SimulatedDifferentialDrive service shows more details on how simulated services find and use entity partners. Code below is from the method CreateMotorBase described in an earlier section.

Simulation Service Design Pattern Simulation services should all follow particular startup patterns to make them robust to the asynchronous nature of the entity creation process. Because entities might be inserted in the simulation after the service has started, services should be careful to not allow DSSP operation processing until the entity notification has been received. The key code segments for proper initialization: 1. First activate a simple interleave that waits once for either a Drop operation or the entity notification. Notice the InsertEntityNotificationHandlerFirstTime handler is registered only once. 2. In the notification handler that runs just once, we call the normal notification handler that caches the entity instance and configures service state. 3. The base class Start method is called so the service activates its operation handlers and inserts to the directory.

115

Customized Mobile Robot System

4. To guard operations against concurrent delete/insert of entities, we combine the main port interleave with a simple interleave that receives entity notifications. Step 5: Run the Simulation Compile and run the simulation using the steps described in the Getting Started section of this simulation. You should see the visualization window open with a table and wheeled robot next to it. You may notice blinking red circles appear on the side of the table, seemingly floating in space. This is custom visualization of the laser impact points on the physics shape for the table. Since the physics view of the table has solid sides, the laser range finder sees a solid block. Using the "simple dashboard" sample service, you can connect to the simulation node and connect to the simulated range finder to see what it "sees". The simple dashboard service is part of the simulation manifest, so you don't need to start a separate node. Once the dashboard window opens, do the following: 1. Enter the machine name and TCP port number of the simulation node. As a shortcut, you can just type local host with no port specified. 2. Click the Connect button in the Remote Node area. Two services should appear in the Service Directory window. 3. Click the Connect button in the Laser Range Finder area. You can also drive the robot by using the Simple Dashboard UI. 1. Double-click the URI for the simulated differential drive. You should see the Motor field say On the Winform. Make sure the Motor field turns on. (It might take two clicks.) 2. Click the Drive button in the DirectInput device area of the UI, or press the main joystick button (if you have a joystick attached). Then use the UI to drive (by dragging on the sphere above the stop button) or use the joystick with the primary button pressed to move forward.

116

Customized Mobile Robot System

117

Customized Mobile Robot System

118

Customized Mobile Robot System

Chapter 7: Conclusions Our goal is to develop software to enable teleoperation of a robot, and as prototype we customized this software for the iRobot Create. The most important objective was to enable control of hardware over a wireless network so that teleoperation is possible, and then enable integration of different hardware to make customization easy and make our service attractive to customers. These objectives were met successfully, and shown through our demonstration. For further improvements, a rotating webcam would have been better so that obstacles can be avoided when moving the robot backwards. Also, a joystick control would provide an easier control device for a user, and also allow diagonal movement of the robot. To have a better prototype it would have been ideal if a robot more suited for terrain exploration was used, instead of iRobot Create. As we customize our software, we might see a trend of a specific function requested by our clients, and it would be efficient for our business to integrate that into our software to lower customization time.

119

Customized Mobile Robot System

References 1. Z. Dehaui, X. Cunxi, L. Xuemei. “Design and Implementation of a Security and Patrol Robot System,” in Proc. IEEE International Conference on Mechatronics and Automation, 2005, pp 1745-49. 2. D. López de Ipiña, I. Vázquez, J. Ruiz de Garibay, D. Sainz. “GPRS-based RealTime Remote Control of MicroBots with M2M Capabilities,” in Proc. IEEE Computational Intelligence in Robotics and Automation, 2005, pp.145-150. 3. “iRobot® Government and Industrial Robots,” *Online Document], 2007, [cited 2007 Sep 14], http://www.irobot.com/sp.cfm?pageid=109 4. Microsoft renames Windows CE, sets CE 6.0 launch date 5. Windows Embedded Homepage 6. "The Meaning of "CE" in Windows CE". Q166915. Microsoft. 2002-09-03. http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q166915. Retrieved on 2006-09-15. 7. a b c Talk:Microsoft Windows CE#Is Windows CE a trimmed down version of desktop Windows ??? 090517 8. "Pen Computing Magazine: Windows CE .net". http://www.pencomputing.com/WinCE/dotnet.html. 090517 pencomputing.com 9. a b c "MS readies WinCE 5.0 preview". http://www.theregister.co.uk/2004/03/29/ms_readies_wince/. 090517 theregister.co.uk 10. "The History of the PDA". http://seditaville.com/academic/summary/The%20History%20of%20Microso ft%20Mobile%20OS(Ver%202).doc. 090517 seditaville.com 11. "Introduction to Microsoft embedded technologies - Session 1". http://www.embedded.net.nz/Presentations%20PPT%20%20PDF/Embedded %20Introduction%20-%20Session%201.ppt. 090517 embedded.net.nz 12. "Differences between Windows CE 5.0 and Windows CE 6.0". http://www.windowsfordevices.com/articles/AT9457847627.html. 090517 windowsfordevices.com 13. Apple (2002-07-17). Apple Introduces "Jaguar," the Next Major Release of Mac OS X. Press release. http://www.apple.com/pr/library/2002/jul/17jaguar.html. Retrieved on 2008-02-04. 14. "HTC TyTN Specification" (PDF). HTC. http://www.europe.htc.com/z/pdf/products/1766_TyTN_LFLT_OUT.PDF. Retrieved on 2008-02-04. 15. (PDF) Simple Pairing Whitepaper. Version V10r00. Bluetooth SIG. 2006-0803. http://bluetooth.com/NR/rdonlyres/0A0B3F36-D15F-4470-85A6F2CCFA26F70F/0/SimplePairing_WP_V10r00.pdf. Retrieved on 2007-02-01. 16. Michael Oryl (2007-03-15). "Bluetooth 2.1 Offers Touch Based Pairing, Reduced Power Consumption". MobileBurn. http://www.mobileburn.com/news.jsp?Id=3213. Retrieved on 2008-02-04.

120

Customized Mobile Robot System

17. Taoufik Ghanname (2007-02-14). "How NFC can to speed Bluetooth transactions-today". Wireless Net DesignLine. http://www.wirelessnetdesignline.com/howto/showArticle.jhtml?articleID=1 80201430. Retrieved on 2008-02-04. 18. David Meyer (2009-04-22). "Bluetooth 3.0 released without ultrawideband". zdnet.co.uk. http://news.zdnet.co.uk/communications/0,1000000085,39643174,00.htm. Retrieved on 2009-04-22. 19. "BlueBug". Trifinite.org. http://trifinite.org/trifinite_stuff_bluebug.html. Retrieved on 2007-02-01. 20. John Oates (2004-06-15). "Virus attacks mobiles via Bluetooth". The Register. http://www.theregister.co.uk/2004/06/15/symbian_virus/. Retrieved on 2007-02-01. 21. "Long Distance Snarf". Trifinite.org. http://trifinite.org/trifinite_stuff_lds.html. Retrieved on 2007-02-01. 22. a b "IR Astronomy: Overview". NASA Infrared Astronomy and Processing Center. http://www.ipac.caltech.edu/Outreach/Edu/importance.html. Retrieved on 2006-10-30. 23. Dr. S. C. Liew. "Electromagnetic Waves". Centre for Remote Imaging, Sensing and Processing. http://www.crisp.nus.edu.sg/~research/tutorial/em.htm. Retrieved on 2006-10-27. 24. a b c "How Night Vision Works". American Technologies Network Corporation. http://www.atncorp.com/HowNightVisionWorks. Retrieved on 2007-08-12. 25. V. Gorbunov; N. Fuchigami; M. Stone; M. Grace; V. V. Tsukruk (2002). "Biological Thermal Detection: Micromechanical and Microthermal Properties of Biological Infrared Receptors". Biomacromolecules 3 (1): 106–115. doi:10.1021/bm015591f. 26. "Clouds & Radiation". http://earthobservatory.nasa.gov/Library/Clouds/. Retrieved on 2007-08-12. 27. "Wi-Fi". http://www.webopedia.com/TERM/W/Wi_Fi.html. 28. "Basic Facts About Wi-Fi and its Advancement". http://www.techpluto.com/wifi-info/. 29. "Authorization of Spread Spectrum Systems Under Parts 15 and 90 of the FCC Rules and Regulations" (TXT). Federal Communications Commission. June 18, 1985. http://www.marcus-spectrum.com/documents/81413RO.txt. Retrieved on 2007-08-31. 30. "Wireless Fidelity' Debunked". Wi-Fi Planet. http://www.wifiplanet.com/columns/article.php/3674591. Retrieved on 2007-08-31.

121

Customized Mobile Robot System

Appendices Attached a list of datasheets of hardware used listed by order of appearance in this section.       

iRobot Create Programmable Robot Datasheet eBox 4300 Datasheet Phidgets Interface Kit with Text LCD Datasheet Phidgets Sonar Sensor Datasheet Phidgets GPS Receiver Datasheet Texas Instruments “TI” MAX232 Datasheet Texas Instruments “TI” PTN78020H Power Regulator Datasheet

122