ros-controls / ros2_control_demos Goto Github PK
View Code? Open in Web Editor NEWThis repository aims at providing examples to illustrate ros2_control and ros2_controllers
Home Page: https://control.ros.org
License: Apache License 2.0
This repository aims at providing examples to illustrate ros2_control and ros2_controllers
Home Page: https://control.ros.org
License: Apache License 2.0
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
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.
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 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?
Feel free to revise explanations if need to
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.
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
:
Sensor
component - it does not have many dependenciesActuator
componentRobot
componentFollowing should be done (add additional items if needed):
rrbot
in the description folder (existing 2dof can be reused)*.ros2_control.xacro
for each robot typeMany 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
.
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
Check the description
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.
Originally posted by @bmagyar in ros-controls/ros2_controllers#131
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.
ros-controls/ros2_control#292 (comment)
follow what was done on the PR referenced above
For more details see discussion here and follow the links there.
Hi,
Are the gazebo files currently not on the repo? Searching for ros2_control_demo_hardware_gazebo returns nothing.
Thanks,
Simon
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.
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)
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.
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?
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.
The issues are found during the review of #68
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,
per README, there is a second package called ros2_control_demo_hardware_gazebo and wondering where is that missing package.
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:
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).
Finalize the demo_resource_manger to support all scenarios from the roadmap example - see ros-controls/roadmap#17
Test the following:
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".
*Hardware
structures in the internal model. Use templated classes to avoid possibility of mixing different types of components.demo_robot
demo_robot
- this is a point where it will be shown is concept is working, therefore be careful and suspicious/strict.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)
Related to #37
@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
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.
In this use case, it is assumed that the user wants to:
The goal is to show that this does not break the ros control API.
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
[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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.