graduation project: roverbot - thesis

Customized Mobile Robot System

Chapter 1: IntroductionMobile 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 clients 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 clients 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 DescriptionSoftware Requirements OS Windows CE compatible Hardware Requirements Supported interfaces Serial, USB, Ethernet

Communication Specifications Network layer Transport Layer IP TCP/UDP Transmitted Data SpecificationsMinimum video frame quality Minimum video frame rate 256*192 pixels 10 fames/s

Control SpecificationMinimum 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 wasnt 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 platform4


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 CommunicationRs232 serial, USB,802.11a/b/g Network with multiple or large coverage 802.11 wireless access point

Peripherals Webcam GPSMust provide at least 10 frames per second that are 256*192 pixels Must support a serial or USB interface

Mobility RequirementsDegrees 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.

MotivationA 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 clients 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 on6


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 ContributionsThe 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 packetswitching services like GPRS for applications of teleportation and telemetry. Unlike RF and fiber used by conventional TGVs like MATILDA, the use of widely deployed packet switched services like GPRS can allow the use of existing infrastructure and control over longer distances. The product features are listed below. Software is easily adaptable for modifications Various sensors can be implemented in the software Communication and control of robot over a wireless network The prototype features includes the product features listed above and the features listed below. Video feedback from robot GPS data from robot Motion sensor data from robot Graphical User Interface on a remote station for control of robot Data displayed in the Graphical User Interface

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

8


Thesis OutlinesThis 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 Hardware2.1 IntroductionThe 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 systems 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 Creates 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 Software3.1 IntroductionIn 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 realtime 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 CEs 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

AbstractCommandFactory.h/.cpp

These two files set the foundation for the well known design pattern: Command Factory A concrete implementation of the AbstractCommandFactory for the iCreate Robot Data structure to hold the incoming command message from the RemoteController Makes use of the command factory design pattern

IRobotCommandFactory.cpp

Buffer.cpp

CommandExecuter.cpp

CommandImpl.cpp

A sample implementation of the EC_Command abstract command.

connection.cpp

Class to encapsulate the network connection

ConnectionManager.cpp

Class to handle instatiation of Connection their termination

ConnectionSocket.cpp

Light wrapper around windows SOCKET

25


Abstract command EC_Command.cpp

OpenInterface.cpp

Provides the iCreate Robot On Interface commands from a cleaner contained namespace Includes _tWinMain, the message loop, and the main functionality Networking functions

Excutive.cpp Socklib.cpp

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

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

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

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

26


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() +Execute(in paramLength : unsigned int, in params : char*)

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

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

28


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

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

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

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

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

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

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

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

29


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

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

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

structControlTheRobot::ThreadContext +m_hThread : HANDLE +m_dwTID : DWORD +m_pUserData : LPVOID +m_pParent : LPVOID +m_dwExitCode : DWORD +ThreadContext()

30


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

31


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

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

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

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

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

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

32


3.5.2.2 eBox GPS Subproject Description As displayed in chapter 1 the proposed hardware includes a GPS receiver used to determine the longitude, latitude, and altitude for the robot. A subproject is required to be created to control over these tasks. GPS module API was used to facilitate this task in this subproject. Code Files Used eBox_GPStest.cpp Main windows message loop initialization, Reads the GPS and sends it to the RemoteController Initialize Phidgets and instantiate the API pointers from the DLL using The usual windows include file to be precompiled

PhidgetFunctionPointers.cpp

stdafx.cpp

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

33


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

CameraCode.cpp

mjpeg2bmp.cpp

VideoSender.cpp

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

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

Sensors.cpp

PhidgetFunctionPointers.cpp Socklib.cpp

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

34


Chapter 4: Computer End software4.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-Boxs 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 such36


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

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

38


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

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

39


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

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

Classes and Libraries Used QDebug40


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

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

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

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


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

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

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

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

42


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


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

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

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

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

47


#include

4.5.6 plotview.ui Description PlotView Class allows adding plots for sensor and GPS data in the main window. UMLUi_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*)

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

QPaintEvent The QPaintEvent class contains event parameters for paint events.

49


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


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

QTcpSocket The QTcpSocket class provides a TCP socket.

Code Block #include

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


#include

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

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

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

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

53


Code Block #include

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

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

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

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

54


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

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

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

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

55


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

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

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

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

56


UML

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

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

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

57


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

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

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

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

58


Code Block #include

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

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

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


#include

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

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

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

60


UML

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

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

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

QThread The QThread class provides platform-independent threads.61


Code Block #include

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

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

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


#include

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

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

63


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

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

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

Code Block64


#include

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

Code Block #include

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

Code Block #include

65


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

UML

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

Classes and libraries used QWidget

66


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

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

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

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

Code Block#include

67


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

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

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

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

QFont

68


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

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

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

QThread The QThread class provides platform-independent thread.69


Code Block#include

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

QTcpSocket Class The QTcpSocket class provides a TCP socket

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

70


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

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

71


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 Featuresa) 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: Networking5.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 mW (dBm) (approximate)

Class

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., "Youve 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 infrared79


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 the80


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 .

graduation project: roverbot - thesis

Documents