-
Notifications
You must be signed in to change notification settings - Fork 124
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
port platooning_control to ros2 #2377
Conversation
carma/launch/guidance.launch
Outdated
<!--Platooning Control Plugin--> | ||
<include file="$(find platoon_control)/launch/platoon_control.launch" /> | ||
|
||
<!--Platooning Control IHP Plugin--> |
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.
you can remove the ihp plugin too. We wont need it
platooning_control/README.md
Outdated
@@ -1,7 +1,7 @@ | |||
# platoon_control | |||
|
|||
Platooning Control plugin which allows platooning to maintain the gap; moreover, generates longitudinal and lateral control commands to follow the trajectory. The structure of this plugin is very similar to the control plugin for IHP2, so the same design document is included here. | |||
The difference between platoon_control, and platoon_control_ihp is that the IHP plugin includes logic to open or close the gap between platoon members, to allow for a new member to join or an existing memeber to exit the platoon. | |||
The difference between platoon_control, and platoon_control_ihp is that the IHP plugin includes logic to open or close the gap between platoon members, to allow for a new member to join or an existing memeber to exit the platoon. |
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.
I dont think we need this paragraph anymore since the control ihp will be removed. You can add a few sentences saying it includes logic from control ihp, and autoware pure pursuit
platooning_control/include/platoon_control/platoon_control_worker.hpp
Outdated
Show resolved
Hide resolved
@@ -23,22 +23,24 @@ | |||
- /guidance/plugins/inlanecruising_plugin | |||
- /guidance/pure_pursuit_wrapper | |||
- /guidance/yield_plugin | |||
- /guidance/plugins/platoon_control |
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.
I wouldn't probably add platooning to required plugins
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.
Related issue here: #2383
Left a lot of comments, so please use your own judgement on what to address. But just wanted to bring these up so that we can also remember to look for such things in future PRs. |
/** | ||
* \brief Extending class provided method which can optionally handle trajectory plan callbacks. | ||
*/ | ||
virtual void current_trajectory_callback(carma_planning_msgs::msg::TrajectoryPlan::UniquePtr msg); |
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.
I dont think you can make the trajectory callback pure virtual, other controllers dont have their own implementation and depend on it to receive the trajectory.
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.
This one won't be pure virtual (doesn't include the =0). Also i'm able to build the pure pursuit wrapper
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.
you are right, it was shown in multiple lanes and I thought I saw the =0
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.
I put all the callbacks in protected, can you do the same? to avoid merge conflicts?
platooning_control/CMakeLists.txt
Outdated
@@ -46,7 +46,7 @@ ament_auto_add_executable(${node_exec} | |||
) | |||
|
|||
# Register component | |||
rclcpp_components_register_nodes(${node_lib} "platoon_control::PlatoonControlPlugin") | |||
rclcpp_components_register_nodes(${node_lib} "platooning_control::PlatoonControlPlugin") |
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.
sorry, not to cause extra work, but if the namespace is now platooning, shouldn't the class also be PlatooningControl?
/** | ||
* \brief Extending class provided method which can optionally handle trajectory plan callbacks. | ||
*/ | ||
virtual void current_trajectory_callback(carma_planning_msgs::msg::TrajectoryPlan::UniquePtr msg); |
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.
I put all the callbacks in protected, can you do the same? to avoid merge conflicts?
Quality Gate passedIssues Measures |
<!-- Thanks for the contribution, this is awesome. --> # PR Details This PR removes reference to platoon_control_ihp node as the node has been removed under usdot-fhwa-stol/carma-platform#2377 This PR also adds a note for using control plugins. Under current implementation it is required that only a single control node be activated at a time, as activating multiple control nodes will cause each node to publish commands for as long as they are activated. This means that if a certain plugin is activated and not responsible for control cmds for a specific trajectory plan, it will publish empty commands that are populated with a valid value of 0.0 for speed and steering. ## Description <!--- Describe your changes in detail --> ## Related Issue <!--- This project only accepts pull requests related to open issues --> <!--- If suggesting a new feature or change, please discuss it in an issue first --> <!--- If fixing a bug, there should be an issue describing it with steps to reproduce --> <!--- Please link to the issue here: --> ## Motivation and Context <!--- Why is this change required? What problem does it solve? --> ## How Has This Been Tested? <!--- Please describe in detail how you tested your changes. --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. --> ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [x] Defect fix (non-breaking change that fixes an issue) - [ ] New feature (non-breaking change that adds functionality) - [ ] Breaking change (fix or feature that cause existing functionality to change) ## Checklist: <!--- Go over all the following points, and put an `x` in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> - [ ] I have added any new packages to the sonar-scanner.properties file - [ ] My change requires a change to the documentation. - [ ] I have updated the documentation accordingly. - [x] I have read the **CONTRIBUTING** document. [CARMA Contributing Guide](https://github.com/usdot-fhwa-stol/carma-platform/blob/develop/Contributing.md) - [ ] I have added tests to cover my changes. - [ ] All new and existing tests passed.
PR Details
Ports the platooning control plugin to ros2.
Description
Related GitHub Issue
Related Jira Key
https://usdot-carma.atlassian.net/browse/CAR-5188
Motivation and Context
How Has This Been Tested?
Unit Test and Local Integration Test.
Types of changes
Checklist: