Clarify with @bmagyar what is difference between Actions and Travis or are they exchangeable.

Check: #4

Tool changers are a usual component in an industrial robotic cell. ros2_control should be able to support a change of tools, i.e. hardware interfaces, of a robot.
This should be done without restarting the control node.
This could be done by dynamically loading and unloading the tool components (different sensors and actuators).
To support real-time constrains, one could load all the components on start and use init, start, stop, halt commands to control a tool.

Finalize the demo_resource_manger to support all scenarios from the roadmap example - see ros-controls/roadmap#17

Test the following:

• Loading of all robots
• Simple loop with read and write calls

I'll remove the comment, the joints should be exported in defined order as in URDF. We should add test for it.

Originally posted by @destogl in #37 (comment)

See comment from @bmagyar here

Modern robots provide usually multiple interfaces towards them, e.g. position, velocity, acceleration, force, etc. It is thinkable that in some cases a user wants to use different interfaces along the kinematic chain, e.g. position on joint 1-3 and velocity on joints 4-6. This is especially interesting for making very complex robots, like mobile manipulators, humanoid robots, etc.

In readme, ros2 control list_controller is wrong command.
Request that command "ros2 control list_controller" replace to "ros2 control list_controllers".

After building, these 2 demos don't exist:

ros2 launch ros2_control_demo_robot demo_robot_launch.py

ros2 launch ros2_control_demo_robot demo_robot_modular_launch.py

Build command:

colcon build --event-handlers desktop_notification- status- --cmake-args -DCMAKE_BUILD_TYPE=Release

There is overlap in the tests when running CI, Linters and Coverage actions. It would be nice to resolve this at some point.

Ideas? Best practices?

I thought I'd try to make a RRBotSystemMultiInterface according to the components_architecture_and_urdf_examples example that has position, velocity, and acceleration. Integration of the velocity or acceleration to position depends on whether these interfaces have been claimed, but how can the hardware interface see which command interfaces are currently claimed, or react to changes of the command interfaces claimed?

In the example, the problem pops up here: rrbot_system_multi_interface/L190-L200. This problem also popped up in my attempts to port Franka Emika Panda to ROS2. Previously the RobotHW would be able to notice the switch of controller in prepareSwitch and doSwitch, how should it be done with the new resource manager standing between the hardware_interface and the controller manager?

[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [ros2_control_node-1]: process started with pid [861]
[ros2_control_node-1] terminate called after throwing an instance of 'pluginlib::LibraryLoadException'
[ros2_control_node-1] what(): According to the loaded plugin descriptions the class ros2_control_demo_hardware/RRBotSystemPositionOnlyHardware with base class type hardware_interface::SystemInterface does not exist. Declared types are test_robot_hardware/TestTwoJointSystem test_system

When using hardware components they can be in different states. This is really considered in hardware_interface in ROS1, which often leads to a completely new start of the whole control system.

The states could be:

• LOADED: objects of components and interfaces are created (e.g. classes are loaded using pluginlib)
• CONFIGURED: parameters for the robot are read from parameter server and the objects are configured according to them
• INITIALIZED: there is communication with a real hardware (or simulation) and components are ready to start. No active movement allowed.
• RUNNING: active movement/control is allowed.
• STOPPED: as initialized, but previous state was running
• HALTED: similar to initialized, but an unexpected event occurred and the robot should be further used with caution. The next state is INITIALIZED, after the is solved.

For communication with some hardware very high frequencies are desirable, e.g. a force-torque sensor. Nevertheless, the control loop is usually limited to the robot hardware or the "slowest" data source. To enable flexible data access from hardware and filtering it should be possible to define the hardware communication loop separate from control loop.

• Test the whole chain for "batch" robot
• Test for the modular robot
• Check what happens if the robot has combined components/interfaces, e.g., Position and Velocity can be used together.

Check the description

check ros-controls/ros2_control#81

Related to #37

Dear @destogl ,
As mentioned during the ros2_control meeting I am willing to help.
From your designed document I tried to give it a shot in:
https://github.com/olivier-stasse/ros2_control_demos.git

It just a starting point to implement the generic headless robot taking inspiration from Dave Coleman and @Karsten1987

Please feel free to reorganize or start from something different if you wish.

Let me know how you want to organize, we can probably split the work by issuing issues in the project https://github.com/orgs/ros-controls/projects/1

I will very much appreciate if you drive this but let me know if you are short in time.

Thanks again for your nice proposal.
Best,

Feel free to revise explanations if need to

Hi,

Are the gazebo files currently not on the repo? Searching for ros2_control_demo_hardware_gazebo returns nothing.

Thanks,
Simon

Add test package for CI and to test the dynamic loading of components as they are implemented.

This is important for #6 so that one is able to test the implementation.

Do this first for the components and allow them not to load any ComponentHardware:

• First: Write a test for the Sensor component - it does not have many dependencies
• Test for the Actuator component
• Test for the Robot component

I'm trying to compile the add_rrbot_system_position_joints branch, and I'm getting this error:

.../ros2_control_demos/ros2_control_demo_hardware/include/ros2_control_demo_hardware/rrbot_system_position_only.hpp:50:15: error: ‘std::string hardware_interface::BaseSystemHardwareInterface::get_name() const’ marked ‘final’, but is not virtual

If I remove final it seems to compile fine.

For more details see discussion here and follow the links there.

Replace the following:

• ros2 control load_start_controller to ros2 control load --state start
• ros2 control load_configure_controller to ros2 control load --state configure

I am working on the Example 3.
https://github.com/ros-controls/roadmap/blob/master/design_drafts/components_architecture_and_urdf_examples.md#3-industrial-robots-with-integrated-sensor

The issues are found during the review of #68

• #68 (comment)
• #68 (comment)
• #68 (comment)
• use "ros2_control" everywhere for the framework name. Check all copyright headers. (e.g. as here)

• There should be one description for each robot in the roadmap example - see ros-controls/roadmap#17.

Following should be done (add additional items if needed):

• define description for rrbot in the description folder (existing 2dof can be reused)
• create *.ros2_control.xacro for each robot type
• prepare full xacro for the robot

The goal of this use case is to show how easily ROS can help robot makers.

Several discussions with people from FabLabs show that they do not know where to start.
Making a clear, lean example would be very helpful.

Maybe this is more about documentation, but it could show clearly where to put the real-time process, the access to the electronics to read sensors, call controllers and write the command.

Then briefly show in the documentation how all the functionalities visualization, playing back trajectories and planning are coming from free.

This could be nice for a PhD student making his own robot prototype.

Mobile manipulators are now a day almost in every research lab for robotics. These are basically multiple robots assembled into one mechanical construction. If each component is already ros2_control enabled there should be a simple way to create a complex robot (in ROS1 CombinedRobot).
Toward controllers, this construction should be transparent in terms that they automatically gain access to every one of them. This could be achieved using the DynamicJointState message.

I'm testing demo -b add_rrbot_system_position_joints.

In the file rrbot_system_position_only.launch.py, exist line executable='ros2_control_node', but in the package control_manager not exist ros2_control_node.

Could indicate the steps to run the demo correctly.

Thank you in advance.

Industrial robot has usually single interface for all joints, sensors, and actuators to the "outside world".
The ros2_control should enable custom protocol with such "on-block" communication toward hardware.

As discussed in #4, we will try to reduce the number of arguments passing in cmake.

Specifically, those are: -Wall -Wextra -Wpedantic

Removing those could produce problems on Windows. This should be removed and than later tested.

Check this discussion for more details.

• ComponentHardware
• SensorHardware
• ActuatorHardware
• RobotHardware

Many robotic components need initialization (e.g. homing) procedures to be ready to use.
Also, the components need to be able to recover themselves after an unexpected event, e.g. an emergency stop.

In ROS1, services are often used for this, and they are calling methods directly in hardware_interface. This is actually something which could be managed by the controller manager or at least the top-level robot interface to make it transparent throughout whole control chain.

I'll remove the comment, the joints should be exported in defined order as in URDF. We should add test for it.

Originally posted by @destogl in #37 (comment)

• ros2_control_demo_robot_headless
• ros2_control_demo_robot_gazebo
• ros2_control_templates (decided to be done later)

• Link with gazebo_ros2_control: Candidate PR #64
• Example of joint_trajectory_controller applied to gazebo_ros2_control

A robot as ros2_control structure should be extensible with additional tools, e.g. force-torque sensor, milling machine, etc.
This extension should be transparent for controllers by adding new data in the DynamicJointState message.
It is preferable to do this without any coding and just loading additional sensor component, i.e. hardware_interface (i the case that sensors is ros2_control enabled).

In this use case, it is assumed that the user wants to:

• Test various power electronics - and therefore can have various low level control: torque control, current control, current control + position (PD+),
• Design its own specific transmission protocol
• Transmit PID value computed by a Differential Dynamic Program (Gain scheduling)
• Create complex actuator with current sensor, absolute encoder, motor encoder, temperature, IMU

The goal is to show that this does not break the ros control API.

• dynamically load *Hardware structures in the internal model. Use templated classes to avoid possibility of mixing different types of components.
• Create classes for demo_robot
• Test demo_robot - this is a point where it will be shown is concept is working, therefore be careful and suspicious/strict.

per README, there is a second package called ros2_control_demo_hardware_gazebo and wondering where is that missing package.

Originally posted by @bmagyar in ros-controls/ros2_controllers#131

Create a new package ros_control_core in this repository to evaluate the concepts from the design document.

This is crucial for implementation of demo_robot.

The following issues need to be close before closing this one!

Probably is the simplest way to implement this in the following order:
#7
#10
#11
#12
#13
#14

@destogl travis is already enabled, I believe github actions can be largely copied over from the ros2_control repo and I also added this to the boilerplate project so you can assign tickets to the project directly

• BaseComponent
• Component
• Sensor
• Actuator
• Robot

Many researchers and hobbyists build their robots by using simple sensors and actuators which usually communicate using separate interfaces and protocols to a computer.
The ros2_control should support this so that one could create software equivalent of the hardware separating communication interfaces and protocols from a representation of the hardware in ros2_control.

This is a problem we've noticed with ros1_control. When transitioning from streaming commands (e.g. teleoperation or visual servoing) to trajectory planning, we need a way to verify that the robot has actually stopped.

Otherwise, the robot continues to move while the trajectory plan occurs, which makes the start state invalid and the trajectory will not execute.

ros-controls/ros2_control#292 (comment)

follow what was done on the PR referenced above