Wikibooks

Embedded Control Systems Design/DARPA Challenge

< Embedded Control Systems Design

The DARPA challenge project can be categorized as “prototyping from scratch”. The actual goal lies in the development of new technologies, so the most important system design driver here is the research based creation of a working prototype from scratch. Because of the fact that the technology is fairly new, ideal design guidelines or directions are not yet determined. So the big challenge for the participating teams consists of combining components, that are not (yet) optimized to function together, and so creating a whole that functions as good as possible.

Consequences on the component level

edit

As an immediate consequence component costs, reusability, flexibility are of almost no importance in comparison to e.g. a commercial design process (e.g. the people mover). Another consequence is that the used components do not optimally work together because they are not (yet) designed to do so (on component level).

Also, because of the limited time span before the challenges it is sometimes necessary to sort of ‘gamble’ and use components that were not fully tested. The lack of experience handling this new technology also implies that too much data is logged and examined simply because it is not yet known exactly which data are important or relevant and which aren’t (comparison to the black box of an airplane, where only the most important data is logged).

Comparison to ROBOCUP

edit

A parallel can be drawn between the DARPA and ROBOCUP competitions, that are both competitive projects in the robotics field. An important difference, however, lies in the coordination of the robot(s), which in ROBOCUP happens via communication with the other robots on the field, where in DARPA the coordination is handled internally in one vehicle, without immediate communication to others. The vehicle creates a map of the world based on only its own observations and knowings (e.g. using SLAM). This again has consequences on many fields e.g. choosing to work with one or plural networks, speed of communication between the components, which data is important and which not, which aspects of the sensing of the environment happens with cameras and which with lasers,…

For all of these questions there are no unambiguous correct answers at the moment so the different teams try out different alternatives and methods that lead to new developments and insights in the technology of unmanned vehicles.

Although resembling technologies are used in both competitions, it is wrong to assume that the technologies used in the DARPA project can simply be scaled down to the ROBOCUP contenders. The components that are being used are still too large and too numerous at the moment, as well as not fit for use indoor or in high-dynamic tracking.

Do’s and Don’ts

edit

Do's

edit
  • All the participating teams have divided the design into subcategories (functionalities) that were developed simultaneously ( e.g. perception, planning, base vehicle platform). Continuous collaboration and information exchange between the subteams is of the upmost importance. Also continuous testing is a must because of the lack of information concerning some components or the interaction between them.
  • Some teams that used new or innovative technologies foresaw backup systems in case of failure. These backups usually consisted of technologies that had already proven their worth.
  • Safety is also very important in this context because few is known about several of the component(combination)s. Therefore the base has to be able to shut down the vehicle at any given time and implement the necessary safety precautions.

Don'ts

edit
  • Because of the short time available for the development, it is almost impossible to extensively investigate every possible component, scenario, … As a consequence the team sometimes has to ‘gamble’ and just choose a certain component, strategy with the risk of failure.
  • There is also no time for optimization of the entire system, nor of the separate components. This may lead to a suboptimal efficiency because e.g. some components are not fully compatible with each other.
  • In this stage, cost is of inferior importance. Factors that can suppress cost in commercial cycles such as flexibility, reusability, cheap components,… don’t have to be taken into account here because the main goal is creating a working prototype
edit
Retrieved from "https://en.wikibooks.org/w/index.php?title=Embedded_Control_Systems_Design/DARPA_Challenge&oldid=3232546"