The original purpose of this research was to demonstrate the feasibility of implementing a hardware- and software-independent abstraction layer around sensors, types of sensors, and algorithms which would provide a controlling intelligence with access to standard information and capabilities and allow the distribution of low-level processing in a manner consistent with a distributed network by extending Free and Open Source Software (FOSS) tools for robot and sensor applications, specifically the applications Player and Gazebo.
The abstraction layer would have taken the form of nodes which detach agents with specific goals and capabilities. Both nodes and agents might run in a separate process or on a separate processor, and would communicate with each other or the controlling intelligence via a client-server relationship. For example:
However, when the author originally undertook an evaluation of team technical proposals following the 2004 GCE it quickly became apparent that, while theoretically feasible, the practical foundation for such an architecture does not exist2. In general, team efforts were specifically tailored to a chosen research platform and selection of sensors. There was no agreement on what combinations of sensors provided what information to the controlling intelligence, no agreement on basic algorithms which process raw sensor output and provide information to the controlling intelligence, and no agreement on algorithms which allow the controlling intelligence to determine what sensors are available to it and what information they provide.
Although the author was able to conceptually divide sensors and dedicated processors into a network of distributed nodes similar to those described by team technical proposals3, insufficient technical detail was disclosed by the teams; and the performance of teams during the 2004 and 2005 GCE supports a conclusion that the identification of basic algorithms was not the focus of the Grand Challenge. As a result, the author was unable to demonstrate the feasibility of implementing a hardware- and software-independent abstraction layer based on 2004 and 2005 GCE challenge vehicles.
In addition, it was not the purpose of this research to implement a controlling intelligence. Because team efforts were specifically tailored to a chosen research platform and selection of sensors, any implementation of a controlling intelligence provided by one of the teams would have resulted in a re-creation of their challenge vehicle as well, effectively defeating the original purpose of this research.
However, while reviewing team technical proposals the author observed a distinctive or characteristic pattern of related behaviors (a syndrome) which was more prevalent in teams with prior experience or significant corporate or academic sponsorship. The author performed a comprehensive review of technical proposals submitted by teams which participated in the the 2004 Qualification, Inspection, and Demonstration (QID) or GCE or 2005 GCE in an attempt to determine the total cost of team solutions so that, based on total cost and number of miles of the 2004 or 2005 GCE course completed, the author would be able to evaluate the cost effectiveness of team solutions, determine which solution was most cost effective, and evaluate the impact of prior experience or significant corporate or academic sponsorship on team performance. However, detailed cost information was not available and it was not possible to relatively rank team challenge vehicles to determine which solution was most cost effective.
The comprehensive review of technical proposals submitted by teams which participated in the the 2004 QID or GCE or 2005 GCE revealed that teams which performed better or completed more miles of the course used the same or similar strategies, and that teams which did not use these strategies did not perform as well or completed less miles of the course. These strategies are referred to as key factors contributing to success. Key factors were therefore symptoms of the syndrome.
Identification of the key factors contributing to success is the focus of the technical report.
Because the stated purpose of the 2004 and 2005 GCE was ostensibly innovation in the field of autonomous vehicle development, the author uses the phrase potentially disruptive team to refer to a team with no prior experience in the field of autonomous vehicle development and neither extensive corporate nor academic sponsorship which implemented the greatest number of key factors contributing to success. The following teams were not potentially disruptive due to their prior experience and extensive corporate or academic sponsorship: Teams 2004-044, 2004-10, 2004-23, 2005-02, 2005-04, 2005-13, 2005-14, 2005-16, and 2005-21. Potentially disruptive teams were therefore those teams which displayed the distinctive or characteristic pattern of related behaviors specifically identified as the key factors contributing to success.
Potentially disruptive teams had a great deal in common with teams with prior experience and extensive corporate or academic sponsorship. However, evaluation of the key factors revealed teams with prior experience or extensive corporate or academic sponsorship were able to use the effects of experience, in particular, and sponsorship as the equivalent of a force multiplier. The advantage this gave these teams was so significant that the author questions whether it was appropriate for DARPA to allow most of the teams which participated in the 2004 or 2005 GCE to participate without first ensuring those teams were able to identify the fundamental problem and devote sufficient resources to the development of a challenge vehicle which would be competitive with those of teams with prior experience and significant sponsorship.
The author asserts the use of simulation as a complement to the Grand Challenge would have provided teams participating in the Grand Challenge with a way to identify key factors contributing to success prior to field trials, increased focus on the development of basic strategies and algorithms to enhance the intelligence of autonomous vehicles, and provided a way to increase the competitiveness of the Grand Challenge by leveling the playing field, allowing teams with no experience or limited sponsorship to compete on a more even basis with teams with prior experience or significant sponsorship.
Key factors became the basis for evaluation of the use of simulation during autonomous vehicle development. Key factors which could be tested in simulation were considered for evaluation. Simulations were designed to evaluate selected key factors using Player and Gazebo, free and open source software for robot and sensor applications. The use of simulation was effective, however successful simulation was only possible after many problems with the applications Player and Gazebo were resolved.
Evaluation of selected key factors contributing to success was the focus of the thesis.
A complete copy of the thesis is available as a PDF (6.1M). Refer to the Table of Contents for specific sections, tables, and figures.
Appendix A (229K) of the thesis documents, in detail, the development of an installation procedure to ensure a reproducible simulation environment, which was necessary due to the generally poor quality of published installation instructions, including those packaged with Player and Gazebo and their dependencies.
Appendix B (90K) of the thesis documents the installation procedure, which was verified in accordance with Appendix C (90K).
Appendix D (98K) of the thesis provides the source code for the improved C++ steering controller and wheel classes.
Appendix E (70K) of the thesis documents example output based on the custom XML parameters implemented.
Appendix F (78K) of the thesis documents example XML configuration files used during research.
Appendix G (135K) of the thesis describes, in detail, miscellaneous problems encountered while verifying Player and Gazebo, validating the improved controller, and evaluating selected simulation targets. The problems included errors in packaged XML configuration files and source code, as well as errors in the user interface and implementation of specific features.
The Table of Contents lists several tables and figures which appear in the main body of the text, but are not hosted as separate documents, specifically Tables I and II and Figure 1. For these tables and figures, refer to the chapters containing them.
A complete copy of the technical report providing relevant technical data, justification for conclusions, and resolution of discrepancies supporting research documented by the thesis is available as a PDF (17.6M). Refer to the Table of Contents for specific sections.
Appendix A (82K) of the technical report provides the source code for the RDDF analysis application. As noted, PHP include statements and the author's Google Maps™ key were deleted from the source code prior to inclusion in the technical report.
Due to the number of tables and figures in the technical report, individual tables and figures are not hosted as separate documents, but as sections titled "Tables" and "Figures". Refer to the List of Tables and List of Figures in the Table of Contents for a complete list of tables and figures in these sections. The List of Tables and List of Figures list several tables and figures which appear in the main body of the text, but are not included in sections "Tables" or "Figures", specifically Tables I and II and Figures 1 through 3. For these tables and figures, refer to the chapters containing them.
Please contact the author with any questions, comments, or concerns.
Copyright © 2008 - 2011 Jason Clair Allen
Last updated: Wednesday, 25 May, 2011