Py Trees

[About][Docs & Demos][Releases][Installation][PyTrees-Ros Ecosystem]

About

PyTrees is a python implementation of behaviour trees designed to facilitate the rapid development of medium sized decision making engines for use in fields like robotics. Brief feature list:

• Sequence, Selector, Parallel composites
• Blackboards for data sharing
• Python generators for smarter ticking over the tree graph
• Python decorators for enabling meta behaviours
• Render trees to dot graphs or visualise with ascii graphs on stdout

Docs and Demos

Core API documentation (also includes some explanation concerning the demo scripts):

If you're really looking for something more edifying than hello world examples, walk through the ros tutorials which incrementally step through the process of building a scenario handling layer for a robot.

There are also runtime visualisation tools - refer to the py_trees_ros_viewer/README as an example implementation of the underlying py_trees_js library.

Releases

• 0.y.x - first open source releases
• 1.0.x - first stable release
• 1.1.x - improvements
• 1.2.x - improvements
• 2.0.x - blackboards v2 with namespaces, access permissions and key tracking
• 2.1.x - Chooser deprecated, api housekeeping

	Devel	2.1.x	2.0.x	1.2.x	0.7.x	0.6.x
Sources
Compatibility
CI
Documentation

Installation

From ppa on Ubuntu/Bionic:

$ sudo apt install python3-py-trees

From pypi:

$ pip3 install py_trees

In a Python Virtual Environment:

$ git clone https://github.com/splintered-reality/py_trees
$ cd py_trees
$ source ./venv.bash

Build your own python3 deb:

$ git clone https://github.com/splintered-reality/py_trees
$ cd py_trees
$ source ./venv.bash
$ make deb

From the ROS2 ecosystem:

$ sudo apt install ros-<rosdistro>-py-trees

PyTrees-ROS Ecosystem

See the py_trees_ros README for the latest information on pytrees packages in the ROS ecosystem and their status.

Contributing Guidelines

Successfully collaborating on common problems is always an edifying experience that increases the desire to do more.

Pull Requests

Before Submitting

Some recommendations to help align your contribution and minimise the eventual back and forth on a PR:

• Engage in an issue thread or in the discussion section.
• Actual code in the form of a minimal PR with a status:do_not_merge label is a great tool for generating useful dialogue.

Which Branch?

• If it's a new feature, or bugfix applicable to the latest code, devel
• If it's a bugfix that can't be applied to devel, but critical for a release, point it at the release branch (e.g. release/0.6.x)

If it is a feature or bugfix that you'd like to see backported to one of the release branches, open a parallel PR for that release branch or mention that you'd like to see it backported in the original PR's description.

Coding

Running . ./venv.bash in the root of the repository can create a nice, self-contained sandbox within which you can develop and test your contribution.

The Pull Request

Be sure to state clearly in the pull request's description (this helps expedite review):

• The motivation, i.e. what problem is this solving.
• A concise summary of what was done (and why if relevant).

Apply relevant labels - one of component & type is the norm. If the pull request is not yet ready, use the status:do_not_merge label.

Style

The repository aims to conform to PEP8, please endeavour to do so. There is a simple script ./lint/flake8 that can be used to check that the code conforms. This is run as part of the CI checks.

Tests

See tests/README.md for instructions on how to run the tests all together or manually. If you are contributing new features, or bugfixing a problem that did not have coverage, it is expected that the pull requests will include a test for regression purposes.

Documentation

Documentation is auto-generated as part of the PR process, but if you do wish to make changes and check locally:

. ./venv.bash
make docs
...
The HTML pages are in doc/html.

Changelog

• Please update the Forthcoming section in the Changelog with your change and a link to your PR.
• The style should be self-explanatory.
• Do not worry about incrementing the version, releases are handled separately.

Review

Once submitted, a reviewer will be assigned. You do not need to select. If no-one has self-assigned in a reasonable time window, feel free to append a friendly bump comment to your PR.

Merging

Once the large button has gone GREEN, you or the reviewer may merge the pull request.

Releasing

If you are interested in seeing your changes make it into a release (sooner rather than later) and distributed on PyPi, PPA or via the ROS ecosystem, please make the request via a comment in your PR or in an issue.

Social Conduct

Be prepared to be tickled by noodly appendages and at all times, be froody.