1. v Project Overview The Mars Ground Control Group is responsible for handling communications to and from a rover in a test area simulating a Martian or lunar environment. The group is also responsible for robot localization and communicating rover sensor data, metrics, and location to the user. Clients: Professor Al Liddicoat, Lockheed-Martin, and the rover group Mars Sandbox - Ground Control Team California Polytechnic State University CPE Capstone – Fall ‘07/Winter ‘08 Tim HermannJose Angulo Ben DaviniRyan Morton c Satellite Ground Control Server Mars Rover Communication Server Internal Sockets Ground Control Client and GUI Robot 802.11/Ethe rnet 802.11 Localization Beacons Ultrasound/RF System Architecture Communications UML Diagram Communication Black Box Design Use Case Diagram The Communication Black Box provides a bridge for data transfer between the TCP clients and the UDP rovers. Inside, data can be manipulated by introducing artificial delay, corruption, and data loss. All communications classes are threaded. This allows any implementing class to use the framework in a non-blocking fashion. The overall design of the various classes attempted to abstract away the use of UDP versus TCP for ease of implementation. As a result, the abstraction of a Packet class was created to hold both the data buffer sent or received, as well as information related to where it’s going, which client it was associated with, et cetera. The Client class is used by the TCP Server to represent a connected client, and by the TCP Client to be the method through which data is transferred. It does not directly inherit AsyncCommunicationsBase because of conceptual differences between its background worker implementation compared to the asynchronous callbacks used by all other classes. Communications GUI The front end for the Communications Black Box allows binding to any available local IP address. At startup, the Configure Server window appears, querying the local host for DNS information. Once Start is pressed, the Server Status window appears. This provides an at-a-glance look at the server. Various parameters related to the communication black box can be set, and a list of connected clients, as well as registered rovers, may be accessed from the Clients menu. Remote Control Conclusion The Ground Control project was completed on schedule with main project goals satisfied. The current system allows localization, communication, and control across multiple clients and with various network technologies, and can be set up with relative ease. More advanced features on the satellite such as delay, corruption, and image transmission were dropped due to not being feature complete by the integration deadline. The localization technology can be improved with an increased number of beacons and further research on localization technologies. These improvements have been documented such that future groups should be able to implement these features without much difficulty System Integration and Test The separate components (GUI, simulated Satellite, and Localization software) were developed independently but cognizant of system integration requirements. The modularity of each component is such that testing and integration of the entire system was done quickly and efficiently. Testing first took place with environments and software that tested each component individually. A miniature sandbox was created for localization and integration testing. Full system testing included a test program on a laptop that communicated with the satellite server over TCP/IP. Because no rover was available for full integration testing, the laptop was moved manually in the miniature sandbox to simulate rover movement. Functionality was confirmed by receipt of messages and an updated graphical map on the GUI. Localization Implement delay, corruption, and variance Implement disconnect functionality for connected clients or rovers. Extend logging capabilities to handle priority and saving to file Display picture/video feed Implement selectable interface between multiple client rovers Dynamically match GUI map to sandbox dimensions Add/remove sensor fields to match rover sensors Implement and return z component Improve erroneous distance measurement Improve time response of getCoord() function Communication Remote Control Future Work Localization (x 0,y 0 ) (x 1,y 1 ) r0r0 r1r1 d h d Figure X: Intersection of two circles as an abstraction to intersecting spheres in 3D. The any triangle of side r a, d, and h along with center of circle (x a, y a ) can be used to find intersection points Figure X: Graphical depiction of hardware architecture. Listeners determine distance to each beacon by measuring time shift between arrival times of RF and ultrasonic signals (simultaneously sent by beacon) Overview The localization system uses the Cricket indoor beacon system shown in figure X. The location (x,y) of the listener cricket can be calculated based on the distances to each of the four overhead beacons and their respective (known) locations. These distance calculations use the difference in arrival times of the RF and ultrasonic signal and the known speed of sound and light. Figure X: Cricket indoor beacon produced by Crossbow Technology, Inc and developed by MIT. Operation Two threads of control allow for quicker results and limit the impact on system timing. One thread continually reads serial port, parses input and stores distances. The client thread (robot) calls a C function to calculate the robot coordinates (x,y). The localization software calculates the location of the listener based on the distances to each of the four beacons using trigonometry and intersections between circles (see figure X). With four beacons there are six circle-circle intersections resulting in twelve possible (x,y) coordinates. The algorithm takes these twelve points and determines the most probable coordinates. Error Reduction The cricket listener-to-beacon distance measurement has a 1 cm precision. This precision coupled with the non-linear calculations using trigonometric functions for the intersection points inherently contains errors. In fact, the probability of six circles intersecting at the exact coordinate of the listener essentially equals zero. Using timestamp info from beacon distance receipt and the number of intersections within threshold distance of convergence point the function returns a probability value (0,1) stating confidence in value returned. Iterative approaches to improving environmental were used with vectors to determine which beacon values caused most error.