Nada Labs

An overview of my honours project, covering the design and implementation of a research framework built in C++ to interface with USARSim. The major goal of this project was to be able to provide data to emperically validate control algortihms and justify design decisions. An overview of the libraries (Windows .dlls) and message flow between the various modules are presented. 

Various simulators exist for modelling robotic platforms, from the simple 2-dimensional to complex environmental and physics modelling. Most of these simulators require a large amount of support code to be written by the user before they are able to implement and test algorithms. This project aimed to develop a research platform for the testing and development of autonomous robot navigation and interaction while providing a means of experimentally validating algorithm efficiency and suitability. The platform was designed to monitor a single robot in an environment and record suitable data with the ability for expansion to monitor multiple robots later on. It was envisioned that, through the use of this research tool, new algorithms could be developed and rigorously analysed to justify selection decisions and show that learning algorithms were improving with time.    

The overall goal of developing a research platform is to not restrict the development process but to allow as much flexibility as possible. This project sought to provide that flexibility through providing a framework consisting of importable code libraries (.DLLs) and leaving the final application up to the user. The individual components themselves were proposed to be as portable as possible, allowing for their reuse in separate projects.      

Selection of Tools

After researching the available tools for robotic simulation, USARSim was selected as the simulator to be used in combination with SQLite to store recorded data. Some of the tools considered included Microsoft Robotics Studio, Player/Stage/Gazebo and some commercial applications. 

USARSim provides detailed models of environments and physical interactions, allowing behaviour based robots to be developed in simulation. (Carpin, Lewis, et al. 2007). A great deal of effort has been put into validating the simulated environment and components. Balaguer et al describe the process they used to verify the GPS sensor and its output through the creation of several experiments. USARSim is designed to allow for algorithms that work well in the simulator to be directly moved into a physical robot with minimal modification. 

As USARSim is a pure simulator, it only provides a very low level control interface to drive the robot models, akin to the interface provided by physical robots. While interfaces are available to use USARSim with Player and other controllers, the developer is capable of building their own control algorithms, increasing the flexibility available. 

SQLite is a public domain, self contained transactional SQL database engine that has been widely deployed in applications from web browsers to smart phones. The design goals of SQLite included that it be simple to administer, operate, deploy and maintain. Various interfaces exist for SQLite to interface with existing applications including Excel and MATLAB for the analysis of the information stored in the database. SQLite has many uses and works well in embedded environments and as application file formats. A database that is created by SQLite is contained within a single file that can be located anywhere on a drive. This database file can easily be emailed, copied and shared amongst multiple computers and people for their use. 

Simulator Interface Library

The simulator interface library is the main interface for various robot control algorithms to communicate with the simulated environment. The library was required to be able to connect with USARSim, process the incoming messages and provide the information in a usable format. The simulator interface also needed to support logging of standard information through the database interface library. The sample communication from USARSim demonstrates that while the information is easy for a human to interpret and understand, a method of processing it was needed in order for a computer based algorithm to use it effectively.    

NFO {Gametype BotDeathMatch} {Level DM-CBNoMaze} {TimeLimit 0}
NFO {StartPoses 5} {Start5 0.00,6.76,1.35:0.00,0.00,-1.57 Start2 -3.26,-5.08,1.35:0.00,0.00,0.93 Start1 0.01,-7.57,1.35:0.00,0.00,1.57 Start4 -2.43,4.48,1.35:0.00,0.00,0.00 Start3 1.93,-1.56,1.35:0.00,0.00,0.64}
INIT {ClassName USARBot.P2AT} {Location 0.000000,6.760000,1.280000} {Rotation 0.000000,0.000000,-1.570000}
GETGEO {Type Robot}
GEO {Type GroundVehicle} {Name P2AT} {Dimensions 0.5238,0.4968,0.2913} {COG 0.0000,0.0000,0.0000} {WheelRadius 0.1300} {WheelSeparation 0.4079} {WheelBase 0.2640}
GETCONF {Type Robot}
CONF {Type GroundVehicle} {Name P2AT} {SteeringType SkidSteered} {Mass 14.0000} {MaxSpeed 5.3850} {MaxTorque 60.0000} {MaxFrontSteer 0.0000} {MaxRearSteer 0.0000}
SEN {Time 303.1106} {Type Sonar} {Name F1 Range 4.9976} {Name F2 Range 4.9952} {Name F3 Range 4.9969} {Name F4 Range 5.0000} {Name F5 Range 5.0000} {Name F6 Range 4.9957} {Name F7 Range 4.9950} {Name F8 Range 4.9988} {Name R1 Range 4.9978} {Name R2 Range 1.3408} {Name R3 Range 0.9540} {Name R4 Range 0.8183} {Name R5 Range 0.8185} {Name R6 Range 0.9542} {Name R7 Range 1.3403} {Name R8 Range 5.0000}
SEN {Type Touch} {Name Touch Touch False}
SEN {Time 303.1106} {Type GroundTruth} {Name GroundTruth} {Location 0.00,6.76,1.28} {Orientation 6.28,6.28,4.71}
MISSTA {Time 303.11} {Name CameraPanTilt} {Link 1} {Value 0.0000} {Torque -20.00} {Link 2} {Value 0.0000} {Torque -20.00}
STA {Type GroundVehicle} {Time 303.11} {FrontSteer 0.0000} {RearSteer 0.0000} {LightToggle False} {LightIntensity 0} {Battery 1199} {View -1}

A heirarchy of C++ classes were designed in order to abstract the useful data from the foramt that USARSim provided it in. The base classes provided a low level interface to the simulator and system services. Mid level modules performed most of the processing and data abstraction. The high level modules represented various concepts of the simulated robot.    

  The design of the Simulator Interface Library allows the user to focus on the development of a control system for the robot through taking care of all of the support logic needed. The steps required to implement a connection to the simulator and develop an algorithm are:      

1. Create a module that is derived from the System module.
2. Add member modules for required information e.g. a SensorRangeScanner module for using laser range scanner data
3. Implement the Launch function, where all processing is performed for the robot.
4. Use the Interface module to connect to the simulator.
5. Start the trial through the TrialRun function.

Step 3 is the point where all processing for the robot takes place, using sensor data to make decisions about the current environment. The Launch function in the System module is akin to a main loop on real robot hardware, performing a small amount of initialisation and then running until it is told to exit on power down.    

 Data Collection Library

The data collection library provides the means of assessing algorithms and parameters for optimal performance. Information is logged throughout a trial which can later be assessed and compared to other trials.    

The data collection subsystem was designed to record general system events and other high level data when it occurs, as opposed to recording all inputs to the system as the data arrives. The main basis behind that decision is that algorithms, in general, are highly dependent upon the initial conditions of the system they are monitoring.    

Learning algorithms, consisting of Neural Networks, Genetic Algorithms and Fuzzy Logic attempt to apply computational intelligence to the problem that they are required to solve. During the course of evolution or learning these algorithms could potentially take the exact same input data and reach a vastly different conclusion about what is required of the system at that point.    

As a small change to the inputs or parameters can result in a large difference in the eventual location of the robot, recorded sensor data of a previous simulation trial quickly becomes inaccurate and irrelevant. The recording of higher level data allows the algorithm to be evaluated on concepts of obstacle avoidance and route planning while on destination to a target, instead of results of motor drive commands in response to sensor inputs.    

Logging for four main classes of information was implemented, allowing the user to keep track of various aspects of the robot throughout a simulation trial. The categories of recorded information are:    

• Trials, which contains information about an individual simulation trial.
• Waypoints, which outline where the robot was intending to go, how it got there and how it navigated around obstacles.
• Events, which describes when and where events occurred throughout the simulation trial, what the event was and any extra data for that event.
• Algorithms, containing the configuration of the algorithm for that trial run and the settings of its various parameters.

The collected data is stored in a file backed database, provided by SQLite. While using a SQL database for the storage of information was harder to implement and more complex, it provided several advantages that outweighed the above disadvantages. The database caters for additional categories of information to be stored at a later date, without impacting previously recorded data. SQLite also stores all information in a single file that can be arbitrarily copied and moved, promoting offline backups and analysis at alternate locations. With the addition of freely available database connector drivers for SQLite, standard programs including Excel and MATLAB are able to access and analyse the recorded data with a minimum of configuration.    

Each category of information is stored in a separate table in the database, with all information being linked together through the trial id. The event and algorithm tables were designed to allow expansion of the data that they store without impacting on previously stored data or databases from other algorithm implementations. This design was chosen to allow different events or algorithms to co-exist in the database without having to have a separate table for each different implementation. The base database library was implemented separately to the simulator interface to enable it to be used in other projects and expanded upon. The library was based on a similar design to the simulator interface, having a few low level classes that are expanded upon to abstract the important data from the underlying storage mechanism.   

While the information stored doesn’t allow for the direct replay of a previous trial, the path the robot was meant to take and how it got there is stored in the waypoint table. A robot can be made to follow the same path by extracting the waypoints that have a reason of WAYPOINT_REASON_ROUTE from a previous trial. Performance of navigation and obstacle avoidance algorithms can then be assessed. Similarly through reusing the start and end locations of a previous trial, path planning algorithms can be analysed by comparing generated route waypoints.   

Using the Framework

In order to demonstrate the functionality and flexibility of the framework an algorithm was implemented to navigate a 2 wheeled, skid steered, robot from one point to another through a maze. The algorithm was required to work without any prior knowledge of the maze and utilise the sensors available on the robot model. The general class of algorithms that solve the above navigation problem are local-path-planners within which a large range of algorithms exist, of which TangentBug generates the shortest path but is the most difficult to implement. The TangentBug application was used to quickly test an implementation of  the Tangent Bug algorithm with different ranges being used for the detection of objects. The algorithm was also tested on a similar map without the walls to obstruct the path of the robot. The user interface enabled the parameters to be quickly changed, resulting in the prompt collection of data with the framework. The collected data indicated that further work was required in that particular implementation of the Tangent Bug algortihm in order for it to work successfully in navigating a robot through a maze. The data also demonstrates that the framework provides a means for adjusting, analysing and comparing algorithms as they are trialled.   

Conclusion

The framework for interfacing to an existing, validated robot and environment simulator, as presented in chapter 3, allows users to rapidly implement algorithms for the autonomous control and interaction of robots. The framework allows users to empirically validate and verify their algorithms through its data recording interface, leading to better design decisions being made. The code generated while implementing a design is easily moved to real hardware without sacrificing functionality or flexibility.   

Future Work

While the framework enables the research of robotic algorithms, improvements and future work would give a user several advantages.   

During the development process the user implements an algorithm, compiles and tests the code. If the algorithm needs to be modified at the structural level the implementation is modified and the process is repeated. This process of compile-test-recompile can add up to a significant amount of time that could be used more effectively in the design and analysis phase. A scripting language would allow the user to make changes and instantly test them, speeding up the development process. Bindings for a pre existing language such as Perl or Python would enable the framework to be utilized more efficiently and lessen the learning curve associated with the development of a custom language.   

Currently the user is blind to what their algorithms are assessing while they are executing. A method of data visualisation would enable the user to determine at a glance that the algorithm is operating effectively. Data visualisation techniques would also improve the analysis of recorded data and the validation of algorithm efficiency and suitability for the task at hand.