ros-controls / ros2_control

Generic and simple controls framework for ROS 2

ros2_control

This package is a part of the ros2_control framework. For more, please check the documentation.

Build status

ROS2 Distro	Branch	Build status	Documentation	Released packages
Rolling	master		Documentation API Reference	ros2_control
Iron	iron		Documentation API Reference	ros2_control
Humble	humble		Documentation API Reference	ros2_control

Detailed build status

Explanation of different build types

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

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

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

2. 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: src/$NAME$/$NAME$.repos

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

Docker images

There are a few published docker images that come with the latest releases. More information about them can be found in the .docker folder. You can pull them under these tags: ghcr.io/ros-controls/ros2_control_release or ghcr.io/ros-controls/ros2_control_source.

Acknowledgements

Supported by ROSIN - ROS-Industrial Quality-Assured Robot Software Components. More information: rosin-project.eu

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 732287.

ros2_control's Issues

Simplify dependency declarations

Specifically I mean to do build_depend + exec_depend = depend.
Should you find anything else you could simplify/clean up, please go ahead.

Implement basic Transmission loading and SimpleTransmission

http://docs.ros.org/melodic/api/transmission_interface/html/c++/classtransmission__interface_1_1SimpleTransmission.html

Documentation for loading the controller is outdated

Hello,

I am following the documentation to load a JointStateController. If I am not mistaken, the load_controller function as written in the README is outdated. The new version does not seem to take 3 string parameters but only 2 (name, type).

Moreover, it seems that the controllers are not under namespace ros_control but their own (joint_state_controller for JointStateController and joint_trajectory_controller for JointTrajectoryController). At least this is what I get by looking at the ros2_controller package (which address is also wrongly spelled in the README with controlllers instead of controllers).

The problem is that even when importing the joint_state_controller package I get loader for controller not found. For reference, I am using the following command:

cm.load_controller("joint_state_controller", "joint_state_controller::JointStateController");`

which might be wrong. Should the controller be loaded in a different way?

Thanks in advance.

As a hardware manufacturer, I would like to use combined_robot_hw to ship my RobotHW implementation working with my hardware

Design

Port over combined_robot_hw

References

http://wiki.ros.org/combined_robot_hw

Add TransmissionInterface class. Adjust SimpleTransmission to inherit from this.

We need something much simpler and extendable than this, no ThisToThat() functions are allowed.

use rclcpp logger macros when possible

throughout the code base, RCUTILS_LOG_X is used due to the lack of the RCLCPP_X logging macros at the time of development.

As a ros2_control user, I would like the possibility to define specific update rates for controllers

Design

Add an optional rate parameter to the controller base class which can override the default set by the RobotHW.
When no controllers has this defined, they should run as before, using the same update rate.

Implement registerInterface() following a string-based setup so it can be checked against when attempting to load transmissions

https://github.com/ros-controls/roadmap/blob/master/design_drafts/joint_interfaces_and_transmissions.md

How to use ros2_control?

I would like to try real-time control in ros2. The only thing I find about ros2 control is this repository. However, I cannot find anything that explain how to use this. Could any one please give me a little hint?

In ros2 demo about pendulum_control, it seemes that they wrote their own code. Does this mean we still don't have a ready-to-use ros2-control? Thank you very much! :-)

As a robotics developer, I want to use the control_toolbox in my controllers

Design requirements

Port the classes and functionalities of control_toolbox over to ROS2.
Some sanitization may be required along the way: if math-specific interfaces were less tangled with ROS-specific interfaces, both the porting job and the API would benefit from it.

This is a leaf package in our dependency tree, it should already be released to ROS2 Dashing for early validation, please work against dashing-devel.

For now, work in the https://github.com/ros-controls/control_toolbox repo for this.

• control_toolbox can be compiled on ROS2 Dashing
• control_toolbox is released to ROS2 Dashing
• control_toolbox is released to ROS2 Eloquent

References

Pending PR with partial port already done: ros-controls/control_toolbox#81

As a ros2_control user I would like to define transmissions for my robots

Design

Port over transmission_interface

Generate transmission info from URDF

https://github.com/ros-controls/roadmap/blob/master/design_drafts/joint_interfaces_and_transmissions.md

First Foxy release

List of required features from ros2_control and ros2_controllers for the first Foxy release:

• The joint_trajectory_controller from ROS Melodic with all it's features
• The diff_drive_controller from ROS Melodic with all it's features
• gazebo_ros_control

Waiting for contributions to this list @jordan-palacios @Karsten1987 @piraka9011

List of breaking changes from ros_control to ros2_control

Hi, I'd like to startup a list of breaking changes from ros_control to ros2_control. I think it'll help with porting some of the modules and programs that use ros_control and wish to port over to ros2_control. Feel free to add to this list or correct my assumptions.

https://github.com/ros-controls/ros_control

hardware_interface

• ros_control's JointStateHandle split into JointStateHandle and JointCommandHandle
• ros_control's RobotHW renamed + functionality change to RobotHardware

joint_limits_interface

• ros_control's JointStateInterface, EffortJointInterface, PositionJointInterface, VelocityJointInterface, *InterfaceProvider functionalities have been replaced by RobotHardware.
• no equivalent so far: EffortJointSaturationInterface/EffortJointSoftLimitsInterface/PositionJointSaturationInterface/PositionJointSoftLimitsInterface/VelocityJointSaturationInterface/VelocityJointSoftLimitsInterface

As a robotics developer, I want to specify the limits of my robot's joints so I can ensure safe operation of my robot

Design requirements

Create a joint_limits_interface that ensures joint commands never go over certain thresholds.

• Limits can be defined from parameters
• Limits can be defined programatically

References

• 'ros-controls/ros_control's joint_limits_interface`
• Windows STL conflicts with std::min/max.

# Potential solution with CMakeLists.txt
if(WIN32)
  add_definitions(-DNOMINMAX)
endif()

JointStateController with Gazebo

Hi,

I would like to ask how to use joint_state_controller to position-control a robot on the Gazebo simulator. It will be very nice if there is a demo example I can refer to (like this in ROS1).

Thank you in advance,
Ryan

Joint Trajectory performance on servos

How does the Joint Trajectory controller in this project perform for receiving position/vel/acc or position/effort messages and projecting them onto servo position waypoints? How does it control the effort input without knowing torque/current feedback?

I'm studying the code but based on the README this repo may not be ready for normal use on ROS2? README says,

"...presented at ROSCON 2017 and is currently not under active development."

I can't find any other existing Joint Trajectory Controllers besides MoveIt!2 perhaps.

Possibly related issues #10
Possibly related ROS Answer - What is the purpose of ros_control and ros_controller?
ROS Wiki on Understanding Trajectory Replacement

Thanks!

Some thoughts on controller and filters

Hi,

in the calls, some of you mention about value limiters when talking about controller composition. What I understand, you would like to have a controller-like structure, which can limit/change values. If so, then this simple kine of controllers are actually filters. Would it be sensible to separate these two semantically, but keep the same parent class? The execution and structure would be actually the same. In this case, we would be able to dynamically compose filters and controllers which would be very nice. This is of course also possible without separation, but it could get confusing for the users. The same issue is with "controllers" which are actually only publishers in ros-control.

What do you think about that? @bmagyar @Karsten1987 @piraka9011 @olivier-stasse

Add clang-format file to repo

As a ROS2 user I would like ros2_control controllers to follow node lifecycles

This could be achieved by making the controller interface inherit from rclcpp_lifecycle::LifecycleNode and the rest falls into place after some adjustment in the controller implementations.

References

• http://design.ros2.org/articles/node_lifecycle.html

Ability to clear the registered handles

Hello,

Is there a functionality to clear the registered handles? At the moment, calling twice the init function on a hardware interface will try to register again a joint or a command resulting in an exception. The problem is that if a controller fail at configuring, the node is stuck in the not configured state as calling on_configure again will fail at the second hardware init call.

Am I missing something?
Thanks.

enable rcpputils pointer traits

top level issue for leveraging rcpputils::is_pointer which in addition to std::is_pointer checks for smart pointers as well.

ros_canopen integration

Hi,

I'm working on porting ros_canopen to ROS2 and on adding CANopen 402 support to ODrive.

The overall goal is to make a cheap open-source motor control solution for custom robots with a large number of brushless motors on the same CAN bus. Hopefully at a high enough frequency for dynamics based "operational space control" and things like that.

The next step for me is to port canopen_motor_node. It is a hardware interface for ros_control at the moment.

I recently released a Unity3d based robot simulator for ROS2 (unity_ros2) and I plan to make something similar to the ros_control <=> gazebo integration in ROS1 for that as well.

I would appreciate some more info about this project before I start coding integrations. Do you plan to make any updates to this project relatively soon? What works and what doesn't work at the moment?

Purpose of controller_parameter_server?

Hi,

Is there some specific reason parameters are loaded using the custom controller_parameter_server package instead of how it is done in nav2_bringup for example.

Did that method of loading parameters not exist when you started working on this?

Import ros2_control

Top Level issue referencing all pending PRs

add ROS services for controller manager

There is currently no way to load controller dynamically at runtime through ROS2 services.

ros_controllers trajectory controller test fails

The trajectory controller tests currently fails which the change to the ROS2 master time/clock interface.

As a robotics developer, I want to control my robot using position, velocity, or torque so I can use different controllers

Design requirements

The implementation for an interface that can read/set the position/velocity/effort/torque of a robot can be found in the hardware_interface package.

This issue will be used to track whether there are certain features missing such as proper error handling, logging, or potentially new features such as acceleration. This issue will most likely upgrade into an Epic

• Expose a timestamp of the last valid update and let controllers exploit this information locally (from here)
• Specify the control type (Effort, Position, Velocity) to use in a controller.

build error

controller_parameter_server/parameter_server.hpp:28:40: error: ‘rclcpp::node’ has not been declared
class ParameterServer : public rclcpp::node::Node

As a ros2_control developer, I want up to date documentation so I can easily understand how to develop my robotics controller

Design requirements

Create a new docs directory with Doxygen setup.

• Create the Doxygen config file
• Generate HTML output and test with Github Pages

Resources

• Getting Started with Doxygen

ownership of this repo

@bmagyar Can you grant me ownership for this repo here? I'd like to set up with travis for the two ros2 control packages.

As a ros2_control user, I would like to easily configure my runtime setup using the common CLI

Design

The currently available service-based interface could be enhanced by a more user-friendly CLI.
Examples: ros2 control list, ros2 control switch ... , ros2 control load ...

Note that this is not to replace the ROS2-API controller_manager interface but to supplement it.

References

https://github.com/ros2/ros2cli

Test dependency in metapackage

I'm not sure what a test dependency in a metapackage really does or offers, but I worry that it will pull in the dependency when using tools such as rosinstall_generator (Full disclaimer: I'm still very very green with ROS2, so I'm just pulling from ROS1 experience here).

Truthfully, I've never even seen a test_depend in a metapackage before. Can someone explain what the intended outcome of this dependency is? If there isn't one, I will open a PR to remove it in order to keep the dependencies of the metapackage slimmer (Similar to in ros_control, where tests are no longer part of the metapackage: ros-controls/ros_control#411)

ros2_control/ros2_control/package.xml

Line 20 in 9850a4b

<test_depend>test_robot_hardware</test_depend>

As a ros2_control developer, I want to have CI for my PRs so I can maintain the quality and stability of my contributions

Design Requirements

• Add the action-ros2-ci Github action to run on pull requests and create a:
  • Build and test workflow
  • Linting workflow

ros2_control and real-time requirements

Hi ros_control folks,

There were discussions in the real-time working group (RTWG) about ROS 2 projects working on real-time related applications. The name of this project was mentioned as some of the applications this project targets require real-time capabilities.

It would be great to to have some feedback from this group, for example by providing use cases with hard real-time requirements, sharing your experience in the development of real-time applications and tools (i.e: realtime_tools) or getting involved in the development or the testing of new features.

Some of the recurrent topics discussed in the RTWG are the rework of the rclcpp executor, the creation of a new C executor in rclc with deterministic behavior, tracing, performance testing, etc. Feel free to join the RTWG and discuss any of these topics or propose new ones.

You can read the minutes of previous meetings in discourse with the wg-real-time tag and check upcoming events here.

Using quotes around ament package names in ament_target_dependencies()

I found some inconsistencies in our cmake files regarding the usage of quotes around ament package names. I don't know where this comes from but I'd prefer to drop them and use quotes to highlight the semantics when the intention is defining an actual string.
If there is a strong practical argument for keeping them, let's make sure we have them but then IMHO we should write every single occurence of an ament package in quotes, not only in ament_target_dependencies.

Example from ros2_control, multiple styles in a single command:

add_library(
  hardware_interface
  SHARED
  src/joint_command_handle.cpp
  src/joint_state_handle.cpp
  src/operation_mode_handle.cpp
  src/robot_hardware.cpp
)
target_include_directories(
  hardware_interface
  PUBLIC
  include)
ament_target_dependencies(
  hardware_interface
  "rclcpp"
  "rcpputils"
)

Example from ros2_controllers:

  ament_add_gtest(test_trajectory_controller
    test/test_trajectory_controller.cpp
    ENV config_file=${CMAKE_CURRENT_SOURCE_DIR}/test/config/test_joint_trajectory_controller.yaml)
  target_include_directories(test_trajectory_controller PRIVATE include)
  target_link_libraries(test_trajectory_controller
    joint_trajectory_controller
  )
  ament_target_dependencies(test_trajectory_controller
    "controller_parameter_server"
    "control_msgs"
    "hardware_interface"
    "rclcpp"
    "rclcpp_lifecycle"
    "rcutils"
    "realtime_tools"
    "test_robot_hardware"
    "trajectory_msgs"
  )

  ament_add_gtest(
    test_load_joint_trajectory_controller
    test/test_load_joint_trajectory_controller.cpp
  )
  target_include_directories(test_load_joint_trajectory_controller PRIVATE include)
  ament_target_dependencies(test_load_joint_trajectory_controller
    controller_manager
    test_robot_hardware
  )

  ament_add_gtest(
    test_trajectory_actions
    test/test_trajectory_actions.cpp
  )
  target_include_directories(test_trajectory_actions PRIVATE include)
  target_link_libraries(test_trajectory_actions
    joint_trajectory_controller
  )
  ament_target_dependencies(test_trajectory_actions
    "controller_parameter_server"
    "control_msgs"
    "hardware_interface"
    "rclcpp"
    "rclcpp_lifecycle"
    "rcutils"
    "test_robot_hardware"
    "trajectory_msgs"
    "realtime_tools"
  )

As a robotics developer, I want to load my robot controller configurations from a YAML file so I can tune my robot parameters

Design Requirements

ROS2 does not have a parameter server per se, however, a node based parameter server can be implemented.
An initial implementation of the parameter server can be found in controller_parameter_server/include/controller_parameter_server/parameter_server.hpp

There is no interface though for the expected format of the YAML file.

• Parse and sanitize the YAML file to make sure the proper keys are passed in the config file:

<robot_name>:
  <controller_name>:
    type: <controller_type_name>
    joint: <joint_name>
    pid: <parameters_dict>

• Create a yamlcpp struct to parse the yaml file.
• Use rcpputils/filesystem_helper for file handling.
• Namespace the parameters in the yaml file.

fix linters on master branch

The current linters are failing with uncrustify errors when using the latest ros2 master.

Set up PR template

Points to highlight:

• add test to new functionality
• leave resolving comments to reviewers, don't resolve them yourself
• run linters from ROS2 master

Add a new robothw to test_robot_hardware that has initialization from URDF and tries to instantiate a transmission. Make necessary changes if integration isn't seamless.

The expected output of this is a couple of new tests.

Implement DifferentialTransmission

http://docs.ros.org/melodic/api/transmission_interface/html/c++/classtransmission__interface_1_1DifferentialTransmission.html

Resolved by #303

As a ros2_control developer, I want unit tests for my packages so I can catch regressions and failures

Design Requirements

ros2_control currently lacks some unit tests for various packages

Specifically:

• Controller interface
  • Create a fake controller and test methods.
  • Mock the robot hardware and lifecycle node.
• Hardware interface
  • Create a fake robot and test methods.
  • Create a fake OperationModeHandle and test methods.
  • Create a fake JointCommandHandle and test methods.

Create Eloquent branch

Make use of DynamicJointState message internally to store values & interface names for joints

Joint handles could still be used & served to clients, pointing to values stored in this message structure.

https://github.com/ros-controls/control_msgs/blob/foxy-devel/control_msgs/msg/DynamicJointState.msg

https://github.com/ros-controls/control_msgs/blob/foxy-devel/control_msgs/msg/InterfaceValue.msg

When will the Dashing version of ros2_control be released?

I'm tring to use Ros2 dashing version to develop my robot. When will the Dashing version of ros2_control be released?

Create general transmission parser interface, subclass URDF transmission parser from this

https://github.com/ros-controls/roadmap/blob/master/design_drafts/joint_interfaces_and_transmissions.md

Possible error in JointCommandHandle::set_cmd(double cmd)

ros2_control/hardware_interface/src/joint_command_handle.cpp

Line 53 in 719cb6c

THROW_ON_NULLPTR(cmd)

I believe THROW_ON_NULLPTR should check cmd_ and not cmd.

Flaky ros2 master?

@piraka9011 @Karsten1987
Could you guys please help me out with where this originates from and how we could avoid it?

[ 98%] Building CXX object src/cpp/CMakeFiles/fastrtps.dir/transport/TCPChannelResourceSecure.cpp.o
  [ 99%] Building CXX object src/cpp/CMakeFiles/fastrtps.dir/transport/TCPAcceptorSecure.cpp.o
  [100%] Linking CXX shared library libfastrtps.so
  [100%] Built target fastrtps
  ---
  Aborted  <<< fastrtps
  --- stderr: fastrtps
  In file included from /usr/include/string.h:494:0,
                   from /home/runner/work/ros2_control/ros2_control/ros_ws/src/eProsima/Fast-RTPS/src/cpp/rtps/persistence/sqlite3.c:12709:
  In function ‘memcpy’,
      inlined from ‘vdbePmaReadBlob’ at /home/runner/work/ros2_control/ros2_control/ros_ws/src/eProsima/Fast-RTPS/src/cpp/rtps/persistence/sqlite3.c:88355:5,
      inlined from ‘vdbePmaReadVarint’ at /home/runner/work/ros2_control/ros2_control/ros_ws/src/eProsima/Fast-RTPS/src/cpp/rtps/persistence/sqlite3.c:88398:12:
  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34:10: warning: ‘__builtin_memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
     return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---
  
  Summary: 83 packages finished [6min 41s]
    1 package failed: rcl_logging_log4cxx
    1 package aborted: fastrtps
    47 packages had stderr output: ament_cmake ament_cmake_copyright ament_cmake_core ament_cmake_cppcheck ament_cmake_cpplint ament_cmake_export_definitions ament_cmake_export_dependencies ament_cmake_export_include_directories ament_cmake_export_interfaces ament_cmake_export_libraries ament_cmake_export_link_flags ament_cmake_flake8 ament_cmake_gmock ament_cmake_gtest ament_cmake_include_directories ament_cmake_libraries ament_cmake_lint_cmake ament_cmake_pep257 ament_cmake_pytest ament_cmake_python ament_cmake_ros ament_cmake_target_dependencies ament_cmake_test ament_cmake_uncrustify ament_cmake_version ament_cmake_xmllint ament_lint_auto ament_lint_common fastrtps foonathan_memory_vendor gmock_vendor gtest_vendor launch_testing_ament_cmake python_cmake_module rcl_logging_log4cxx rmw_connext_cpp rmw_connext_shared_cpp rmw_implementation_cmake rosidl_adapter rosidl_cmake rosidl_generator_c rosidl_generator_dds_idl rosidl_parser rosidl_typesupport_connext_c rosidl_typesupport_connext_cpp rosidl_typesupport_interface test_interface_files

As a ros2_control user, I would like to define my control system with chained controllers

Design

It is a common design in control theory to define certain parts of a controller's equation with another controller.
In our case, we need to allow one controller's input to be defined by the output of another.
This can be achieved by the shared-memory message passing available within the same executor.
Ensure that the RobotHW and controller manager operate on the same executor with all other controllers.

A configuration file-based approach has to be established which defines

• the internal parametrization,
• the inter-controller connections and
• the order in which the controller update()-s should be called.

References

Re-enable macOS build workflow

Once ros-tooling/action-ros-ci#81 is resolved, the build.yml workflow should be updated to include macos in the build matrix:

...
run-on: macos-latest
...