The goal of the National Robotics Initiative is to accelerate the development and use of robots in the United States that work beside, or cooperatively with, people. Innovative robotics research and applications emphasizing the realization of such co-robots acting in direct support of and in a symbiotic relationship with human partners is supported by multiple agencies of the federal government including the National Science Foundation (NSF), the National Aeronautics and Space Administration (NASA), the National Institutes of Health (NIH), and the U.S. Department of Agriculture (USDA). The purpose of this program is the development of this next generation of robotics, to advance the capability and usability of such systems and artifacts, and to encourage existing and new communities to focus on innovative application areas. It will address the entire life cycle from fundamental research and development to industry manufacturing and deployment. Methods for the establishment and infusion of robotics in educational curricula and research to gain a better understanding of the long term social, behavioral and economic implications of co-robots across all areas of human activity are important parts of this initiative. Collaboration between academic, industry, non-profit and other organizations is strongly encouraged to establish better linkages between fundamental science and technology development, deployment and use.

Although proposals aren’t due until later this year, get started right away if you’re interested in applying…these NSF and SBIR application processes make mortgage paperwork look as simple as signing a coffee shop receipt.

In the last post, I wrote briefly on how the goal modeling task – described by the O-MaSE agent-oriented design methodology – is useful for laying out a birds eye view of what you want your (multi-agent) robot(s) to accomplish. The simple act of decomposing high level goals into sub-goals goes a long way towards defining the overall scope of what your project is aiming to achieve. But the goal modeling exercise is only one tool among many other analysis & design techniques.

Another technique that I find incredibly valuable, is the use of UML State Diagrams to visually express robot behaviors and transitions among behaviors. If you’re unfamiliar with them, state diagrams are a quick and easy way to document states a system may be in and how the system progresses (or regresses) from one state to another. It’s also very effective at describing which behaviors can be run concurrently and which require sole attention before moving on. Furthermore, state diagrams aren’t just for simple projects; indeed, they’re simplicity scales well to capture even quite sophisticated domains, such as autonomous unmanned vehicles. Reading through Junior: The Stanford Entry in the Urban Challenge, the authors define the behavior states which the vehicle can be in and how each state transitions to other states.

As another example, I’ve put together a state diagram of a proof-of-concept project I’m working on which I’m calling “Assisted Capture the Flag.” The project requirements are as follows:

After receiving a command (received as a Joint Architecture for Unmanned Systems (JAUS) command message), an autonomous, mobile robot must follow a person to a “flag room.” The robot must enter the room and search for a “flag.” The flag is an object of which the robot will have a priori knowledge; i.e., the robot will know what it’s looking for before starting on its quest. After finding and identifying the location of the flag, the robot will return to its initial location and report its finding via a JAUS message.

Although I’ve described the project at a high level, it’s difficult to visualize what’s happening and when. This is where state diagrams come into play. What follows is a state diagram describing the states and state transition that the robot may go through while attempting to achieve the overall goal of the project, finding and reporting upon the flag’s location.

I won’t go into too much detail of the state transition diagram above, but there are a few things I’d like to point out.

Immediately under the initial state of the system, the state forks into two concurrently running behaviors, localizing itself within the environment and awaiting/parsing a JAUS command for execution. After both of those complete, the system then, and only then, joins and progresses to the next state of “Locate Person to Follow.”

There are two “composite states” shown: “Find Flag Room” and “Find Flag.” Each of these contain concurrent behaviors in order to achieve the objective of the composite state. What makes these different than forks/joins, is that A) not all states must “complete” before progressing to the next state, and B) there exist multiple exit points to “short circuit” the entire composite state.

A key element, to ensure that the state diagram doesn’t get too bogged down with detail, is to focus on expressing behavior and avoiding how the behavior is to be accomplished. For example, one could hypothetically break the “Locate Flag” down into many sub-states, such as “Search for Flag with Dominant Orientation Templates (DOT).” Although this is a technique the project will likely include, breaking the state diagram down to this level goes beyond behavior, instead describing how a behavior is to be achieved.

Ideally, a behavior should be something that an external observer note the robot is doing, regardless of how it’s pulling it off. (Think about having to watch some squirrels for a few hours and note distinct behaviors…there’s a fun family activity for ya this weekend.) For example, the “Enter Doorway” state exemplifies this principle; an observer could easily note that the robot is working on getting through a doorway as an overall behavior of the robot. On the other hand, the “SLAM Path” state is not something that an observer would likely know the robot is doing while within the composite state “Find the Flag Room”; yet, it’s a concurrent, internalized behavior which must occur in order to return to its initial location at a later time. One justification of its inclusion in the diagram is its placement within a composite state; thereby, encapsulating it within an externally observable behavior. But, regardless, especially in mobile robotics, if you’re adding a state which cannot be easily discerned by an external observer, you should ask yourself if it is truly a separate state or if it is simply describing a detail of how the state is being carried out. Keeping the state diagram clear of such details makes it easier to adapt to implementation changes later in the process. But as with all rules of thumb in software development, “it depends.”

O-MaSE is an agent-oriented analysis & design (AOAD) methodology. I have found it to be a particularly powerful tool, in the development of project work, due to its flexibility of use and ability to handle single and multi-agent domains equally well. For example, unlike many other methodologies (which I’ll leave nameless to avoid stoking any fires), O-MaSE is very adaptable to be easily slimmed down for smaller projects while having requirements and analysis support for quite complicated, multi-agent domains (e.g., RoboCup teams). Additionally, O-MaSE’s initial requirement phases focus more on system goals, rather than agent goals. In doing so, it is easier to model multi-agent domains without becoming prematurely bogged down in the details of which responsibilities belong to which agent.

As I’ve discussed this methodology, and resources for learning more about it, in a previous post, I’d like to instead share an example of how I’ve used it for a proof-of-concept project I’m putting together as a stepping stone towards higher aspirations. This first step in O-MaSE is goal modeling. The methodology defines a goal as an overall function of the organization; a goal could be seen as a desirable situation or the objective of a computational process. The “Model Goal” task focuses on transforming system requirements into goals and sub-goals represented as an AND/OR decomposition/goal tree.

An AND/OR goal tree is simply a class diagram where each class is stereotyped as “<< goal >>” and sub-goals are shown hierarchically. It is an AND/OR tree because while some goals may require all of its sub-goals to be completed in order to be satisfied, other goals may only require one of its subgoals to be completed to be satisfied. The UML relationship aggregation notation is used to note that all sub-goals must be satisfied to consider the parent goal satisfied, while the UML generalization (inheritance) notations is used to note that only one sub-goal must be satisfied.

It’s certainly easier to understand by looking at an example. The proof-of-concept project that I’m working is an assisted capture the flag game. The idea is that a mobile robot must follow a person to a particular room and search the room for a flag, then returning to its initial location to report the results. Below is the AND/OR goal tree that I put together to represent the goals of the system, using Enterprise Architect. (Click the image to see it full-size.)

As indicated, the overall system goal is “Find Flag.” To achieve this, the goal is broken down again and again into sub-goals. The level of granularity to which you take the decomposition is certainly subjective, but it should continue to be done until the decomposition process is no longer resulting in new information, or is beginning to express how goals are to be achieved. Once you cross the threshhold of defining how the goals are to be achieved, rather then simply defining the goals themselves, you’re switching gears from goal-modeling to plan-modeling. In fact, even in this example, the line between goals and plans becomes gray after the third tier; e.g., “Identify Person to Follow,” “Follow Person,” and “SLAM Path Taken” could be argued as being closer to plans than goals. That was a clear indication to me that I had gone “far enough” and should now turn attentions towards analyzing plans for achieving the goals presented.

In business software development, the more experienced a developer becomes, the less – he realizes – he knows. The only developers I know, for the most part, who believe they’re truly gurus in their profession have around three years experience…after that comes a few years of realizing that they’ve only seen the tip of the iceberg to becoming of craftsman in the art of software development. But developing software for robotics takes this humbling lesson to staggering new heights.

After writing a line-follower way back when, I (thought I) had my “Ah ha, I’ve got it!” moment. I’ve had a long series of those moments, only to be dramatically humbled again and again when trying to take on increasing complexity. The most recent, of those humbling moments, came when I began working on the planning layer of a project of mine. This post is to provide research guidance to others who may be sinking their teeth into this realm.

There are three primary approaches to planning [1]:

Programming-based approach which involves anticipating every planning decision and hard-coding the planning mechanism. This approach, while terrific on smaller problems, does not scale well, is tedious to develop and maintain, and becomes brittle as complexity increases.

Learning-based approach which leverages learning algorithms to “teach” the control layer how to approach particular problems. (See Ethem Alpaydin’s Introduction to Machine Learning, 2nd Ed. for a foray down this path.)

Model-based approach which deduces the planning solution from a model of the planning problem. This approach then has a number of general techniques, including:

Classical planning using a basic model using a planning language such as STRIPS, PDDL (the subject of a future post), ADL, or NDDL,

Markov Decision Process (MDP) where the model is represented as state transition probabilities and assumes the state is fully observable (discoverable with 100% confidence), and

Partially Observable MDP (POMDP) where the state is assumed to be not fully observable.

My current research focus is on emulating probabilistic planning (MDP) using classical planning techniques. Accordingly, I’d like to share a few key papers and resources, which I have found, which have been of great assistance in my efforts to better understand the planning domain and to prepare for applying it to real-world project work. (Listed in suggested order to be read.)

As for planning tools, you’ll certainly want to check out the following as well:

Teleo-Reactive Executive (T-REX) hybrid executive for autonomous robotics (uses NDDL as the planning language). It should be duly noted that TREX has been successfully used on a number of real-world projects.

This should get you going in the right direction for reading up on background materials and emerging research areas in the realm of planning. Certainly let me know if you have other tips or references, I’m particularly interested in other planning tools being used in real-world scenarios.

Planning concerns itself with determining future actions to achieve goals. One, albeit naïve, approach to planning is to explicitly represent plans via ifs and for loops, laying out the sequential via low-level code. But for better flexibility and scalability, if warranted for the task at hand, it’s preferred to represent plans less rigidly; plans that can be more easily adapted to changing and unforeseen circumstances.

Flexible plans, by definition, are not fully constrained by a preset order before execution – a planning algorithm is leveraged to assemble a plan, from a set of available actions, to achieve goals. Certainly, a challenge is in representing plans formally enough as to be understood and searchable by a planning engine. As described in Artificial Intelligence [1], “the key is to find a language that is expressive enough to describe a wide variety of problems, but restrictive enough to allow efficient algorithms to operate over it.” An early language towards this aim is STRIPS; a planning language providing the foundational backbone of many modern day planning representation techniques.

(For historical clarification, STRIPS (Stanford Research Institute Problem Solver) was an automated planner developed in 1971 and also used to name the language providing input to the planner [2].)

Classical Planning

When studying planning techniques, it’s appropriate to begin in the realm of classical planning environments. These environments apply a number of restrictive assumptions to a planning problem:

The planning problem has a finite set of states.

It is fully observable: the state of the system is known with 100% confidence.

It is deterministic: for every action applicable to a state, and applied, the system is brought to a single other state.

It is static: the system state remains constant between applied actions.

It is discrete: actions and events are instantaneous state transitions – they have no duration.

A solution plan is an ordered, finite sequence of actions.

Although it’s difficult to wedge real-world problems into these assumptions, there are practical motivations for starting with such classical planning environments:

When faced with difficult problems, simplified models help to work out well-founded approaches.

Classical planning has served as the foundation for scalable, real-world approaches.

STRIPS is a classical planning language, representing plan components as states, goals, and actions, allowing algorithms to parse the logical structure of the planning problem to provide a solution.

In STRIPS, state is represented as a conjunction of positive literals. Positive literals may be a propositional literal (e.g., Big ^ Tall) or a first-order literal (e.g., At(Billy, Desk)). The positive literals must be grounded – may not contain a variable (e.g., At(x, Desk)) – and must be function-free – may not invoke a function to calculate a value (e.g., At(Father(Billy), Desk)). Any state conditions that are not mentioned are assumed false.

The goal is also represented as a conjunction of positive, ground literals. A state satisfies a goal if the state contains all of the conjuncted literals in the goal; e.g., Stacked ^ Ordered ^ Purchased satisfies Ordered ^ Stacked.

Actions (or operators) are defined by action schemas, each consisting of three parts:

The action name and any parameters.

Preconditions which must hold before the action can be executed. Preconditions are represented as a conjunction of function-free, positive literals. Any variables in a precondition must appear in the action’s parameter list.

Effects which describe how the state of the environment changes when the action is executed. Effects are represented as a conjunction of function-free literals. Any variables in a precondition must appear in the action’s parameter list. Any world state not explicitly impacted by the action schema’s effect is assumed to remain unchanged.

The following, simple action schema describes the action of moving a box from location x to location y:

Action: MoveBox(x, y)
Precond: BoxAt(x)
Effect: BoxAt(y), ¬ BoxAt(x)

If an action is applied, but the current state of the system does not meet the necessary preconditions, then the action has no effect. But if an action is successfully applied, then any positive literals, in the effect, are added to the current state of the world; correspondingly, any negative literals, in the effect, result in the removal of the corresponding positive literals from the state of the world.

For example, in the action schema above, the effect would result in the proposition BoxAt(y) being added to the known state of the world, while BoxAt(x) would be removed from the known state of the world. (Recall that state only includes positive literals, so a negation effect results in the removal of positive literals.) Note also that positive effects can not get duplicated in state; likewise, a negative of a proposition that is not currently in state is simply ignored. For example, if Open(x) was not previously part of the state, ¬ Open(x) would have no effect.

A STRIPS problem includes the complete (but relevant) initial state of the world, the goal state(s), and action schemas. A STRIPS algorithm should then be able to accept such a problem, returning a solution. The solution is simply an action sequence that, when applied to the initial state, results in a state which satisfies the goal.

STRIPS Planning Algorithm

As previously referenced, STRIPS began as an automated planning algorithm and has double-meaning to describe the language (described above) used to provide input to that algorithm. While the algorithm does not scale well to real-world problems, it, like the language, serves as a foundational starting point to developing and understanding more powerful automated planning algorithms. The STRIPS algorithm [3] is found below, followed by a brief commentary:

In the above STRIPS algorithm, A represents all of the possible, grounded actions (i.e., action schemas with variables replaced with values), while s is the current state, and g is the goal state.

Critically important to note is that this algorithm is a backward-search algorithm. In other words, the goal state of the planning problem is fed into the algorithm as s, while the initial state of the planning problem is provided as g. The returned solution, if any, simply needs to be reversed to provide the solution to the planning problem. Simply put, it works backwards from the goal to figure out a logical path to get there.

There’s certainly more to the STRIPS algorithm, detailed nicely in [3], than the basic explanation outlined here, but this should give a cursory introduction to how the STRIPS language can be used to define a planning problem and be searched to find a sound solution.

While the STRIPS language provides a good starting point for representing planning problems, it is far too simplistic to handle real–world planning domains. Accordingly, the Planning Definition Domain Language (PDDL) has emerged as the de facto means for formerly representing sophisticated planning problems. PDDL will the subject of our next post.

Over the years, a number of well defined architectures have been proposed for a wide assortment of project domains; a few examples were described in Architectural Paradigms of Robotic Control. As described, the architectural approaches can typically be categorized as follows:

Reactive architectures which emphasize reacting to the immediate world environment without keeping an internal world model representation,

Deliberative architectures which focus on maintaining a detailed internal world model, carefully planning actions to interact with the environment, and a layered system to disseminate plans to actuators,

Interactive architectures which focus on communication and cooperation within multi-agent systems, and

As with any project, a challenge is picking the appropriate architecture for the task at hand. Thankfully, much work has been done on analyzing agent-oriented architectures to assist development teams with making this selection. While a little dated, Jörg Müller et al.’s Intelligent Agents V provides a solid introduction to analyzing architectural approaches and comparing them to one another for particular project needs. For the project at hand, only those architectures which were hybrid, supporting deliberative-reaction capabilities, were considered. Furthermore, those supporting multi-agent coordination were particularly preferred. Specifically, the following architectures were considered in detail: RAPs/ATLANTIS/3T, Lyons & Hendriks, TouringMachines, InteRRaP, SimAgent, and NMRA. Without going into details as to why the choice was made, InteRRaP has been selected as the target architectural design for the project, providing a good balance of reactive and deliberative capabilities while supporting multi-agent communication and cooperation. This post introduces the major concepts of InteRRaP and the effects of this architectural selection on the O-MaSE project methodology.

InteRRaP 4.0

InteRRaP is a hybrid, belief-desire-intention (BDI) architecture supporting the modeling of reactive, goal-directed, and interacting agents by providing 1) a set of hierarchical control layers, 2) a knowledge base that supports the representation of different abstraction levels of knowledge, and 3) a well-defined control structure that ensures coherent interaction among the control layers. [1] For completeness, BDI should be further described. A BDI approach is broken down, conceptually, as the following mental categories [2]:

Beliefs of an agent expressing its expectations about the current state of the world;

Desire expressing preferences over future world states or courses of action;

Goals describing subsets of desires that an agent might pursue (including reactive, local, and social goals);

Intention expresses the specific goal (or set of goals) to commit to; and

Plans representing sets of intentions (each representing a partial plan) to be executed to achieve goals.

It should be noted that InteRRaP is not a traditional BDI architecture; it attempts to leverage the advantages of a BDI architecture as a component of its hybrid approach to structuring multi-agent systems, distributing the mental categories over three layers. For example, beliefs are split into three layered models:

A world model containing beliefs about the environment,

A mental model holding meta-level beliefs the agent has about itself, and

A social model describing meta-level beliefs about other agents.

For action deliberation and execution, InteRRaP incorporates three hierarchical control layers described as:

A local-planning layer that provides means-ends reasoning of local tasks and produces-goal directed behavior.

A cooperative-planning layer enabling agent reasoning about other agents and supporting coordinated action among agents.

The initiation of actions are triggered by specific situations, which are specific subsets of the agents beliefs. Similar to the breakdown of belief modeling and control layering, situations are classified into three separate categories:

Behavioral situations which are reactive situations derived purely from the world model,

Local planning situations which are derived from information from both the world and mental model, and

Cooperative planning situations which are derived from information from the world, mental and social models.

Architectural Implementation

The implementation of the control architecture itself is based on the principles of:

Layered control having different level of abstraction,

Layered knowledge base allowing restriction of the amount of information available to lower control layers,

Bottom-up activation wherein the next layer up only gains control if the layer below is unable to deal with the recognized situation, and

Top-down execution wherein each layer uses operational primitives (or Patterns of Behavior (PoB)) defined in the next lower layer to achieve its goals.

The diagram above [3] illustrates how the underlying principles were used in implementing the control architecture of InteRRaP. There are three primary modules: a world interface providing the agent’s perception, communication, and action interfaces with its environment; a knowledge base partitioned into three layers, consisting of the world, mental and social models described previously; and a control unit organized into the three control layers described previously (behavior-based, local-planning, and cooperative-planning). Furthermore, each control layer has two processes including a situation recognition and goal activation (SG) process and a planning, schedule, and execution (PS) process. Control moves from the behavior layer up until a suitable layer competent for execution is found; action is then directed back down to the behavior layer which is the only layer with direct access to sensors and actuators.

To help limit the scope of responsibility of each layer, each is limited to a respective portion of the knowledge base. For example, the behavior-based layer only has access to the world model and can only recognize situations warranting a purely reactive response. Conversely, the cooperative planning layer has access to the social, mental and world models, allowing it to recognize more complex situations and to plan and pass down execution commands, accordingly.

Implications on O-MaSE

As described previously, O-MaSE is a flexible methodology for the definition and design of multi-agent systems. While choosing InteRRaP as a preferred architecture does not preclude the use of any O-MaSE tasks, it implies the introduction of a new task: Model Situations Task. This task would define the situations which may be recognized for taking action upon. Going a step further along these lines, a supporting O-MaSE task may be introduced – Refine Situations Task – to better assign which control layers should be responsible for recognizing and responding to each situation.

This introductory post to InteRRaP only touches upon the major components of this architectural approach in an effort to concisely describe its intent and organization. The interested reader is strongly encouraged to read the references found at the bottom of this post for more detailed information. In the next post, we’ll look at some examples of how O-MaSE was used to define requirements in alignment with the selected InteRRaP architecture.

It should be noted that it is not my intention to follow InteRRaP “to a tee”; rather, I find its overall organization to be very logical and will use as inspiration for structuring current project work; for example, I could see trex-autonomy as being a suitable approach for implementing the behavior-based and local-planning layers without negating the underlying principles of InteRRaP, nor its implied organization. Time (and a lot of trial-and-error) will tell.

In selecting an appropriate agent-oriented analysis & design (AOAD) methodology, the project delivery team must carefully consider the ramifications of the methodology on the final solution and if the methodology’s presumed architectural paradigm, if there is one, is in line with the team’s goals for the project. With traditional object-oriented analysis & design (OOAD) methodologies – e.g., Domain Driven Design, Model Driven Engineering, Larman’s Applying UML and Patterns – the OOAD methodologies don’t typically have much presumption on the final architectural solution; one could use almost any OOAD methodology while resulting in a wide array of architectural implementations. Conversely, because AOAD methodologies not only assume a behavioral focus but often assume how those behaviors are organized, the selected AOAD methodology can have a significant impact on the architectural solution.

The architectural solution must support deliberative planning to consider resource and environmental constraints and plan, accordingly.

It must support reactive agents that will leverage a finite state machine to transition between behaviors.

It must support interaction with other agents for cooperation and reactive coordination.

These basic architectural assumptions suggest a methodology which will result in a hybrid architecture supporting multi-agent coordination and interaction. (It’s already sounding like an InteRRaP or Alliance / L-Alliance agent architecture to support these needs.)

Ideally, I want to avoid picking a methodology which will dictate the agent architecture without negating the methodology’s usefulness. Accordingly, three general agent-oriented methodologies, which do not mandate a particular agent-architecture, were considered in detail: Tropos, MaSE (Multiagent System Engineering) & O-MaSE, and Gaia. Gaia was eliminated due to the fact that while it supports high-level design, it does not provide much guidance for detailed and lower-level implementation design. Both Tropos and MaSE provide good project life-cycle guidance and support high-level and detailed design. A major plus to Tropos is Formal Tropos, which includes support for symbolic model checking with T-Tool. It’s also built upon Eric Yu’s i* framework described in Agent-Oriented Modeling: Software versus the World. But ultimately, MaSE was selected as the methodology of choice for the following reasons:

MaSE exhibits the same benefits as the other considered architectures: good project life-cycle support, open-ended agent-architecture, models and guidance for both high-level and detailed design.

MaSE is in active development with the recent extension O-MaSE and appears to widely referenced in various publications.

MaSE has a positively-reviewed, design tool available as agentTool III.

MaSE has been proven in cooperative, multi-agent robotics (reference below).

So with the methodology selected, it’s time to look at picking an architectural approach to the multi-agent system in the next post. A major advantage of the O-MaSE methodology is that it is built upon the premise of being a flexible methodology allowing one to pick and choose a number of techniques to assist in defining requirements. Accordingly, by knowing more about the intended architectural approach, we’ll be able to customize the O-MaSE methodology to better align the efforts with the end result.

Enjoy!
Billy McCafferty

This post is one in a series for the commercial development of a multi-agent, robotic, bell pepper picking team with scalable planning, supporting unstructured, outdoor horticulture. If you’d like to follow along, be sure to subscribe to SharpRobotica.com. In addition to commenting on posts, feel free to contact me anytime if you would like to discuss collaboration or funding prospects.

Object oriented analysis and design (OOAD) methodologies are well established, offering a plethora of methodologies depending on the needs of the project and the skills of the development team; e.g., eXtreme Programming, Domain Driven Design, Agile Modeling, and Crystal Clear. (Scrum is omitted as it lacks adequate direction for OOAD; albeit, it’s a terrific project management methodology.) Indeed, a pivotal element of any successful software development endeavor is the careful selection of a methodology for defining project requirements and designing the solution. A challenge with applying traditional OOAD methodology to robot and multi-agent control systems is the traditional methodologies’ bias towards defining the structure and properties of objects and applying behaviors to those objects as a secondary concern. But in the world of robotics, the emphasis needs to be squarely placed on behavior as the centerpiece of design. This does not imply that the methodology will result in a behavior-based, subsumption architecture, but instead that the robot’s goal-driven and event-driven behavior is at the very core of what is being modeled. Accordingly, a number of agent-oriented analysis and design (AOAD) methodologies have emerged over the years in response to this disconnect between traditional OOAD methodologies and the needs of agent-oriented systems.

What follows is a brief listing of a few notable AOAD methodologies representing a wide cross-section of approaches:

The Tropos methodology is a full project life-cycle methodology based on actors, goals, plans, resources, dependencies, capabilities, and beliefs. A Tropos project begins by defining the actor and dependency models which reflect “who” is involved and the dependencies between the actors. Project design continues by defining a goal model and a respective plan model for describing “canned plans” for achieving the goals.

The 4D/RCS methodology describes a comprehensive methodology for the design of systems built upon the guidance of the 4D/RCS reference architecture. Incidentally, although intended for 4D/RCS projects, the methodology itself is quite compatible with other layered architectures, such as 3T and other hybrid architectural solutions.

Although more of an architectural model than a methodology, Jörg Müller’s The Design of Intelligent Agents includes a couple of case studies on defining requirements for various layers of an InteRRaP architectural solution. These complement any methodology you may pick as further examples of taking an agent-oriented approach to requirements definition.

In the next post, we’ll examine some of the architectural constraints of our project and determine which AOAD methodology will be right.

Enjoy!
Billy McCafferty

This post is one in a series for the commercial development of a multi-agent, robotic, bell pepper picking team with scalable planning, supporting unstructured, outdoor horticulture. If you’d like to follow along, be sure to subscribe to SharpRobotica.com. In addition to commenting on posts, feel free to contact me anytime if you would like to discuss collaboration or funding prospects.

Automated Planning, Dominant Orientation Templates, Differential Evolution, Locally Adaptive Regression Kernels, Elastic Band Path Optimization, Open Motion Planning, Policy Learning, SLAM, , and other niche algorithms are interesting to learn in isolation, but at some point it’s time to put the puzzle pieces together and produce something useful. For the past few months, I’ve been formulating a project for my company, Denver-based Codai, that has commercial potential, fills a much needed industry gap, and attempts to bring together emerging algorithms and off the shelf hardware for (hopefully) effective results. Much of the initial phases of project development will be shared here on Sharp Robotica, from discussing the methodology for defining requirements and the high-level requirements themselves; to the algorithms for control, planning and reactive behavior; to the implementation decisions for hardware, drivers, application integration, and implementation. My intention for doing so, at the risk of inciting competition, is to use the community as a sounding board for ideas and implementation details, to share insights which may prove useful to the robotics community, and to find others with similar goals for potential collaboration and/or funding opportunities. Concisely, the project is the development of a multi-agent, robotic, bell pepper picking team with scalable planning, supporting unstructured, outdoor horticulture. (How’s that for a niche?)

With an ever increasing laborshortage and cost for harvesting fruits and vegetables, opportunities are ripe (get it?) for the introduction of mechanization solutions to assist farming operations better prepare for labor resourcing needs, more effectively predict harvesting costs, and scale more efficiently, resulting in greater yields and productivity. But while labor challenges are growing, decreasing costs in hardware along with a maturing set of robust, software algorithms are enabling a “tipping point” for the practical introduction of task-specific robotics to assist in such harvesting activities, specifically for the harvesting of bell peppers as is the focus of this work.

Current research efforts in the harvesting of bell peppers, and other short-plant commodities such as strawberries, rely upon all-in-one harvesting machines which are bulky, prohibitively expensive, and largely dependent upon specialized environments, such as greenhouses with predictive lighting and plant configurations. Further challenges hinder this single-point-of-failure approach, such as short power supplies along with expensive and time consuming repairs. This research project suggests a better way.

This project postulates that the widespread adoption of the mechanization of bell pepper harvesting will only become attainable with cheaper, more reliable robotic solutions which can easily scale to accommodate farming operations both large and small while supporting outdoor horticulture. Accordingly, at its core, this project proposes the development of two task-specific robots, a “harvester” to identify and collect bell peppers from plants and a “runner” to return harvested bell peppers to an aggregation point and to re-supply the harvester with power. The primary objective in the development of the robots is for them to be light, cheap and fast, using emerging software algorithms and techniques, such as person following, point cloud analysis, flexible object identification, and automated planning, for effective team coordination and robust pepper identification and harvesting in unstructured, outdoor horticulture. For scalability, the project will exhibit the ability to accommodate additional harvesters and runners into the harvesting plan, thus facilitating a dynamic team for increased productivity.

This objective will demonstrate that low-cost, robotic bell pepper harvesting is attainable, providing a practical alternative or augmentation to ever increasing labor challenges while better enabling farming operations to have predictable control over production.

If you haven’t already done so, be sure to subscribe to SharpRobotica.com to follow the project. Also, in addition to commenting on posts, feel free to contact me anytime if you would like to discuss collaboration or funding possibilities.

An argument that interests me is the debate concerning what value simulations provide for researching new ideas and garnering new knowledge. As Herbert Simon succinctly puts the argument in The Sciences of the Artificial, “How can a simulation ever tell us anything that we do not already know?” The arguments backing this skeptic’s question are that 1) simulations are no better than the assumptions they are built on and that 2) simulations can only do what they’ve been programmed to do.

Simon continues with a response which is far more concise and sound than I could express in my own words…

There are two related ways in which simulation can provide new knowledge. … Even when we have correct premises, it may be very difficult to discover what they imply. … [We] must tease out the consequences of our assumptions. … [For example] attempts have been under way for some years to apply [simulation to weather and weather prediction. While simulations for this environment are] greatly oversimplified, the idea is that we already know the correct basic assumptions, the local atmospheric equations, but we need the computer to work out the implications of the interactions of vast numbers of variables starting from complicated initial conditions.

Accordingly, simulations provide a means to create “canned” environments, or scenarios with known initial conditions, and to watch the implications of our assumptions play out on those conditions. Obviously, simulations are also immensely assistive as a means to test out new ideas without investing large amounts of time and money into speculative hardware requirements.

Certainly a challenge with the creation of any simulation for the purposes of knowledge creation is 1) the realistic re-creation of the environment and 2) the realistic re-creation of the agent which will be responding to stimuli and/or acting upon the environment. Indeed, one can find him/herself spending as much time on generating the environment and simulated agent as they might in actually building the agent itself (e.g., a mobile robot). Some vendors have taken great strides in recognizing this challenge and accommodating users, accordingly. For example, while simplistic, Lego NXT robots may be designed within Lego Digital Designer and converted into Robot Operating System (ROS) compatible models using the NXT-ROS stack to rapidly produce and simulate an assortment of ideas in differing environments. Increasingly available tools and solutions, such as this, are allowing vastly more complicated scenarios to be brought into varying, simulated environments for feasibility testing of new ideas. (If you’d like to discover many other available simulation environments, I invite you to also take a look at Simulations Environments for Mobile Robotics.)

So while it’s difficult to replace the feedback and learning of “the real-world,” simulations still provide a veritable proving ground for observing the implications that well-grounded assumptions, with known initial conditions, have in a wide array of possible environments, with sometimes surprisingly real-world results.