The FallbackNode is used to try different strategies, until one succeeds. If any child returns RUNNING, previous children will NOT be ticked again.
-The SequenceNode is used to tick children in an ordered sequence. If any child returns RUNNING, previous children will NOT be ticked again.
-The SequenceStarNode is used to tick children in an ordered sequence. If any child returns RUNNING, previous children are not ticked again.
-The ParallelNode executes all its children concurrently, but not in separate threads!
-Even if this may look similar to ReactiveSequence, this Control Node is the only one that can have multiple children RUNNING at the same time.
-The Node is completed either when the THRESHOLD_SUCCESS or THRESHOLD_FAILURE number is reached (both configured using ports).
-If any of the thresholds are reached, and other children are still running, they will be halted.
-The ReactiveSequence is similar to a ParallelNode. All the children are ticked from first to last:
-If all the children return SUCCESS, this node returns SUCCESS.
-The ReactiveFallback is similar to a ParallelNode. All the children are ticked from first to last:
-If all the children fail, then this node returns FAILURE.
-IMPORTANT: to work properly, this node should not have more than a single asynchronous child.
-The first child is the "statement" of the if.
-If that return SUCCESS, then the second child is executed.
-Instead, if it returned FAILURE, the third child is executed.
-If you have only 2 children, this node will return FAILURE whenever the statement returns FAILURE.
-This is equivalent to add AlwaysFailure as 3rd child.
-WhileDoElse must have exactly 2 or 3 children. It is a REACTIVE node of IfThenElseNode.
-The first child is the "statement" that is executed at each tick
-If result is SUCCESS, the second child is executed.
-If result is FAILURE, the third child is executed.
-If the 2nd or 3d child is RUNNING and the statement changes, the RUNNING child will be stopped before starting the sibling.
-Executes its child node only if a condition is met.
-If the precondition is met, the child node will be run and this node will return the status returned from the child.
-If the precondition is not met, this node will return the BT::NodeStatus value specified in "return_on_mismatch".
-Tick the child once and return SUCCESS if the child failed or FAILURE if the child succeeded.
-If the child returns RUNNING, this node returns RUNNING too.
-Tick the child until it returns SUCCESS.
-Tick the child until it returns FAILURE.
-Tick the child up to N times, where N is passed as a Input Port, as long as the child returns SUCCESS.
-Interrupt the loop if the child returns FAILURE and, in that case, return FAILURE too.
-If the child returns RUNNING, this node returns RUNNING too.
-Halt the child node after a given timeout.
-Sleep for a given duration of time and then tick the child node.
-If the child returns RUNNING, this node returns RUNNING too.
-Otherwise, it returns always SUCCESS.
-If the child returns RUNNING, this node returns RUNNING too.
-Otherwise, it returns always FAILURE.
-Return SUCCESS.
-Return FAILURE.
-Write a value into the behavior tree blackboard.
-Introduced in BT.CPP 4 to integrate scripting language within XML
-Allows users to read from and write to variables in the blackboard
-Can perform operation like assignment, comparison, etc.
-- Provides functions for realtime tracking of AprilTag in published image topics. -
-- Parameters for tag detector are ingested parsed YAML configuration. Raw images are processed from the specified camera stream topic, - and detections are published as a vector of TransformStamped to the specified output topic. -
-- NOTE: This behavior will never terminate on its own. You must wrap it in a sequence that will handle halting the node. -
-- Activates a controller whose name is given by the "controller_name" input port. -
-- Subscribes to a topic that can be used for pausing an objective during execution to allow introspection. This behavior will listen on the configured topic for a True/False message which will cause it to continue or abort from a breakpoint that is included in an objective. -
-- Check if an input object is similar to another object. Succeeds if the objects are similar within the provided criteria and fails if they are not similar. -
-- Clears the existing Octomap and Pointcloud snapshots. -
-- Uses the "/edit_waypoints service" to save the robot's current state as a new named waypoint or erase an existing waypoint. The name of the waypoint to save or delete is set through the "waypoint_name" behavior parameter. The operation to perform on the waypoint is set through the "waypoint_operation" behavior parameter, which must be set to either "save" or "erase". -
-- Takes a shared pointer to an MTC Solution object via an input data port, and executes the lowest-cost trajectory in that Solution using the MTC ExecuteTaskSolution MoveGroup capability's "/execute_task_solution" action server. -
-- Given a collection of CollisionObjects, find the one closest to the provided pose. -
-- Analyze a point cloud to find well-singulated cuboids which supported by a surface. -
-- Calculates the pose, length, and width of a door handle. By convention, the z-axis of "target_handle_pose" is aligned with the handle's axis of rotation, and the x-axis points along the handle toward the door hinge. -
-- Given an input PoseStamped representing a grasp pose selected on a drawer handle, output three PoseStampeds that define a screw motion to open the drawer. -
-- Assumes that the z-axis of the grasp pose matches the normal vector of the front face of the drawer. -
-- Arrange input poses into the order expected by the affordance template behavior. -
-- Given three input poses generated from surface-normal calculation of a point cloud, where the first represents the location of the door handle and the second and third are points on the axis of the hinge, determine which hinge axis pose should be the origin of the hinge vector so that a positive rotation about the hinge axis opens the door towards the user's viewpoint. -
-- Assumes that the z-axis of the two poses on the hinge axis are oriented facing into the surface of the door. -
-- The direction of the door relative to the surface normal is determined by calculating the vector cross product of the vector from the hinge origin pose to the grasp pose and the vector from the hinge origin pose to the hinge axis pose, and then calculating the dot product of the resulting vector and the z-axis of the hinge origin pose. If the dot product is positive, the hinge origin and hinge axis poses are correctly ordered. If the dot product is negative, the hinge origin and hinge axis poses need to be reversed for positive door rotation to open the door towards the viewpoint. -
-- Gets the latest transform from the robot model root to a frame specified as an input parameter to this behavior. -
-- Captures a point cloud and makes it available on an output port. -
-- Optionally takes a string uuid which can be used to identify the requester, and makes it available on an output port. The parameter is "optional", if it unset then no output will be forwarded. Note: no validation is done on the value of the UUID, so any string is provided (including the empty string) it will be set on the output port. -
-- Saves a single image to a file as soon as it receives a message on the topic. Filename will follow the syntax of IMAGE_TOPIC_image_raw_YYYYMMDD_HHMMSS.png -
-- Save the contents of a point cloud on the blackboard to a pcd file using the pcl::PointXYZRGB point type. Filename will follow the syntax of pointcloud_YYYYMMDD_HHMMSS.pcd -
-- Creates a shared pointer to a new MTC Task object, populates it with global settings (for example, the names of controllers to enable by default when executing trajectories planned by this task), and sets it as an output data port. -
-- Check if the robot's current state satisfies a kinematic visibility constraint. -
-- A condition node that monitors a wrench topic and returns "BT::NodeStatus::FAILURE" when ticked if the magnitude of the force components has exceeded a specified threshold for some number of consecutive observations. -
-- Checks for the presence of a user interface by checking if the "/trajectory_bridge" ROS node exists. -
-- Loads the configuration parameters for a given objective. The configuration file name is given as an input port parameters to this behavior. The parameters are loaded once per objective execution. To reload the parameter from the file, just execute the objective again. -
-- Loads a point cloud from a .PCD file, converts it to a ROS sensor_msgs/PointCloud2 message, and writes it to an output data port. -
-- Add a collision object to the planning scene. -
-- Actuate a gripper through its driver node's GripperCommand action server. Given the name of the action topic and a target gripper position, move the gripper to the specified position. -
-- Moved to a named Waypoint. -
-- Takes a shared pointer to an existing MTC Task object via an input data port, plans the task, and sets the resulting MTC Solution object as an output data port. -
-- Publishes a point cloud on a ROS topic (typically used for debugging purposes). -
-- Removes all objects which were added to the planning scene during runtime. -
-- Given a named waypoint, sends a service request to the Agent WaypointManager to retrieve the joint state associated with that waypoint. -
-- Use the "/get_planning_scene" service to save the robot's current state. -
-- Given a point cloud, filter it using MoveIt's settings for that sensor, convert it to ASCII PCD format, and publish it on a topic. -
-- The UUID parameter can be used to track the pointcloud request through to other behaviors, if required. It is an optional input port, and if unset then the published message will have an empty string in its UUID field. Note: no validation is done on the value of the UUID, so any string that is provided (including the empty string) will be set on the output port. -
-- Configures MTC stages to perform a motion that can be parameterized as a screw trajectory. Examples in practice include opening doors and drawers. -
-- The input data ports are generally calculated by separate perception processing Behaviors in a previous step of the Objective. -
-- Given an existing MTC Task object and input parameters that configure a screw motion affordance template, perform the following steps: -
-- Given an existing MTC Task object and a joint state, appends MTC stages to describe a cartesian motion plan to that joint state. -
-- Given an existing MTC Task object, appends an MTC CurrentState Stage to the Task. -
-- Given an existing MTC Task object and a joint state, appends MTC stages to describe a joint-interpolated motion plan to that joint state. -
-- Given an existing MTC Task object, frame name, axis, and move distance, appends MTC stages to describe a cartesian motion plan in the frame's axis with the specified distance. -
-- Given an existing MTC Task object and a joint state, appends MTC stages to describe a freespace motion plan to that joint state. -
-- Given an existing MTC Task object and the name of a known state, appends MTC stages to describe a freespace motion plan to that state. -
-- Given an existing MTC Task object and a target pose, appends MTC stages to describe a freespace motion plan to that target pose. -
-- Configures MTC stages to open a lever-handled door by turning the handle and pushing the door away from the robot. -
-- The input data ports are generally calculated by separate perception processing Behaviors in a previous step of the Objective. -
-- Given an existing MTC Task object and a target object, appends MTC stages to describe a motion plan to approach, grasp and lift the object. -
-- Given an existing MTC Task object and a target grasp pose, appends MTC stages to describe a motion plan to approach, grasp and lift an object at that pose. -
-- Add an MTC Stage to an MTC Task that modifies the planning scene's Allowed Collision Matrix to permit or forbid collision between a planning scene object and the links of a named robot planning group while planning subsequent Stages. -
-- Split an MTC Solution message in two by dividing its vector of subtrajectories at the specified index. -
-- This is a special Behavior to run human-in-the-loop teleoperation using MoveIt Servo through the Objective Server. -
-- When started, this Behavior will run INDEFINITELY until it is halted. This will happen either when the root node of the behavior tree is halted as the Objective is canceled, or when this Behavior's parent control node halts it. When this Behavior first transitions from IDLE to RUNNING, it starts and unpauses Servo control using the services advertised by the Servo server node. While this Behavior is RUNNING, it subscribes to JointJog and TwistStamped command messages that originate in the user interface, and republishes these messages to the command topics advertised by the Servo server node. When this Behavior is halted, it pauses Servo control using the server's services. -
-- Updates parameters for an existing admittance controller. -
-- DEPRECATED: Use UpdatePlanningSceneService and SendPointCloudToUI instead. -
-- Given a point cloud from the specified sensor, will sanitize the point cloud according to that sensor's params and publish the result to the relevant topic to update the occupancy map. It will also convert the resulting pointcloud to ASCII PCD format and publish it to the specified pcd_topic. -
-- The UUID parameter can be used to track the pointcloud request through to other behaviors, if required. It is an optional input port, and if it unset then the published message will have an empty string in its UUID field. Note: no validation is done on the value of the UUID, so any string is provided (including the empty string) it will be set on the output port. -
-- Updates the planning scene's collision octree using the provided point cloud, and waits until the octree has finished updating. -
-- Wait for a specified duration before succeeding. -
-- Takes a shared pointer to an MTC Solution object via an input data port, and publishes the lowest-cost trajectory in that Solution on the "/preview_solution" topic. Creates a SetBool service server on the "/execute_behavior_solution" topic and waits to receive a request containing data: true before succeeding. -
-