If you missed out on last year’s Robotics Technology Development and Deployment funding opportunity and can’t quite find a good funding match for your project from other funding sources, you may be interested to know about the National Robotics Initiative (NRI), which Obama announced this morning while touring CMU’s Robotics Institute.

From the NRI program solicitation:

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.

Billy McCafferty

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.

hookups near me | escort-review.co.uk | sex massage near me | thaisecretescorts.co.uk | massage parlour near | niru massage near me | brothelsuk.co.uk | ozzieescorts.com | brothelsnearme.com | canuckescorts.com | asian-massage-parlors.com | rubandtugnearme.com | escorts-search.com | erotic-massage-near-me.com | order hook up sites online | check out our sex tonight - Local Sex Finder | illicitaffair.co.uk | localsexnearme.com | thai-massage-near-me.com | pornstories.co.uk | massageparlournearme.co.uk | local sex

meetnfuck.uk

freesexsite.co.uk

hookersnearme.co.uk

callgirlsnearme.co.uk

hookupsnearme.co.uk

freesexlondon.co.uk

massageparlourlondon.co.uk

www.massageparlourslondon.co.uk

massageparloursmanchester.co.uk

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.”

Enjoy!
Billy McCafferty

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.

Billy McCafferty

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.)

• [1] The Model-based Approach to Autonomous Behavior: A Personal View by Geffner
• Automated Planning: Theory & Practice by Ghallab, Nau, and Traverso
• PDDL papers at https://ipc.informatik.uni-freiburg.de/PddlResources
• The Fast Downward Planning System by Helmert, with planner available at https://www.fast-downward.org
• Probabilistic Planning vs. Replanning by Little and Thiebaux
• FF-Replan: A Baseline for Probabilistic Planning by Yoon, Fern and Givan (don’t skip this one!)
• RFF: A Robust, FF-Based MDP Planning Algorithm for Generating Policis with Low Probability of Failure by Teichteil-Konigsbuch, Infantes, and Kuter
• Probabilistic Plan Recognition using off-the-shelf Classical Planners by Ramirez and Geffner
• Automatic Derivation of Memoryless Policies and Finite-State Controllers Using Classical Planners by Bonet, Palacios and Geffner

Other papers that may be of interest:

• PPDDL1.0: The Language for the Probabilistic Part of IPC-4 by Younes and Littman
• Relational Dynamic Influence Diagram Language (RDDL): Language Description by Scott Sanner; RDDL is the new probabilistic language being used for the ICAPS 2011 International Probabilistic Planning Competition (IPPC)
• Planning and acting in partially observable stochastic domains by Kaelbling, Littman, and Cassandra (this will make you truly appreciate the previous paper concerning FF-Replan)
• Hierarchical Methods for Planning under Uncertainty by Pineau
• A Translation-based Approach to Contingent Planning by Albore, Palacios, and Geffner

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.
• Fast Downward planning system (uses PDDL as the planning language)

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.

Enjoy!
Billy McCafferty

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.
• Extensions may be applied for relaxing specific (or all) assumptions for practical problem domains.

STRIPS Planning Language

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:

STRIPS(A, s, g)
p = empty plan
loop…
if s satisfies g then return p
a = [an applicable action in A, relevant for g]
if a = null, then return failure
p’ = STRIPS(A, s, precond(a))
if p’ = failure, then return failure
s = apply p’ to s
s = apply a to s
p = p + p’ + a

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.

Enjoy!
Billy McCafferty

References

[1] Russell, Stuart and Peter Norvig.  2002.  Artificial Intelligence, 2nd Ed.

[2] Nilsson, Nils and Richard Fikes.  1971.  https://www.ai.sri.com/pubs/files/tn043r-fikes71.pdf.

[3] Ghallab, Malik, Dana Nau, and Paolo Traverso.  2004. Automated Planning: Theory & Practice.

InteRRaP 4.0

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:

Architectural Implementation

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.

Enjoy!
Billy McCafferty

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.

For example, choosing the 4D/RCS methodology, and following it to a tee, will result in a purely hierarchical architecture; the Australian AI Institute (AAII) methodology results in a Procedural Reasoning System (PRS) architecture; while the Multi-Agent Scenario-Based (MASB) results in a more reactive architecture.  Accordingly, for the project at hand, I’m interested in a methodology which supports an architecture with the following attributes:

• 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).

Resource summary for MaSE and O-MaSE:

• Introduction to MaSE (Multiagent System Engineering) (pdf)
• Introduction to O-MaSE (pdf)
• MaSE designer agentTool III
• Additional publication listing
• Applying Agent Oriented Software Engineering to Cooperative Robotics

Resources which helped me make this decision include:

• Federico Bergenti’s (et. al.) Methodologies and Software Engineering for Agent Systems
• Agent-Oriented Information Systems I, II, III and IV
• An Introduction to MultiAgent Systems by Michael Wooldridge
• A Methodology to Evaluate Agent Oriented Software Engineering Techniques by Chia-En Li, et. al.

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:

• Australian AI Institute (AAII) (now defunct) developed a methodology for designing Procedural Reasoning Systems (PRS) built on a belief-desire-intention, logic paradigm.  This methodology is concisely described in Michael Wooldrige’s Introduction to MultiAgent Systems.  AAII’s methodology is strongly rooted in OOAD with extensions for agent-based design.
• 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.
• Lightly defined methodologies for the design of reactive/behavioral systems (those that Brooks likes) are defined in Introduction to AI Robotics by Robin Murphy (pg. 163) and in Behavior-Based Robotics by Ronald Arkin (pg. 155).
• 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.
• Other notable methodologies, still frequently used, include Gaia, Prometheus, and MaSE.

If you’d like to learn more about other agent-oriented methodologies, an almost comprehensive survey of options, with a good introduction to each, has been put together by the University of British Columbia in Analysis and Design of Agent-Oriented Information Systems (AOIS); or, if you’re willing to shell out some cash, see Federico Bergenti’s Methodologies and Software Engineering for Agent Systems.

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, <more algorithmic jargon omitted for brevity>, 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 labor shortage 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.

The first series of posts associated with this project will be the review of current multi-agent project development methodologies, the selection of the methodology – or more likely mix of methodologies – for this project, and a breakdown of the requirements, accordingly.

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.

Enjoy!
Billy McCafferty

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.

Billy McCafferty