[Documentation] [TitleIndex] [WordIndex

TREX is a hybrid executive for integrating primitive robot actions into higher level tasks. TREX aims to simplify this integration by using a model and a planner to generate necessary actions automatically where appropriate, to enable temporal constraints to be specified and enforced, and to handle recovery from failures through replanning. TREX is experimental. We are evaluating the costs and benefits of using TREX by applying it to a range of application demonstrations on PR2. The main example of this was Milestone 2. Additional examples will be developed based on that foundation. We aim to show that new capabilities can be composed and integrated in a coherent fashion using this methodology.

Contents

About T-REX

Owner

Conor McGann

Theory of operation

TREX is a hybrid executive designed for integrating planning and control in a compositional framework. TREX was developed at the Monterey Bay Aquarium Research Institute for Adaptive Mission Control of Autonomous Underwater Vehicles. TREX has been deployed for a number of sea trials and science missions in the Monterey Bay. Some of the details of these field experiments are described here: http://www.mbari.org/autonomy/TREX/index.htm

TREX is based on the EUROPA-2 temporal planning library which is an open-source system from the NASA Ames Research Center applied to diverse problems including rover command and control, solar array control for the space station, crew activity planning and scheduling for the space station, and motion planning for the ATHLETE robot. TREX embeds EUROPA within a control loop according to a sense-plan-act paradigm. TREX allows a collection of control loops to be composed and co-ordinated in a scalable fashion.

Useful Background Material

Desired feature set

For Users (in progress)

Launching a TREX Test

TREX tests utilize an inheritance-like directory structure to organize different tests.

rosrun trex_ros launch relative/path/to/test/directory desired_launchfile_name.launch

You can also do this implicitly:

cd path/to/test
rosrun trex_ros launch desired_launchfile_name.launch

Or alternatively, you can leave off the launchfile extension:

cd path/to/test
rosrun trex_ros launch desired_launchfile_name

If you find yourself running a lot of TREX tests, you might want to add this to your bahshrc:

alias trexlaunch='rosrun trex_ros launch'

Which would then allow you to do something like:

trexlaunch path/to/test desired_launchfile_name

Running TREX in Simulation

There are three ways to simulate TREX:

Building a TREX Package with Both "Fast" and "Debug" Executables

TREX packages have the capability of simultaneously building parallel "debug" and "fast" dependency trees. This gives the developer the ability to quickly switch back and forth between a high-performance executable, and a debug executable which includes a significant amount of error-checking and other information, without having to recompile. By default, TREX executables and libraries are only built in the "fast" mode. This uses the cflags:

-O3 -DEUROPA_FAST

But an additional debug executable can be built alongside the fast tree by setting in your environment:

export ROS_TREX_DEBUG=1

This can be further disabled via:

export ROS_TREX_DEBUG=0

Debugging Workflows

Log and Playback

Console Mode

GDB

For Developers (in progress)

Writing a TREX Package CMakeLists

In order to allow a TREX package to support the fast/debug development workflow, packages building TREX executives must include some special CMake macros via the following lines in the CMakeLists.txt file:

find_ros_package(trex_ros)
include(${trex_ros_PACKAGE_PATH}/trex_build.cmake)
create_nddl_config()

To build the sources in this pakage so that they can be exported and used by another type:

set(TREX_MY_PACKAGE_NAME_FILES src/adapter_utilities.cpp
                               src/components.cpp
                               src/adapters.cpp
                               src/master_reactor.cpp)
create_trex_lib(trex_pr2_my_package_name TREX_MY_PACKAGE_NAME_FILES)

Then in order to be able to build trexfast and trexdebug based on the environment variables defined in the following section:

create_trex_executables(bin/trexfast bin/trexdebug)

For all other executables, simply use the standard procedures for ROS.

Extending the M2 Executive

The executive created for milestone 2 can be extended with a replacement master. This will expose the high-level control of navigation, door manipulation, and recharging. Internally this is done by simply including the NDDL model files, and linking against the libraries created when one builds trex_pr2. When running, either the real, simulated, or stubbed executive can be launched by delegating to the launchfiles in trex_pr2/test/base.

Configuration Files

Search Paths

Agent Config

Each TREX executable instantiates an Agent singleton. This Agent is composed of a set of reactors which interact via shared timelines. TBD: Describe composition of agent.cfg files here

For TREX Developers (in progress)

The Makefile in the trex package automatically anonymously checks out the sources for PLASMA and TREX from their respective svn repositories. IF one wishes to develop the TREX internals in the context of the ROS package, one can set the environment variable:

ROS_TREX_GOOGLE_CODE_USERNAME

This should be set to a google account that has check-in authorization. Once this is set, the Makefile will check out the code from the secure server, thus allowing inline commits. Note that if this mode is enabled, a make command will still execute an svn up if the ROS target TREX checkout is newer than the checked out revision.

FAQ

How can I customize emacs to enter c++-mode for editing nddl files? Add the following to your ~.emacs file:

(setq auto-mode-alist (cons '("\\.nddl$" . c++-mode) auto-mode-alist))

T-REX Executive Meeting Minutes

/Minutes 06-08-2009

Troubleshooting


2024-03-23 13:03