mirte_lc_labclean package

Submodules

• mirte_lc_labclean.behaviours module
• mirte_lc_labclean.labclean_tree module
• mirte_lc_labclean.mirte_lc module
• mirte_lc_labclean.test_node module

Module contents

mirte_lc_labclean package for ROS2 lab cleaning behaviours and dashboard control.

This package provides behaviour tree classes, a ROS2 node for managing exploration-to-coverage transitions, a Qt dashboard backend, and a simple test node for verifying sensor-driven motion.

class mirte_lc_labclean.CoverageTask(name: str, planner: str)

Bases: py_trees.behaviour.Behaviour

Send a coverage navigation goal and monitor until complete.

Args:

name (str): Name of the behaviour. planner (str): Planner type, e.g. skeleton.

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.FlashLedStrip(name: str, colour: list = [0.0, 0.0, 1.0])

Bases: py_trees.behaviour.Behaviour

Flash the LED strip with a colour command.

Args:

name (str): Name of the behaviour. colour (list[float]): RGB colour values in range [0.0, 1.0].

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.GetPlanarObjects(name: str, blackboard_key: str = 'planar_objects_detected_array')

Bases: py_trees.behaviour.Behaviour

Query the planar object detection service and write to the blackboard.

Args:

name (str): Name of the behaviour. blackboard_key (str): Blackboard key to write detected objects into.

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.LabcleanManager

Bases: rclpy.node.Node

Manage the transition from exploration to lab coverage navigation.

The manager subscribes to exploration status updates and sends a NavigateCoverage action goal when exploration completes.

exploration_callback(msg)

Handle exploration status updates.

Args:

msg (explore_lite_msgs.msg.ExploreStatus): Exploration status message.

goal_response_callback(future)

Handle the goal response from the coverage navigation action server.

Args:

future: The future returned by send_goal_async.

nav_feedback_callback(feedback_msg)

Log progress updates from the coverage navigation action.

Args:

feedback_msg: The feedback message from the action server.

send_coverage_goal()

Send a coverage navigation goal.

The goal uses the SKELETON planner and enables verbose feedback.

class mirte_lc_labclean.MoveArm(name: str, blackboard_key: Optional[str] = None, target_position=None, predefined_pose: Optional[str] = None)

Bases: py_trees.behaviour.Behaviour

Move the robot arm to a named or explicit target pose.

Returns SUCCESS only when the action server confirms the goal succeeded.

Args:

name (str): Name of the behaviour. blackboard_key (str, optional): Blackboard key holding a target pose. target_position (tuple[float, float, float], optional): Explicit XYZ. predefined_pose (str, optional): Name of a predefined arm pose.

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.NavigateToPosition(name: str, blackboard_key: Optional[str] = None, target_position=None, goal_tolerance: float = 0.5, stuck_timeout: float = 20.0, nav2_timeout: float = 5.0, standoff: float = 0.4)

Bases: py_trees.behaviour.Behaviour

Navigate the robot to a target position.

Sends a Nav2 goal and monitors progress. Handles TF not ready, Nav2 not ready, feedback dropout, and genuine stuck situations gracefully.

Args:

name (str): Name of the behaviour. blackboard_key (str, optional): Blackboard key containing a list of

DetectedObject messages. The closest object is used as the target.

target_position (list[float] | tuple[float, float], optional): Fixed

XY position in the map frame. Used when blackboard_key is None.

goal_tolerance (float): Distance in metres at which to consider the

goal reached and cancel early. Default 0.5m.

stuck_timeout (float): Seconds without progress before cancelling.

Default 20.0s.

nav2_timeout (float): Seconds to wait for Nav2 to become active.

Default 5.0s.

standoff (float): Metres to stop short of a detected object so the

robot doesn’t drive into it. Default 0.4m.

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.PickObject(name: str, blackboard_key: str = 'planar_objects_detected_array')

Bases: py_trees.behaviour.Behaviour

Pick the closest detected object using a multi-step arm sequence.

Steps: approach → open → dive → grip → place → let_go → standby

Args:

name (str): Name of the behaviour. blackboard_key (str): Blackboard key holding a list of DetectedObject.

STEPS = ['approach', 'open', 'dive', 'grip', 'place', 'let_go', 'standby']

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

class mirte_lc_labclean.SetCoverageStatus(name: str, requested_status: str)

Bases: py_trees.behaviour.Behaviour

Send a pause/resume/stop command to the coverage navigation server.

Args:

name (str): Name of the behaviour. requested_status (str): One of pause, resume, or stop.

initialise()

Execute user specified instructions prior to commencement of a new round of activity.

Users should override this method to perform any necessary initialising/clearing/resetting of variables prior to a new round of activity for the behaviour.

This method is automatically called via the py_trees.behaviour.Behaviour.tick() method whenever the behaviour is not RUNNING.

… note:: This method can be called more than once in the lifetime of a tree!

setup(**kwargs)

Set up and verify infrastructure (middleware connections, etc) is available.

Users should override this method for any configuration and/or validation that is necessary prior to ticking the tree. Such construction is best done here rather than in __init__ since there is no guarantee at __init__ that the infrastructure is ready or even available (e.g. you may be just rendering dot graphs of the trees, no robot around).

Examples:

• establishing a middleware connection to a sensor or driver

• ensuring a sensor or driver is in a ‘ready’ state

This method will typically be called before a tree’s first tick as this gives the application time to check and verify that everything is in a ready state before executing. This is especially important given that a tree does not always tick every behaviour and if not checked up-front, it may be some time before discovering a behaviour was in a broken state.

Tip

When to use __init__(), setup() and when to use initialise()?

Use __init__() for configuration of non-runtime dependencies (e.g. no middleware).

Use setup() for one-offs or to get early signal that everything (e.g. middleware) is ready to go.

Use initialise() for just-in-time configurations and/or checks.

There are times when it makes sense to do all three. For example, pythonic variable configuration in __init__(), middleware service client creation / server existence checks in setup() and a just-in-time check to ensure the server is still available in initialise().

Tip

Faults are notified to the user of the behaviour via exceptions. Choice of exception to use is left to the user.

Warning

The kwargs argument is for distributing objects at runtime to behaviours before ticking. For example, a simulator instance with which behaviours can interact with the simulator’s python api, a ros2 node for setting up communications. Use sparingly, as this is not proof against keyword conflicts amongst disparate libraries of behaviours.

Args:

**kwargs: distribute arguments to this

behaviour and in turn, all of its children

Raises:

Exception: if this behaviour has a fault in construction or configuration

See also

py_trees.behaviour.Behaviour.shutdown()

status_commands = {'pause': 0, 'resume': 1, 'stop': 2}

update()

Execute user specified instructions when the behaviour is ticked.

Users should override this method to perform any logic required to arrive at a decision on the behaviour’s new status. It is the primary worker function called by the tick() mechanism.

Returns:

the behaviour’s new status Status

Tip

This method should be almost instantaneous and non-blocking

See also

py_trees.behaviour.Behaviour.tick()

mirte_lc_labclean.create_root() → py_trees.behaviour.Behaviour

Build the LabClean behaviour tree root.

Tree structure:

[Parallel] Lab Cleanup Root ├── [Sequence] Topics2BB │ ├── Init Cloud Objects │ ├── Init Planar Objects │ ├── Init Explore Status │ └── [Parallel] Subscribers │ ├── Exploration2BB │ ├── Cancel2BB │ ├── Start2BB │ ├── Battery2BB │ ├── Detectedcloud2BB │ └── DetectedClasses2BB ├── [Selector] Explore or Cover │ ├── [EternalGuard] Explored? │ │ └── CoverageTask │ └── Idle └── [Selector] Tasks

├── [EternalGuard] Battery Low? │ └── [Parallel] Dock │ ├── Flash Red │ └── Dock Action ├── [Sequence] Approach and Handle │ ├── Objects? │ ├── Pause Coverage │ ├── [Sequence] Handle │ │ ├── Flash Green │ │ └── [Sequence] Pick Up │ │ ├── Approach │ │ └── [Selector] Pick or Skip │ │ ├── [Sequence] Sort and Pick │ │ │ ├── [Retry] Retry Planar │ │ │ │ └── Planar_Detected? │ │ │ └── PickObject │ │ └── Idle │ └── Resume Coverage └── Flash Orange

Returns:

py_trees.behaviour.Behaviour: Root of the behaviour tree.

mirte_lc_labclean.test_node_main(args=None)

Initialize and run the Mirte test controller node.

Args:

args (list, optional): Arguments forwarded to rclpy.init().