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
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
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
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
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
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
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
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 packet-
switching 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
 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
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
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
Figure 1.2 – Top level system diagram
Figure 2.3 – Hardware connectivity
12
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
Figure 2.4 – The eBox Interface
The iRobot Create
14
Figure 2.5 – Hardware Assembly
15
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
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
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 real-
time needs.
18
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
 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
 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
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
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
Figure 3.1: Overall Structure for ControlTheRobot
24
Code Files Used
Code File Description
These two files set the foundation for

AbstractCommandFactory.h/.cpp the well known design pattern:
Command Factory
A concrete implementation of the

IRobotCommandFactory.cpp AbstractCommandFactory for the
iCreate Robot
Data structure to hold the incoming

Buffer.cpp command message from the
RemoteController
Makes use of the command factory

CommandExecuter.cpp design pattern
A sample implementation of the

CommandImpl.cpp EC_Command abstract command.
Class to encapsulate the network

connection.cpp connection
Class to handle instatiation of

ConnectionManager.cpp Connection their termination
ConnectionSocket.cpp Light wrapper around windows

SOCKET
25
Abstract command
EC_Command.cpp
Provides the iCreate Robot On Interface

OpenInterface.cpp commands from a cleaner contained
namespace
Includes _tWinMain, the message loop,

Excutive.cpp
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()
ControlTheRobot::BatteryTemperatureSensorCmd
+BatteryTemperatureSensorCmd()
+~BatteryTemperatureSensorCmd()
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
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
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()
ControlTheRobot::CoverCmd
+CoverCmd()
+~CoverCmd()
ControlTheRobot::CurrentSensorCmd
+CurrentSensorCmd()
+~CurrentSensorCmd()
28
ControlTheRobot::DriveCmd
+DriveCmd()
+~DriveCmd()
ControlTheRobot::DriveDirectCmd
+DriveDirectCmd()
+~DriveDirectCmd()
ControlTheRobot::EC_AbstractCommand
#m_Parameters : char *
#m_ParamBufferLength : unsigned int
+EC_AbstractCommand()
+~EC_AbstractCommand()
+SetParameters(in paramLength : unsigned int, in params : char*)
ControlTheRobot::EnterFullModeCmd
+EnterFullModeCmd()
+~EnterFullModeCmd()
ControlTheRobot::EnterSafeModeCmd
+EnterSafeModeCmd()
+~EnterSafeModeCmd()
ControlTheRobot::LowSideDriversCmd
+LowSideDriversCmd()
+~LowSideDriversCmd()
ControlTheRobot::SendIRCmd
+SendIRCmd()
+~SendIRCmd()
ControlTheRobot::SensorsCmd
+SensorsCmd()
+~SensorsCmd()
29
ControlTheRobot::StartCmd
+StartCmd()
+~StartCmd()
ControlTheRobot::StopCmd
+StopCmd()
+~StopCmd()
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
«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)
+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
ControlTheRobot::VoltageSensorCmd
+VoltageSensorCmd()
+~VoltageSensorCmd()
ControlTheRobot::WaitAngleCmd
+WaitAngleCmd()
+~WaitAngleCmd()
ControlTheRobot::WaitDistanceCmd
+WaitDistanceCmd()
+~WaitDistanceCmd()
ControlTheRobot::WaitEventCmd
+WaitEventCmd()
+~WaitEventCmd()
ControlTheRobot::WaitTimeCmd
+WaitTimeCmd()
+~WaitTimeCmd()
ControlTheRobot::WallSignalSensorCmd
+WallSignalSensorCmd()
+~WallSignalSensorCmd()
32
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
PhidgetFunctionPointers.cpp Initialize Phidgets and instantiate
the API pointers from the DLL
using
stdafx.cpp The usual windows include file to
be precompiled
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
33
3.5.2.3 VideoSender
Make usage of the camera device

driver written by Doug Boling, with
CameraCode.cpp
one convenience function added
by the team
Makes a BMP from a MJPEG
mjpeg2bmp.cpp stream
Implements tWinMain, the
message loop, as well as grabbing
VideoSender.cpp
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
Sensors.cpp
sensor data and sending it to the
RemoteController
Initialize Phidgets and instantiate
PhidgetFunctionPointers.cpp the API pointers from the DLL
using GetProcAddress()
Socklib.cpp Networking functions
Table 2.4: List of code files used for the Sensors process
34
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
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
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
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 Description

Implements the required main() function, initiates the
main.cpp
QApplication and the MainWindow objects
Offers a dialog box to the user to choose a robot address
ConnectionDialog.cpp
from a list, or to enter an IP address
EyeCreateRobot.cpp Encapsulate the iCreate Robot functionality in a class
The thread that handles opening the socket and waiting
GPSDataThread.cpp
for GPS data
GPSSentences.cpp Class to extract information from the NMEA phrases
gpsview.cpp A QFrame derived class that displays the GPS path
ImageView.cpp A QFrame derived class that displays the video feedback
The top level Frame that owns all the views, menus and
MainWindow.cpp
controls
A QFrame derived class to display any raw data as a
plotview.cpp
curve
SensorsView A specialized view to render the sensor's data
The thread that handles opening the socket and waiting
SensorsDataThread.cpp
for the sensor data
VideoFrameThread.cpp 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
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 <QApplication>
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 <QPushButton>
39
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()
QDebug
40
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 <QDebug>
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 <QTimer>
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 <qlayout.h>
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
in a Z-order. A widget is clipped by its parent and by the widgets in front

of it.
Code Block
#include <QWidget>
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
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
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
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
Preview
4.5.4 ConnectionDialog.ui
Description
This window allows connection to robot through a given IP.
46
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*)
QObject
The QObject class is the base class of all Qt objects.
Code Block
47
#include <QObject>
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
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*)
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
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
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
QThread
The QThread class provides platform-independent threads.
Code Block
#include <QThread>
QString
Code Block
#include <QString>
QTcpSocket
The QTcpSocket class provides a TCP socket.
Code Block
#include <QTcpSocket>
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
#include <QDataStream>
QMutexLocker
The QMutexLocker class is a convenience class that simplifies locking

and unlocking mutexes.
Code Block
#include <QMutexLocker>
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()
QtGUI
The QtGui module extends QtCore with GUI functionality
53
Code Block
#include <QtGui>
QString
Code Block
#include <QString>
QWidget
Code Block
#include <QWidget>
QFrame
Code Block
#include <QFrame>
QLabel
The QLabel widget provides a text or image display
Code Block
#include <QLabel>
54
QPallette
The QPalette class contains color groups for each widget state
Code Block
#include <QPalette>
QSizePolicy
The QSizePolicy class is layouts attribute describing horizontal and
vertical resizing policy.
Code Block
#include <QSizePolicy>
QGraphicsView
The QGraphicsView class provides a widget for displaying the contents of
a QGraphicsScene.
Code Block
#include <QGraphicsView>
QPainter
paint devices.
Code Block
#include <QPainter>
QGridLayout
The QGridLayout class lays out widgets in a grid
Code Block
#include <QGridLayout>
55
QAbstractSocket
The QAbstractSocket class provides the base functionality common to all
socket types.
Code Block
#include <QAbsrtactSocket>
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 <QMessageBox>
QPixmap
The QPixmap class is an off-screen image representation that can be
used as a paint device.
Code Block
#include <QPixmap>
4.5.10 GPSSentences.cpp
Description
Class to extract information from the NMEA phrases
56
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()
QStringList
The QStringList class provides a list of string.
Code Block
#include <QStringList>
QString
Code Block
#include <QString>
57
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)
+disconnect()
+setParent(in parent : MainWindow*)
+paintEvent(in event : QPaintEvent*)
-setResetButtonEnabled()
-setupMatrix()
-toggleAntialiasing()
-zoomIn()
-zoomOut()
-ConnectionEstablished()
-populateScene()
-clearScene()
QWidget
Code Block
#include <QWidget>
QFrame
58
Code Block
#include <QFrame>
QLabel
The QLabel widget provides a text or image display
Code Block
#include <QLabel>
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 <QGraphicsView>
QPainter
paint devices.
Code Block
#include <QPainter>
QFile
The QFile class provides an interface for reading from and writing to
files.
Code Block
59
#include <QFile>
QAbstractSocket
The QAbstractSocket class provides the base functionality common to all
socket types.
Code Block
#include <QAbsrtactSocket>
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 <QMessageBox>
QPixmap
The QPixmap class is an off-screen image representation that can be
used as a paint device.
Code Block
#include <QPixmap>
4.5.12 GPSDataThread.cpp
Description
The thread that handles opening the socket and waiting for GPS data
60
UML
GPSDataThread
-m_parent : GPSView *
-hostName : QString
-port : quint16
-mutex : QMutex
-m_GPSData : char *
-connected : bool
+GPSDataThread(in parent : GPSView* = 0)
+~GPSDataThread()
+stop()
+startAcquiringGPSData(in hostName : const QString &, in port : quint16)
+run()
+quitRunning()
+wakeUpAndWork()
QtNetwork
The QtNetwork module offers classes that allow you to write TCP/IP
clients and servers
Code Block
QT += network
#include <QtNetwork>
QFrame
Code Block
#include <QFrame>
QThread
61
Code Block
#include <QThread>
QMutexLocker

Code Block
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 <QTcpSocket>
QDataStream

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
#include <QDataStream>
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
QWidget
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 <QWidget>
63
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 <QDialog>
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 <QComboBox>
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
#include <QString>
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 <QLineEdit>
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 <QHostAddress>
65
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)
+disconnect()
+shiftDown(in rect : QRect &, in offset : int)
+drawContents(in p : QPainter*)
+paintEvent(in Parameter1 : QPaintEvent*)
Classes and libraries used
QWidget
66
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 <Qwidget>
QFrame
Code Block
QFrame(parent)
Qt Gui Module
QColor
The QColor class provides colors based on RGB, HSV or CMYK values
Code Block
#include <Qcolor>
QRect
The QRect class defines a rectangle in the plane using integer precision.
Code Block
#include <Qrect>
67
QPaintEvent
The QPaintEvent class contains event parameters for paint events.
Code Block
#include <Qpaintevent>
QBrush Class
The QBrush class defines the fill pattern of shapes drawn by QPainter
Code Block
#include <QBrush>
QPainter

paint devices.
Code Block
#include <Qpainter>
QPaintEngine
The QPaintEngine class provides an abstract definition of how QPainter

draws to a given device on a given platform.
Code Block
#include <QpaintEngine>
QFont
68
The QFont class specifies a font used for drawing text
Code Block
#include <QFont>
QThread
Code Block
#include <QThread>
4.5.15 SensorsDataThread.cpp
Description
The thread that handles opening the socket and waiting for the sensor
data
QtNetwork Library
The QtNetwork module offers classes that allow you to write TCP/IP
clients and servers.
Code Block
#include <QtNetwork>
QThread
The QThread class provides platform-independent thread.
69
Code Block
#include <QThread>
QMutexLocker

Code Block
QTcpSocket Class
The QTcpSocket class provides a TCP socket
QDataStream

aQIODevice.
Code Block
#include<Qdatastream>
70
UML
SensorsDataThread
-m_parent : SensorsView *
-hostName : QString
-port : quint16
-mutex : QMutex
-m_SensorsData : char *
-connected : bool
+SensorsDataThread(in parent : SensorsView* = 0)
+~SensorsDataThread()
+stop()
+startAcquiringGPSData(in hostName : const QString &, in port : quint16)
+run()
+quitRunning()
+wakeUpAndWork()
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
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
 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
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
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.
Maximum Permitted Power Range

Class
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
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
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
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
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
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
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
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
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
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 data-
link 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
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
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
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
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
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
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
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
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
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 professionally-
installed 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
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
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
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
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 IP-

OFDMA 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 IMT-
Advanced 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
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 non-
mobile 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
 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-to-

point 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
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
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 IMT-
2000 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
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
 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 hand-
held 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
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
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
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
^ ^ | |
|_______|______|______|
107
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
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 .NET-

based 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 community-
developed 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
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
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
 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
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
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
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
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
117
118
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
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 Real-
Time 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.
15. (PDF) Simple Pairing Whitepaper. Version V10r00. Bluetooth SIG. 2006-08-
03. http://bluetooth.com/NR/rdonlyres/0A0B3F36-D15F-4470-85A6-
F2CCFA26F70F/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
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.
19. "BlueBug". Trifinite.org. http://trifinite.org/trifinite_stuff_bluebug.html.

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.
23. Dr. S. C. Liew. "Electromagnetic Waves". Centre for Remote Imaging, Sensing
and Processing. http://www.crisp.nus.edu.sg/~research/tutorial/em.htm.
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/.
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.
30. "Wireless Fidelity' Debunked". Wi-Fi Planet. http://www.wi-

fiplanet.com/columns/article.php/3674591. Retrieved on 2007-08-31.
121
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

Graduation Project: Roverbot - Thesis

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Graduation Project: Roverbot - Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

Customized Mobile Robot System

The objective of this project is to create and test a prototype of a

The achieved system may be used in different fields such as military

Figure 1 (Description of the project)

Figure 2 (Description of the project in details)

Supported interfaces Serial, USB, Ethernet

Transport Layer TCP/UDP

Transmitted Data Specifications

Minimum video frame quality 256*192 pixels

Minimum video frame rate 10 fames/s

Minimum remote controllability Forward, backward and rotational

Table 1.1 – Initial specification for the project

Since the on time delivery of a packet within a maximum delay is not a

The embedded computer that used (e-Box) provided sufficient

Finally, the design enables scalability as described in section of the

and software environment (Linux running on gumstix.) And as already

Embedded computer specifications

Interfaces Rs232 serial, USB,802.11a/b/g

Communication Network with multiple or large coverage

Webcam Must provide at least 10 frames per

GPS Must support a serial or USB interface

Degrees of freedom Forward , backward and rotation

Table 1.2 – Initial specification for the test platform

Table 1.3 – Hardware specification

The proposed software framework consists mainly of two applications,

A wide range of readymade robot applications are available in the

Modularity allows reasonable software design that makes the software

Although companies like iRobot and Foster Miller robotics provide a

Another important factor in the design of mobile robots includes reliable

The product features are listed below.

 Software is easily adaptable for modifications

 Video feedback from robot

The prototype provides control of the iRobot Create over a wireless

Part3 describes “Networking”. The wireless networks are described

Finally the thesis is concluded in chapter 7. Then the used references

Chapter 2: Robot Hardware

2.2 The Robot Hardware

Two problems were detected during the analysis of hardware

The peripherals connected to the eBox include a Phidgets board and

The dataflow between hardware is shown in figure (2.1)

Figure 2.1 – Hardware Dataflow

Top level system diagram

Figure 1.2 – Top level system diagram

Figure 2.3 – Hardware connectivity

2.3 Codes and Standards

2.4 Constraints, alternatives, and tradeoffs

The Create robot from i-Robot was chosen because it is

The e-Box was chosen as the embedded computer on the robot, as it

An embedded computer like the e-Box has limited memory and

Figure 2.4 – The eBox Interface

The iRobot Create

Figure 2.5 – Hardware Assembly

Figure 2.6 – The REHI Circuit

Chapter 3: Robot Embedded Software

3.1.1 Real Time Embedded Systems with Windows CE

An embedded system is a computer device programmed to carry

3.1.1.2 Commercial Applications

Advances in technology have made embedded systems

Some systems require a real-time response. For example an electric

increase human safety in space exploration vehicles or to ensure

3.1.1.3 Underlying Technology

A high number of automation applications of robotics and

The many optimized features of CE include a unified kernel is capable of