Graduate research.

Original proposal.

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:

The controlling intelligence might create a navigation node to provide access to standard hardware-independent localization information. The node might detach an agent to periodically query a GPS sensor or independently determine the quality of the GPS signal. During a GPS outage or degradation of signal, the agent would inform the node, and the node would then switch to a localization algorithm using alternate sensors. The node would continue to provide standard localization information, and perhaps other information useful to the controlling intelligence such as a recommended maximum speed based on the accuracy of the alternate sensors in use. In combination with reliable map data, this strategy might have mitigated the effect of GPS drift which eliminated several teams during the 2004 and 2005 Grand Challenge Event (GCE).
The controlling intelligence might create another navigation node to provide access to low-level route information. The node might detach an agent to maintain a continuously updated list of waypoints using localization information and map data. The agent would provide the node with continuously-updated distance and bearing to the next waypoint.
The controlling intelligence might instruct the navigation node to detach an agent to determine an optimal route to reach a destination. This would allow the controlling intelligence to establish abstract long-term goals, such as drive to Cleveland without having to perform any route planning itself, and eliminate the need to re-calculate the route, for example, when the vehicle is unable to merge onto an exit or entry ramp due to traffic conditions which will not allow the vehicle to safely execute a change in bearing or speed.
The controlling intelligence might create a near sensing node to provide access to information about detected obstacles. The node might detach an agent to detect and identify obstacles entering the maximum effective range of a specific sensor or combination of sensors. The agent might communicate with another agent detached by the node to maintain a continuously updated list of all obstacles within a radius of one reaction unit1 from the challenge vehicle. The node would periodically query the agent to determine what obstacles were within a radius of one reaction unit from the challenge vehicle and perform the low-level computation necessary to determine how to avoid the obstacle, passing that information to the controlling intelligence as a series of course corrections. The reaction unit would be set by the controlling intelligence or node as necessary. This would allow the controlling intelligence to make informed decisions in the event collision is unavoidable, and a choice must be made between colliding with a chain link fence on one side of the road and a vehicle travelling at a speed of 60 mph on the other side of the road, reducing speed to focus closely on the immediate environment, or increasing the reaction unit to allow travel at increased speed.
The controlling intelligence might create several nodes of the same type, each with a different reaction unit.
The controlling intelligence may instruct a navigation node to favor the results of one agent more than others by, for example, assigning a greater weight of priority to localization information provided by an IMU than localization information provided by a GPS sensor. This might allow the controlling intelligence to inform the node that the vehicle is approaching a tunnel, mitigating the effect of GPS drift, or inform the node that it will soon have access to a more accurate GPS signal and should therefore increase its reaction unit.

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.

Key factors contributing to success.

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.

Potentially disruptive teams.

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.

A case for simulation.

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.

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.

Technical report.

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.

Contact the author.

Please contact the author with any questions, comments, or concerns.

Endnotes.

The author developed the concept of the reaction unit based on the use of the phrase “reaction unit” in popular fiction about large, autonomous vehicles called “Bolos”. As proposed by the author, the reaction unit is a variable unit of time set by the controlling intelligence, and which represents the time required for the controlling intelligence to appropriately respond to some event.

By necessity, different nodes or agents would have different reaction units. For example: the reaction unit of an agent monitoring LIDAR sensors might be set at the maximum effective range (20 m) or the maximum obstacle detection range, i.e., the range at which obstacles with 30 percent reflectivity are detected, divided by the current velocity; and the reaction unit of an agent monitoring RADAR might be set at the time required for the controlling intelligence to bring the autonomous vehicle to a complete stop on detection of an unavoidable obstacle.

In both examples above, the reaction unit is based on the relationship between velocity, distance, and time. However, there is no reason to expect the relationship between velocity, distance, and time will determine reaction unit in all cases.

The Team 2004-12 technical proposal reported an approach similar to this in concept. Team 2004-12 stated: “The vehicle state sensors are routed directly to the microcontrollers, which process and format the data for access by the main controller. The microcontrollers are used for closing the loop of the servo- controlled axes, to achieve the commanded position from the maincontroller. The accelerometers provide information about the localized terrain including tilt, ascent/descent angle, and terrain roughness, which limit vehicle ground speed, turning radius, and acceleration/deceleration. The main controller software implements a 'chassis' object which performs higher level control and access to the vehicle state sensors through the microcontrollers.” ([32], pp. 5 - 6).

Several teams reported formal architectures which are similar in concept. For example:

Team 2004-04 stated: “The system is built on the DoD Joint Architecture for Unmanned Systems (JAUS) and consists of both accepted and experimental JAUS component.....s [sic].” ([30], p. 11). Team 2004-04 participated in the 2005 GCE as Team 2005-02. Team 2005-02 stated: “The system architecture... is based on the Joint Architecture for Unmanned Systems (JAUS) Reference Architecture, Version 3.2. JAUS defines a set of reusable components and their interfaces.” ([45], p. 4) and “Recognizing that JAUS would greatly simplify system integration, [Team 2005-02] used it throughout the [challenge vehicle] development. Version 3.2 of JAUS was also augmented with experimental components and messages that defined the smart sensor messaging architecture that was implemented.” ([45], p. 5).
Team 2004-23 stated: “[The challenge vehicle] Control Logic is made up of a number of blocks: some always active and some active on demand. The established structure allows separate and somewhat independent development. It also allows continual expansion of different and more complex cases and situation to be addressed during the development cycle.” ([18], p. 4).
Team 2005-08 stated: “At the center of our architecture is a module called COMA (Contextual Operating Mode Architecture). COMA is a hybrid robot architecture which combines both reactive and deliberative architectural qualities into one architecture.” ([57], p. 15).

Refer to Table III (58K) of the thesis for a list of Team Reference Numbers and Section References (105K) for a list of References (denoted by square brackets, i.e., "[]").

Last updated: Wednesday, 25 May, 2011

Home