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
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
Information about EUROPA can be obtained here: https://babelfish.arc.nasa.gov/trac/europa.
The documentation for EUROPA is available here: https://babelfish.arc.nasa.gov/trac/europa/wiki/EuropaDocs
A preliminary description of TREX is provided in: TREX.ICRA.08.pdf
A detailed description of the application of TREX to science missions for surveying dynamic coastal ocean processes is provided in: TREX.AAAI08.doc
A preliminary paper, on formal framework and detailed algorithms for TREX: TREX.FORMAL.pdf
Related Work
For a review of plan execution languages and systems: PLEXIL.1.pdf
References to CASPER, which utilizes the ASPEN planner (from JPL) for continuous planning and execution, can be found here: http://casper.jpl.nasa.gov/
A reference for using TITAN, which uses a language called RMPL for expressing programs and system models. TITAN.RMPL.pdf
Desired feature set
- Support teleo-reactive execution via T-REX, embedded into a ROS node
- Should have no effects on other nodes
- Should publish enough internal state that an external GUI can visualize the state of the plan and system
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:
- stubs
- nddlsim
- gazebo
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
- TREX searches up a directory tree starting at the ros param "trex/start_dir"
- TREX searches in every colon-delimited path in the ros param "trex/path"
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
Troubleshooting
- trexfast and trexdebug fail at different points during execution
It is possible that you built all of the fast dependencies, but only built trexdebug in your local package. Set ROS_TREX_DEBUG (see above) and then rosbuild your package. If the problem persists, check your package dependencies.