-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ros2 control managers #147
Conversation
…ncy collision. ControllerManager prepared to initialize a controller with components.
…rce Manager give aditional error output.
…alize and use controllers. ResourceManager is now smart pointer. Enable undeclared paramters for the node.
Wit the last commit I kind of "closed the loop". So now is forward controller also loaded and called in update. I have a huge issue... It seams that is something wrong with the initializaition of the
There are many very nice additions in recent PRs from @Karsten1987 and I think we have to implement those also here. Therefore, I just want to emphasize the goal of this PR. I am very much aware that not all of the code here is realtime-friendly and that some concepts are sub-optimal. Nevertheless it provide a very concrete base to test different cases and optimize everything. After we resolve the issue with the I also added above the notes how to test this implementation on your computer. |
Enable undeclared parameters for the controller's LifecycleNode s. Renable controller_manager tests. Clean and extend `ros2_control_manager`. Use executor from the ros2_control_node.
I am glad to anounce that I resolved all the issues I had and this very-first, simple ros2_control implementaiton with components is working! There is one simple functionality behind it: "Just load the SystemHardware and robot's Joints from the URDF description, start contoller defined in YAML file and read-update-write data between the hardware and controller". The goal is to demonstrate the idea behind the components. |
The tests are missing! |
controller_interface/include/controller_interface/controller_interface.hpp
Show resolved
Hide resolved
controller_interface/include/controller_interface/controller_interface.hpp
Outdated
Show resolved
Hide resolved
hardware_interface/include/hardware_interface/resource_manager.hpp
Outdated
Show resolved
Hide resolved
command_interfaces_[joint_info.name] = joint->get_command_interfaces(); | ||
// TODO(anyone): add checking if Joint has state interfaces at all | ||
state_interfaces_[joint_info.name] = joint->get_state_interfaces(); | ||
joint_components_[joint_info.name] = joint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need this? I don't really see a strong need to know that mapping. But even if, why not just storing the instance of "hardware_info_list" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The controllers are accessing the joints using their names so using the names instead of hardware_info
cannot be directly searched.
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
std::map<std::string, std::shared_ptr< | ||
hardware_interface::components::Joint>> joint_components_; | ||
std::map<std::string, std::vector<std::shared_ptr< | ||
hardware_interface::components::Joint>>> joint_components_for_hardware_; | ||
std::map<std::string, std::shared_ptr< | ||
hardware_interface::components::Sensor>> sensor_components_; | ||
std::map<std::string, std::vector<std::shared_ptr< | ||
hardware_interface::components::Sensor>>> sensor_components_for_hardware_; | ||
|
||
/** | ||
* Map of joints and their command interfaces | ||
*/ | ||
std::map<std::string, std::vector<std::string>> command_interfaces_; | ||
|
||
std::map<std::string, std::vector<std::string>> claimed_command_interfaces_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if needed, consider using a unordered_map for speed.
…l/ros2_control into add_ros2_control_managers
…ollerManager's update(). Resource manager is using unodered_map
Thanks for the testing!
We are look into this in #177
This should be resolved now. Thanks! |
@destogl I was going to start looking at the tests, ilke you said we need a robot description. How do you think it's best to implement it? I was copying part of https://github.com/ros-controls/ros2_control_demos/tree/add_rrbot_system_position_joints/ros2_control_demo_robot/description into the test_robot_hardware, and use that in the tests. Any other ideas? |
I am heaving an issue with the logic change from this PR, specifically the loading of controllers configuring themselves in load_controller(name, type) before being ready. JointTrajectoryController, for example, is now being configured before it is getting it's parameters and it then complains about empty joint_names. Previously, there was configure() and activate() method that would be called after the controllers were loaded and parameters set. I am working on getting @ahcorde's work on gazebo_ros2_control updated. In the plugin's initialization it creates the ControllerManager, then calls the load_controller(name, type) which calls load_controller_impl internally, which calls on_configure() on the controller instance. Inside the on_configure of JointTrajectoryController is where it looks for joints parameters but no yaml has been loaded at this point. There is no longer a way to configure a controller loaded via pluginlib anymore. How would these loaded controllers initialize with their yaml under the new changes? Perhaps I am totally doing it wrong now, There is a note by @ahcorde that his load-controller-parameters code should be updated when "spawn functionality". |
You can take this description of any other description from the roadmap. @AndyZe also uses them in #167. Therefore, it would probably make sense to put them into |
We changed the logic in #139. There we decided to go almost the same way, from the logic perspective as in ROS1.
YAML should actually be loaded before starting any of those function, so before even calling
If you look the manual linked in the first post you can find working example of controller and hardware. |
Closing in favor of #216, as discussed in Meeting on 21st of October 2020. |
This PR implements: Updated on 7.10.2020
ResourceManager
- initial version to mange "SystemHardware" only (Example 1)ros2_control_node
- generic node to start the ROS2 control robotsControllerManager
- has nowResourceManager
and supports components which supports. controller manager has multiple callback groups.To limit amount of code in this PR, only functionalities needed for Example 1 - Robot will be implemented in this PR.
Solves #141, #142, and #143
To be done:
ControllerManagerNewWithManager
executor::
namespace (I am on Ubutnu 18 with eloquent, therefore needed....)How to test:
ros2_control
with componentsUPDATE: check the README in
ros2_control_demos