Search Tools

Terminology Home

Learning to Edit

edit SideBar

Foundations Workspace

This page is a sandbox for logged in editors to propose and critique components that could be included in the foundations consensus.

he purpose of this site is to start building a sense of what constitutes the core, fundamental tools, techniques, and principles underlying the discipline of Robotics.

Pursuant to that, I've started putting together a map of what those pieces might look like, what pieces we already have, and what things are still missing.

Will the core pieces of Robotics mirror the core pieces of other engineering disciplines, or the core pieces of scientific disciplines, or the core pieces of interdisciplinary studies like computer science?

In Electrical Engineering, the core concepts include the concept of current and mathematical models for how current moves through different substances and how it can be stored, and the physical components that enable engineers to design mechanisms that take advantage of those models (resistors, capacitors, batteries, wires). It includes a set of basic standard configurations and the mathematical tools used to analyze them.

Potential Pieces

Part 1 - Diversity

In Robotics, any given problem often has multiple answers. The scruffy researcher sidesteps the wall, while the neat researcher disassembles it. Both approaches will produce a functional system, but those two systems will be very different from each other, like a computer is different from a brain. Both things can compute 2+2=4, but the mechanisms they use and the hardware involved is extremely different. Only one can compute for days without a break, and (at least for now) only one can fall in love and make intuitive leaps from abstract art to emotional meaning. Roboticists face the problem that different robots function in fundamentally different ways, even when they are both solving the same problem. Any fundamentals of Robotics need to take into account the inherent diversity of solutions that fall within the field.

Part 2 - Requirements

How do you compare the results of two approaches? How do you define a specification for the system you want, such that both approaches are possible and their suitability for the task can be evaluated?

Part 3 - Evaluation

Part 4 - Behavior and Autonomy Design Principles

The software community is in the process of defining principles that help them deal with design in the face of complexity. There are several approaches that could help, including improved representations of the different aspects of the problem. In robotics, as in AI, behavior interrelations are often represented using bubbles or state machine diagrams. Similarly, the controls community often uses block diagrams to capture the flow of information through various hardware components. However, useful as these tools are, they fail to enable the designer to capture the relationships between different levels of behavior implementations, the connections between the behaviors and the robot's hardware and control options, and the specific tasks the robot is capable of accomplishing. Additional tools are necessary to capture these different perspectives on the system and their associated design constraints and potential design methodologies.

Design representations

Behaviors - can generally be represented with a state machine (many other representations are possible, but the state machine diagram is a very clean mechanism for capturing the underlying task decomposition chosen by the designer)

Physical Design - block diagrams are often used to capture this, with individual boxes representing specific components, documented interfaces tracking the information that flows into and out of each box, and wires capturing the connections between the boxes.

Skill Tree - can be used to represent the relationships between different levels of behavior implementations - documents specific relationships between higher level behaviors and the lower level state machines or individual skills that must be combined in order to achieve the higher level behavior. [ Skill tree example from the gaming community]

Control Mapping - this needs a better name, but it's a mechanism for using the available behaviors or skills (or controllers) to connect the information available (from sensors, from communications, and from on-board computation) to the control available (including actuators, parameters, data manipulation, outgoing communications, and on-board processing)

Missing Piece - we don't have a piece yet that can represent the design choices or constraints, or elucidate the design decisions, in terms of the tasks the robot is expected to do. This is still very ad hoc. Perhaps a combination of something like the Skill Tree and NIST's urban search and rescue testbed would work for this.

Part 5 - Laws, Rules, and Truths

Terminology Home - Edit - History - Print - Recent Changes - Search
Page last modified on March 23, 2016, at 11:41 AM