picknik_controllers repository

Repository Summary

Checkout URI https://github.com/PickNikRobotics/picknik_controllers.git
VCS Type git
VCS Version main
Last Updated 2023-07-25
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

picknik_controllers

Package defining custom controllers that are generic and we want to contribute them into ros2_controllers. The controllers have been prefixed with picknik_ so that when they eventually land upstream the prefix can be removed and the versions here will become deprecated.

  • picknik_twist_controller::PicknikTwistController
  • picknik_reset_fault_controller::PicknikResetFaultController

PicknikTwistController

Generic ROS2 controller to forward cartesian twist commands. We plan to land this upstream in ros2_controllers: https://github.com/ros-controls/ros2_controllers/pull/300

Usage

Example of instance within ros2_control can be found in the configuration file. Defined interfaces have to exist within the hardware_interface::SystemInterface implemented for the robot (e.g. driver). Stop any commanding controller and then start PicknikTwistControllerto forward twist msgs to the hardware's built-in cartesian twist controller.

Note on controllers

Exclusiveness logic is within the driver, and running joint-based and twist controller at the same time is not possible. Controller Manager (ros2_control) will try to activate both on request, but the hardware should reject it.

ros2 control switch_controllers --activate streaming_controller --deactivate joint_trajectory_controller

By publishing geometry_msgs::msg::Twist to /streaming_controller/commands, the commands will be piped to the driver and streamed to the robot controller.

PicknikResetFaultController

ROS 2 controller that offers a service to clear faults in a hardware interface

Usage

Example of instance within ros2_control can be found in the configuration file. Interfaces are already hardcoded in the hardware_interface::SystemInterface implemented for the robot (e.g. driver)

Spawn FaultController if it is not already spawned

ros2 run controller_manager spawner fault_controller

On the topic /fault_controller/internal_fault of type example_interfaces::msg::Bool the information if robot is currently faulted can be found.

Deactivate all the controllers using robot.

ros2 control swithc_controllers --deactivate joint_trajectory_controller gripper_controller

Call the service for resetting the fault (example_interfaces::srv::Trigger).

ros2 service call /fault_controller/reset_fault example_interfaces/srv/Trigger

Activate controllers to enable robot control.

ros2 control swithc_controllers --activate joint_trajectory_controller gripper_controller

Build status

ROS2 Distro Branch Build status Documentation Released packages
Rolling rolling Rolling Binary Build
Rolling Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Humble humble Humble Binary Build
Humble Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Iron iron Iron Binary Build
Iron Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers

Explanation of different build types

NOTE: There are three build stages checking current and future compatibility of the package.

Detailed build status

  1. Binary builds - against released packages (main and testing) in ROS distributions. Shows that direct local build is possible.

Uses repos file: $NAME$-not-released.<ros-distro>.repos

  1. Semi-binary builds - against released core ROS packages (main and testing), but the immediate dependencies are pulled from source. Shows that local build with dependencies is possible and if fails there we can expect that after the next package sync we will not be able to build.

Uses repos file: $NAME$.repos

  1. Source build - also core ROS packages are build from source. It shows potential issues in the mid future.

CONTRIBUTING

No CONTRIBUTING.md found.

Repository Summary

Checkout URI https://github.com/PickNikRobotics/picknik_controllers.git
VCS Type git
VCS Version main
Last Updated 2023-07-25
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

picknik_controllers

Package defining custom controllers that are generic and we want to contribute them into ros2_controllers. The controllers have been prefixed with picknik_ so that when they eventually land upstream the prefix can be removed and the versions here will become deprecated.

  • picknik_twist_controller::PicknikTwistController
  • picknik_reset_fault_controller::PicknikResetFaultController

PicknikTwistController

Generic ROS2 controller to forward cartesian twist commands. We plan to land this upstream in ros2_controllers: https://github.com/ros-controls/ros2_controllers/pull/300

Usage

Example of instance within ros2_control can be found in the configuration file. Defined interfaces have to exist within the hardware_interface::SystemInterface implemented for the robot (e.g. driver). Stop any commanding controller and then start PicknikTwistControllerto forward twist msgs to the hardware's built-in cartesian twist controller.

Note on controllers

Exclusiveness logic is within the driver, and running joint-based and twist controller at the same time is not possible. Controller Manager (ros2_control) will try to activate both on request, but the hardware should reject it.

ros2 control switch_controllers --activate streaming_controller --deactivate joint_trajectory_controller

By publishing geometry_msgs::msg::Twist to /streaming_controller/commands, the commands will be piped to the driver and streamed to the robot controller.

PicknikResetFaultController

ROS 2 controller that offers a service to clear faults in a hardware interface

Usage

Example of instance within ros2_control can be found in the configuration file. Interfaces are already hardcoded in the hardware_interface::SystemInterface implemented for the robot (e.g. driver)

Spawn FaultController if it is not already spawned

ros2 run controller_manager spawner fault_controller

On the topic /fault_controller/internal_fault of type example_interfaces::msg::Bool the information if robot is currently faulted can be found.

Deactivate all the controllers using robot.

ros2 control swithc_controllers --deactivate joint_trajectory_controller gripper_controller

Call the service for resetting the fault (example_interfaces::srv::Trigger).

ros2 service call /fault_controller/reset_fault example_interfaces/srv/Trigger

Activate controllers to enable robot control.

ros2 control swithc_controllers --activate joint_trajectory_controller gripper_controller

Build status

ROS2 Distro Branch Build status Documentation Released packages
Rolling rolling Rolling Binary Build
Rolling Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Humble humble Humble Binary Build
Humble Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Iron iron Iron Binary Build
Iron Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers

Explanation of different build types

NOTE: There are three build stages checking current and future compatibility of the package.

Detailed build status

  1. Binary builds - against released packages (main and testing) in ROS distributions. Shows that direct local build is possible.

Uses repos file: $NAME$-not-released.<ros-distro>.repos

  1. Semi-binary builds - against released core ROS packages (main and testing), but the immediate dependencies are pulled from source. Shows that local build with dependencies is possible and if fails there we can expect that after the next package sync we will not be able to build.

Uses repos file: $NAME$.repos

  1. Source build - also core ROS packages are build from source. It shows potential issues in the mid future.

CONTRIBUTING

No CONTRIBUTING.md found.

Repository Summary

Checkout URI https://github.com/PickNikRobotics/picknik_controllers.git
VCS Type git
VCS Version main
Last Updated 2023-07-25
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

README

picknik_controllers

Package defining custom controllers that are generic and we want to contribute them into ros2_controllers. The controllers have been prefixed with picknik_ so that when they eventually land upstream the prefix can be removed and the versions here will become deprecated.

  • picknik_twist_controller::PicknikTwistController
  • picknik_reset_fault_controller::PicknikResetFaultController

PicknikTwistController

Generic ROS2 controller to forward cartesian twist commands. We plan to land this upstream in ros2_controllers: https://github.com/ros-controls/ros2_controllers/pull/300

Usage

Example of instance within ros2_control can be found in the configuration file. Defined interfaces have to exist within the hardware_interface::SystemInterface implemented for the robot (e.g. driver). Stop any commanding controller and then start PicknikTwistControllerto forward twist msgs to the hardware's built-in cartesian twist controller.

Note on controllers

Exclusiveness logic is within the driver, and running joint-based and twist controller at the same time is not possible. Controller Manager (ros2_control) will try to activate both on request, but the hardware should reject it.

ros2 control switch_controllers --activate streaming_controller --deactivate joint_trajectory_controller

By publishing geometry_msgs::msg::Twist to /streaming_controller/commands, the commands will be piped to the driver and streamed to the robot controller.

PicknikResetFaultController

ROS 2 controller that offers a service to clear faults in a hardware interface

Usage

Example of instance within ros2_control can be found in the configuration file. Interfaces are already hardcoded in the hardware_interface::SystemInterface implemented for the robot (e.g. driver)

Spawn FaultController if it is not already spawned

ros2 run controller_manager spawner fault_controller

On the topic /fault_controller/internal_fault of type example_interfaces::msg::Bool the information if robot is currently faulted can be found.

Deactivate all the controllers using robot.

ros2 control swithc_controllers --deactivate joint_trajectory_controller gripper_controller

Call the service for resetting the fault (example_interfaces::srv::Trigger).

ros2 service call /fault_controller/reset_fault example_interfaces/srv/Trigger

Activate controllers to enable robot control.

ros2 control swithc_controllers --activate joint_trajectory_controller gripper_controller

Build status

ROS2 Distro Branch Build status Documentation Released packages
Rolling rolling Rolling Binary Build
Rolling Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Humble humble Humble Binary Build
Humble Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers
ROS2 Distro Branch Build status Documentation Released packages
Iron iron Iron Binary Build
Iron Semi-Binary Build
Doxygen Doc Deployment
Generated Doc
picknik_controllers

Explanation of different build types

NOTE: There are three build stages checking current and future compatibility of the package.

Detailed build status

  1. Binary builds - against released packages (main and testing) in ROS distributions. Shows that direct local build is possible.

Uses repos file: $NAME$-not-released.<ros-distro>.repos

  1. Semi-binary builds - against released core ROS packages (main and testing), but the immediate dependencies are pulled from source. Shows that local build with dependencies is possible and if fails there we can expect that after the next package sync we will not be able to build.

Uses repos file: $NAME$.repos

  1. Source build - also core ROS packages are build from source. It shows potential issues in the mid future.

CONTRIBUTING

No CONTRIBUTING.md found.