CBFKit: A Control Barrier Function Toolbox for Robotics Applications

CBFKit is a Python/ROS2 toolbox designed to facilitate safe planning and control for robotics applications, particularly in uncertain environments. The toolbox utilizes Control Barrier Functions (CBFs) to provide formal safety guarantees while offering flexibility and ease of use. We additionally provide efficient JAX implementatio of Model Predictive path Integral (MPPI) with support for reach avoid specifications.

Table of Contents

• Key Features
• Supported Models
• Applications
• Installation
• Start with Tutorials
• ROS2
• Examples
• Citing CBFKit
• License

Key Features

• Generalized Framework: Supports the design of CBFs for various robotic systems operating in both deterministic and stochastic settings.
• ROS Integration: Seamlessly connects with ROS2, enabling multi-robot applications, environment and map encoding, and integration with motion planning algorithms.
• Diverse CBF Options: Provides a variety of CBF formulations and algorithms to address different control scenarios.
• Model-based and Model-free Control: Accommodates both model-based control strategies using system dynamics and model-free control approaches. Model-free algorithms to be added soon.
• Safety Guarantee: CBFs provide mathematically rigorous guarantees of safety by ensuring the system remains within a defined safe operating region.
• Flexibility: Allows users to specify custom safety constraints and barrier functions to tailor the control behavior to specific needs.
• Multi-layer architecure Allows seamless integration of planners, nominal controller and safety filter controllers.
• Efficiency: Leverages JAX for efficient automatic differentiation and jaxopt for fast quadratic program (QP) solving, enabling real-time control applications.
• Code Generation: Simplifies model creation with automatic code generation for dynamics, controllers, and certificate functions.
• Usability: Includes tutorials and examples for a smooth learning curve and rapid prototyping.
• Functional Programming: Built on functional programming principles, emphasizing data immutability and programmatic determinism.

Supported Models

CBFKit accommodates a range of control-affine system models:

• Deterministic Continuous-time ODEs: $\dot{x} = f(x) + g(x)u$
• ODEs with Bounded Disturbances: $\dot{x} = f(x) + g(x)u + Mw$
• Stochastic Differential Equations (SDEs): $dx = (f(x) + g(x)u)dt + \sigma(x)dw$

Applications

CBFKit can be applied to diverse robotics applications, including:

• Autonomous Navigation: Ensure collision avoidance with static and dynamic obstacles.
• Human-Robot Interaction: Guarantee safety during collaborative tasks and physical interaction.
• Manipulation: Control robot arms while avoiding obstacles and joint limits.
• Multi-Robot Coordination: Coordinate the movement of multiple robots while maintaining safe distances and avoiding collisions.

Installation

CBFKit is readily deployable via a Docker image. After setting up Docker (refer to the official Docker documentation for detailed instructions), proceed with one of the following methods:

1. VS Code DevContainer Launch

1. Open the project in VS Code.
2. Click the green button at the bottom right of the window to launch the DevContainer.
3. All necessary components are pre-installed for immediate use.

2. Docker Command Line

1. Build the image:

   docker build -t cbfkit:latest -f Dockerfile.$(uname -m) .

2. Run the container:

   docker run -it --name container-name -v .:/workspace cbfkit:latest

Start with Tutorials

Explore the tutorials directory to help you get started with CBFKit. Open the Python notebook in the tutorials directory to get started. The script simulate_new_control_system.ipynb automatically generates the controller, plant, and certificate function for a Van der Pol oscillator. It also generates ROS2 nodes for the plant, controller, sensor, and estimator. These serve as a starting point for developing your own CBF-based controller.

Generated files/folders:

van_der_pol_oscillator
 ┣ certificate_functions
 ┃ ┣ barrier_functions
 ┃ ┃ ┣ __init__.py
 ┃ ┃ ┣ barrier_1.py
 ┃ ┃ ┗ barrier_2.py
 ┃ ┣ lyapunov_functions
 ┃ ┃ ┣ __init__.py
 ┃ ┃ ┗ lyapunov_1.py
 ┃ ┗ __init__.py
 ┣ controllers
 ┃ ┣ __init__.py
 ┃ ┣ controller_1.py
 ┃ ┗ zero_controller.py
 ┣ ros2
 ┃ ┣ __init__.py
 ┃ ┣ config.py
 ┃ ┣ controller.py
 ┃ ┣ estimator.py
 ┃ ┣ plant_model.py
 ┃ ┗ sensor.py
 ┣ __init__.py
 ┣ constants.py
 ┣ plant.py
 ┗ run_ros2_nodes.sh

We recommend going through the tutorials in the following order to get familiar with the architecture of our library.

• simulate_new_control_system.ipynb
• multi_robot_example.ipynb
• simulate_mppi_cbf.py
• simulate_mppi_cbf_ellipsoidal_stochastic_cbf.py
• simulate_mppi_stl.py

Simulation Arhitecture

• Every simulation must define a planner, nominal controller, and a controller where the output of planner is passed to nominal controller and the output of nominal controller is then passed to the controller. The nominal controller is expected to designed to generate control input that steers towards a state waypoint. The controller is designed to be a filter after nominal controller.
• The planner can return a state or control input trajectory. If the planner returns a control input trajectory, the nominal controller is skipped and the controller is directly employed. If the planner returns a state trajectory, then the nominal controller is called first to convert the desired state into corresponding control input command which is then passed to the controller.

The flowchart below summarizes the architecure

Each function (dynamics, cost, constraint, controller) must follow a specific structure.

• dynamics:
  • Input arguments: x (state)
  • Return arguments: f, g (dynamics matrix for affine dynamics x_dot = f(x) + g(x)u)
• nominal controller:
  • Input arguments: t (time), x (state)
  • Return arguments: u (control), data (dictionary with the key "u_nom" mapping to designed u )
• cost function:
  • Input arguments: state_and_time (concatenated state and time in 1D array)
  • Return arguments: cost (float)
• planner:
  • Input arguments: t (time), x (state), key (for random number generation), data (dictionary containing necessary information)
  • Return arguments: u (first control input in planned sequence (can be None if planner retutrns state trajectory instead of control trajectory)), data (dictionary containing extra information like found control or state trajectory)
• controller:
  • Input arguments: t (time), x (state), u_nom (nominal control input), key (for random number generation), data (dictionary containing necessary information)
  • Return arguments: u (control input), data (dictionary containing extra information)

The data (python dictionary) in planners and controllers is designed to cater to needs of different types of comntrollers and planners. For example, CBF-QP does not need to maintain internal state but planners/controllers like MPC or MPPI need to initialize their initial guess with solution from previous time step when implemented in receding horizon fashion. Since we focus on functional programming for computational efficiency, instead of maintaining this internal state, we pass it as input and output arguments. Controllers like CBF-QP need to maintain any internal state and can have empty dictionary whereas MPPI stores its solution trajectory in the dictionary (and received it back at next time step of the simulation). The data must therefore be populated appropriately. In case of planners, the control trajectory must be associated with the key u_traj and state trajectory must be associated with the key x_traj. See cbf_clf_qp_generator.py and mpi_generator.py files to understand in more detail.

ROS2

The ROS2 nodes are generated in the ros2 directory. The nodes are generated for the plant, controller, sensor, and estimator. This support is in the initial stage and will be improved soon.

To run the nodes, execute the following command in the van_der_pol_oscillator directory:

bash run_ros2_nodes.sh

The generated nodes interact as follows:

• The plant_model node simulates the physical system and publishes the system state.
• The sensor node receives the system state and adds noise to simulate real-world measurements.
• The estimator node receives the noisy measurements and estimates the true system state.
• The controller node receives the estimated state and computes the control input based on the CBF formulation.

Citing CBFKit

If you use CBFKit in your research, please cite the following PAPER:

@misc{black2024cbfkit,
title={CBFKIT: A Control Barrier Function Toolbox for Robotics Applications},
author={Mitchell Black and Georgios Fainekos and Bardh Hoxha and Hideki Okamoto and Danil Prokhorov},
year={2024},
eprint={2404.07158},
archivePrefix={arXiv},
primaryClass={cs.RO}
}

License

CBFKit is distributed under the BSD 3-Clause License. Refer to the LICENSE file for detailed terms.