Final Report
RECEE: Reconfigurable Embedded Controller for Environmental Exploration
Prepared By: Group1
Greg Bonn
Shawn Luna
Mark Radford
Michael Sullivan
Jessica Wheeler
Reporting Period: 2/1/05 – 5/2/05
Advisor:
Dr. Yinong Chen
Professor:
Dr. Hasan Cam
May 2005
ArizonaStateUniversity
Tempe, AZ
TABLE OF CONTENTS
1.0ABSTRACT
2.0INTRODUCTION
3.0DETAILS
3.1Controller
3.1.1Design Decisions
3.1.2Implementation
3.1.2.1User Interface
3.1.2.2Device Interface
3.2VUC Simulator
3.2.1Design Decisions
3.2.1.1Controller Interface
3.2.1.2GUI
3.2.2Implementation
3.2.2.1Controller Interface
3.2.2.2Vehicle Simulation
3.2.2.3GUI
3.2.2.3.1Initial GUI
3.2.2.3.1Final 3D GUI
3.3Integration and Testing
4.0Difficulties Encountered
5.0TASKS COMPLETED
6.0CONCLUSION
6.1Limitations
6.2Lessons Learned
7.0REFERENCES
Table of figures
Figure 1: Organizational Chart
Figure 2: Controller interface definition
Figure 3: RECEE Controller GUI
Figure 4: 2D Simulator GUI
Figure 5: RECEE Test Server
1.0ABSTRACT
The purpose of this project is to create a Reconfigurable Embedded Controller for Environmental Exploration (RECEE). RECEE is designed to be independent of the actual vehicle and designed to adapt to a variety of environments, such as ground based or underwater. Instead of demonstrating this application on a specific hardware platform, the group has decided to create a software simulator to mimic the actual vehicle. The project, therefore, was split into two major sections, the controller and the Vehicle Under Control (VUC) simulator. The design, implementation, progress, and future work on both sections will be discussed here.
2.0INTRODUCTION
RECEE is designed to control an unmanned vehicle through various environments that may be difficult or even impossible for humans to explore. RECEE can be given a predetermined path before being deployed to its target destination. Once RECEE is on its way, if it encounters an obstacle along that path, it can send back information regarding the obstacle, and the application can then determine the best way around it and recompose the path.
The motivation behind this project stems from the fact that embedded processors represent over 99% of all microprocessors in production worldwide[1]. The resources and adaptability of an embedded system, however, compared to a common PC’s, are extremely limited. RECEE, on the other hand, can utilize a more powerful remote command center to recompose itself in real-time. This real-time reconfiguration of control routines can enable the explorer to adapt to changing environments and handle unforeseen events. Since RECEE is designed to deal with unknown environments in real-time, pre-defining all possible routines is not necessary. If the controller is unable to maneuver around an obstacle in the vehicle’s path, a remote command center, with more powerful computing capability can evaluate the data sent back by RECEE and recompose the routines to adapt to the environment. The design and implementation of the remote command center is beyond the scope of this semester’s project.
Another motivation for the project was the Mars Exploration Rover used by NASA. The Rover was used to provide information about Mars’ environment. RECEE is designed to be independent of the vehicle’s physical implementation, which allows it to be utilized in all types of applications and environments, including, but not limited to, space exploration. The objective of the reconfigurable feature used in RECEE, will be to enhance movement and adaptability in applications such as the Mars Rover.
Due to time and financial constraints, a simulator for the Vehicle Under Control (VUC) was chosen instead of building an actual vehicle. Different types of vehicles that could be used with RECEE will have different physical limitations that may decrease the full functionality provided by the application; by using a simulation environment, all features of RECEE can be demonstrated.
3.0DETAILS
The reconfigurable embedded system is based on Windows CE, and can control a vehicle’s movement using input from the user and feedback from the vehicle, which will be represented by the simulator. The ability to reconfigure the program will allow the vehicle to take different paths based on real-time information.
The vehicle’s path will be transmitted in XML format from the CE device to the VUC using a socket based connection. The simulator will translate the XML data into the appropriate commands that will move the vehicle within the simulated 3D environment.
The project has been divided into two major sections:
- The Controller, which contains the user interface and device interface, both of which were developed with Microsoft C# Smart Device applications.
- The VUC Simulator, which contains the controller interface, the graphical representation of the vehicle and the vehicle simulation.
Once these two major tasks were determined, the appropriate sub-tasks were developed and are shown with their respective owners in the following organizational chart.
Figure 1: Organizational Chart
The implementation details of the project have been broken down by the two main sections and each of the corresponding sub-sections.
3.1Controller
The Controller interface design in shown in Figure 2.
The user interacts with the GUI on the CE device to provide an IP address and port of the server implemented on the VUC. The user can then create a desired path for the VUC from the list of commands on the GUI.
The communication layer between the CE device and the simulator is implemented with a Client-Server design using a socket-based connection. In our implementation, the PC running the simulator will act as the server and the CE device will act as the client. This configuration was chosen because the simulator needs to be able to sit in a state in which it is not connected to anything but it is waiting for a connection to occur. If the simulator were to be the client we would have to design an interface to initiate a connection with the CE device, which could be done on the simulator but the actual car would not have this functionality.
Figure 2: Controller interface definition
3.1.1Design Decisions
The choice of Windows CE provided many benefits, including the ability to change the controller’s platform to one matching the customer’s requirement.
The decision to use XML to encode the data was due to XML’s simplicity and ease of use. There are also built-in libraries in C# to create XML objects, which made the implementation very simple. The RECEE application is designed to be generic enough to use with a diverse set of vehicles. Each of these vehicles will require a unique driver to decode the XML data into the appropriate byte code or signals to drive the vehicle. The RECEE application should not include such drivers; otherwise it would not be independent of the vehicle and would be very limited in its application.
A TCP socket-based interface will be used to connect the CE device to the VUC simulator. TCP connections maintain a connection between the client and server device at all times and provide built in transmission reliability. This frees the RECEE and VUC Simulator from transmission validation duties. C# also has Socket libraries that support TCP protocol.
3.1.2Implementation
3.1.2.1User Interface
The user interface for programming the controller was designed for simplicity and adaptability to different customer’s requirements. Given this ambiguity, a basic interface was chosen and implemented. Microsoft Visual Studio built-in Form Builder was used to create the Form and place the controls. All of the controller code was written in C#.
Figure 3: RECEE Controller GUI
As shown in Figure 3, simple controls to enter movement commands were created, as well as entry fields to supply connection information. The user selects the path of the vehicle from the perspective of a hypothetical pilot. Forward or reverse motion is specified using positive and negative values in the meters NumericUpDown control, direction is changed by specifying a heading change using the degrees NumericUpDown control. Although the NumericUpDown control is capable of specifying a resolution finer than 1.0, the implementation on Windows CE .Net does not support that granularity. Commands may be moved or deleted using the buttons located below the Route To Take list box.
Once satisfied with the route entered, the user clicks the Deploy button to send the commands to the VUC. The commands are packaged as XML and sent one at a time to the VUC. The VUC will attempt to execute each command and responds to the controller with a Success or Failure. Along with a Failure token is the reason for failure (Connection Lost, Obstacle, etc). With all response tokens, the VUC returns its 3D coordinates relative to its starting point. The controller uses this information to track the movements of the VUC. As the controller and VUC become more sophisticated, subtle corrections can be made for drift motion.
3.1.2.2Device Interface
The device interface is implemented in C# and uses .Net’s built-in Socket library to create a TCP connection to the simulator PC, which is acting as the server. The CE device interface is responsible for sending the XML data representing the path entered by the user to the simulator and waiting for confirmation from the server. The data sent back provides the vehicle’s 3D coordinates and direction, relative to its original position. This information can then be provided to the user. The device interface is implemented in two separate classes, which are described in detail below.
The ClientSocket class provides the low level functions to transfer the data to the server. It is used as an abstraction layer between the server and the Client class. This class creates a ClientSocket object. The object uses the provided IP address string and port integer to create an IPEndPoint object which is then used to instantiate a socket object. The socket object that we create is of stream type and uses TCP protocol. C# contains a TCPClient class that basically implements the same connection through a socket. The main reason for not using the TCPClient class was to provide more flexibility for change in the future. If another protocol is desired, the only changes needed would be in the socket instantiation of the ClientSocket constructor. The.Net Compact Framework supports a number of different protocols for Socket objects, including but not limited to TCP, IP, Icmp, and Udp. With the current implementation changing the protocol would be transparent to the user interface, which is the main reason for using our own low level ClientSocket class.
There are several methods implemented in the ClientSocket class. The connect method calls the Socket connect method which tries to connect to the IPEndPoint. This method can throw an exception. There is also a sendData method that takes a string and uses the Socket Send method to transfer the string to the server. The string is first encoded to ASCII characters before being transferred. This method returns a 1 if it was sent, a 0 if there is no connection and a -1 on any other error. The final method is the receive method that returns a string. This method uses the Socket Receive method in attempt to read data transferred from the server. The string “Error” is returned if an exception is thrown, otherwise the ASCII string received is returned.
The second class is the Client class. This class provides the interface between the user program and the ClientSocket class. These methods aredirectly accessed by the user interface to transfer the XML data. The Client object is instantiated in the user interface program. The IP address and port provided by the user are passed as parameters to the Client connect method in an attempt to create a connection with the server side. The connect method calls the ClientSocket connect method and returns a 1 on success and a 0 on failure. The Client class also provides a method called sendData that takes a XML string and calls the ClientSocket sendData method. The value returned from the ClientSocket sendData method is used within the Client class to determine what actions to take. If there was a bad connection a 0 is returned, if there was an error in the transmission a 2 is returned, otherwise the data was sent and the method attempts to receive the handshake signal from the server. The receive method from the ClientSocket class is called and if there is an error, a 4 is returned. If there is obstacle detection and an obstacle is found, a 3 is returned. Finally, if the vehicle completed its command, the current 3D coordinate position and direction is passed back from the server and is providedto the user interface.
3.2VUC Simulator
The VUC Simulator is used to provide a visual representation of the vehicle under control. The simulator was developed in place of an actual vehicle to demonstrate RECEE’s capabilities. The simulator tracks the vehicle’s movement along its path.
3.2.1Design Decisions
The following design decisions were made when developing the VUC Simulator.
3.2.1.1Controller Interface
Connectionless data transmission protocols, such as UDP (User Datagram Protocol), were considered because of the reduced overhead of data transmission. UDP lacks the built in transmission acknowledgement and retransmission that TCP provides. Although this is a much simpler protocol for implementation, the transmitting peers must implement some level of transmission verification if the data is critical. Due to the critical nature of the control commands, the TCP socket-based transmission was chosen. C# provides built-in libraries for TCP sockets with sample code to provide a base for development.
The interface with the controller was implemented using the socket libraries provided by C#. The interface has undergone many transformations throughout the project. It has always been based upon the server side of a TCP client/server model; however the exact implementation has changed several times.
The initial implementation was based upon the code provided to us by Dr. Chen. This design allowed us to support multiple connections and buffer multiple commands from the controller. However, this model also included a significant amount of overhead that was unnecessary. Our overall command structure between the controller and the simulator is very simple, a single command is sent from the controller, executed, and then a reply message is sent back from the simulator. There will only be one command issued from the controller at a time and there will only be one controller connected to the simulator at any given time. Thus, we chose to simplify the design of the server from one that supported multiple connections and multiple commands to one that followed our communication structure more closely.
The second implementation of the server was the exact opposite of our initial implementation. It was a simple, single connection single command implementation that allowed simple send and receive functionality and not much else. However, a new problem was discovered, the simulator needed an interface that would run in its own thread and allow the rest of the simulator to run normally while waiting for a new command from the controller. If the server did not allow this the display for the GUI would not be able to refresh regularly and would behave abnormally.
To implement this next challenge, we decided to use an event driven system. An event is a signal that is sent when an anticipated change has occurred and needs to be handled. In our implementation this takes the form of a new command being received from the controller. When a new command arrives a signal must be sent to the rest of the simulator so that the new command can be processed. By generating an event signal and having the server run in its own thread the rest of the simulator was allowed to run normally even if the server was waiting for the next command.
3.2.1.2GUI
The final implementation for the simulation environment is a 3D “world”. The original GUI was created in 2D graphics. This was done first because the learning curve seemed steeper for 3D graphic languages. It is obvious that 3D provides a more realistic visual representation of the real world and the different terrains that RECEE could be used for. After we were able to implement a 2D GUI of the simulator, the next step was to create a 3D working model within the time limits. Methods of representing this environment were researched in order to implement an accurate model of a vehicle. In the end OpenGL was the chosen for its robustness and ease of use. There were also C# wrappers available for use with OpenGL.
3.2.2Implementation
3.2.2.1Controller Interface
The controller interface was implemented using a simple TCP server model that was contained within its own thread. The server generates an event to notify the rest of the simulator that a command has been received from the controller. The final implementation of the server interface with the controller was broken into three distinct parts:
- ReceivedDataEventArgs
- ReceivedDataEventHandler
- Server
The ReceivedDataEventArgs class is essentially a container class that holds the command data received from the controller. There are two elements of data that are received from the controller, a command that tells the vehicle to move or turn and a data element that hold the distance to be traveled or the angle at which to turn.