Core functionalities for the drivers

This package contains two libraries that implement the common functionalities of the 3 kuka drivers to reduce code duplications and make the code more maintainable.

Wrapper methods for specific services

The kuka_drivers_core::communication_helpers is a header-only library providing wrapper methods for commonly used features.

Synchronous service calls

rclcpp does not provide synchronous service calls, this is implemented in the service_tools.hpp

It provides the sendRequest() endpoint with following arguments:

• client [ClientT]: the initialized service client
• request [RequestT]: the filled request with appropriate type
• service_timeout_ms [int] (default: 2000): timeout for service discovery
• response_timeout_ms [int] (default: 1000): timeout for getting the response

The method returns the service response (as a shared pointer).

Example for calling the ListControllers service of the controller_manager:

rclcpp::Client<controller_manager_msgs::srv::ListControllers>::SharedPtr get_controllers_client_;
auto request = std::make_shared<controller_manager_msgs::srv::ListControllers::Request>();

// [...]

auto response =  kuka_drivers_core::sendRequest<controller_manager_msgs::srv::ListControllers::Response>(get_controllers_client_, request, 0, 1000);

ros2_control state handling

The library also contains the ros2_control_tools.hpp header, which implements wrapper methods for modifying the states of controllers and hardware components.

Endpoints:

The changeHardwareState() can change the state of one hardware component and has the following arguments:

• client [rclcpp::Client<controller_manager_msgs::srv::SetHardwareComponentState>::SharedPtr]: initialized client
• hardware_name` [std::string]: name of the hardware component
• state [uint8_t of enum]: desired state after state change (only one transition is possible with one call)
• timeout_ms [int] (default: 1000): timeout for the response

The method returns whether the transition was successful.

The changeControllerState() can change the state of more controllers and has the following arguments:

• client [rclcpp::Client<controller_manager_msgs::srv::SwitchController>::SharedPtr]: initialized client
• activate_controllers [std::vector<std::string>]: names of the controllers to activate
• deactivate_controllers [std::vector<std::string>]: names of the controllers to deactivate
• strictness [int32_t] (default: STRICT): whether to fail if one state change is unsuccessful

The method returns whether the transitions were successful.

Examples:

rclcpp::Client<controller_manager_msgs::srv::SetHardwareComponentState>::SharedPtr change_hardware_state_client_;
rclcpp::Client<controller_manager_msgs::srv::SwitchController>::SharedPtr change_controller_state_client_;

// [...]

// Activate hardware named 'lbr_iisy3_r760'
bool success1 = changeHardwareState(change_hardware_state_client_, "lbr_iisy3_r760", State::PRIMARY_STATE_ACTIVE);

// Activate 'joint_state_broadcaster' and 'joint_trajectory_controller'
bool success2 = changeControllerState(change_controller_state_client_, {"joint_state_broadcaster", "joint_trajectory_controller"}, {/*nothing to deactivate*/});

Core classes

Base classes with improved parameter handling

There are two core classes implemented in this repository, ROS2BaseNode for improved parameter handling, and ROS2BaseLCNode, which derives from the rclcpp_lifecycle::LifecycleNode class and implements lifecycle state transitions which would be usually implemented in the same way in every case. These are virtual functions, so it is possible to override them in the case of a different desired implementation.

Parameter handling

The base classes provide a wrapper method for parameter registration, which makes handling of parameters more convenient. This is done with the help of the ParameterHandler class, which includes a ParameterBase and a template Parameter<T> nested class for this purpose.

Improvements:

• The add_on_set_parameters_callback() is called in both of the constructors to register the callback for parameter change requests. This makes sure that the initial values of the parameters are synced from the parameter server.
• The parameter type is enforced automatically.
• The registered callback has access over all of the registered parameters, therefore the parameter server and the node is always in sync
• It is easy to register a callback for additional checks before requested parameter value is accepted.
• The user can define the lifecycle states, in which parameter changes are allowed using the ParameterSetAccessRights structure.
• There is a different endpoint for static parameters, which cannot be changed after initialization.

The Parameter<T> class supports the following parameter types (identical to the types supported by rclcpp::Parameter):

• bool
• int64_t (or type satisfying std::is_integral except bool)
• double (or type satisfying std::is_floating_point)
• std::string
• std::vector<uint8_t>
• std::vector<bool>
• std::vector<int64_t>
• std::vector<double>
• std::vector<std::string>

The nodes provide the registerParameter() and registerStaticParameter() endpoints with the following arguments:

• name [std::string]: name of the parameter
• value [T]: default value of the parameter

File truncated at 100 lines see the full file

Changelog for package kuka_drivers_core

0.9.2 (2024-07-10)

• Fix GCC warning causing unstable build

0.9.1 (2024-07-08)

• Add missing test dependency

0.9.0 (2024-07-08)

• Add package with core features necessary for all KUKA drivers
• Contributors: Aron Svastits, Gergely Kovacs, Mark Szitanics, Sandor Komaromi