-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Modify the directory structure to allow for multiple implementations … #28
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
Modify the directory structure to allow for multiple implementations … #28
Conversation
…of a given task type. Also create a shell BTNavigator class and introduce namespaces.
namespace nav2_tasks | ||
{ | ||
|
||
using ComputePathToPoseCommand = nav2_tasks::msg::PathEndPoints; |
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 suggest to rename ComputePathToPoseCommand to PathToPoseCommand since this is just a name for the command and the command itself is not performing the computation.
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.
Not sure if removing 'Compute' from the message name is better...
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've used a consistent naming for the commands <Action>Command. Where action is a verb followed by any nouns. For example: Compute, Follow, Navigate, etc. So, you end up with <Verb><NounsThatVerbOperatesOn>Command.
{ | ||
|
||
using ComputePathToPoseCommand = nav2_tasks::msg::PathEndPoints; | ||
using ComputePathToPoseResult = nav2_tasks::msg::Path; |
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.
Same with ComputePathToPoseResult. This is a msg that provides a result and it's not a function to compute a result.
} | ||
|
||
// Check if the planning task has completed | ||
TaskStatus status = planner_->waitForResult(path, 100); |
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.
We need to define constants.
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.
Could we do: planner_->waitForResult(path, 100ms) ?
src/mission_execution/CMakeLists.txt
Outdated
) | ||
|
||
target_link_libraries(mission_execution | ||
target_link_libraries(mission_executor |
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 line is unnecessary.
src/mission_execution/CMakeLists.txt
Outdated
|
||
include_directories( | ||
include | ||
../task/include | ||
../navigation/include | ||
../nav2_tasks/include |
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.
These are unnecessary if nav2_tasks and simple_navigator are made packages.
@@ -29,13 +29,13 @@ add_executable(dwa_controller | |||
) | |||
|
|||
target_link_libraries(dwa_controller | |||
robot | |||
nav2_robot |
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.
We should be able to delete this call
) | ||
|
||
ament_target_dependencies(dwa_controller | ||
rclcpp | ||
std_msgs | ||
nav2_msgs | ||
nav2_tasks | ||
robot |
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.
Should this one be nav2_robot?
} | ||
|
||
TaskStatus | ||
BTNavigator::executeAsync(const nav2_tasks::NavigateToPoseCommand::SharedPtr command) |
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 function and the executeAsync in simpleNavigator are very long and could be easily broken up into smaller logical chunks. I think if you do that, you could probably eliminate the need for that goto as well.
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.
Behavior trees handle this nicely for the BTNavigator. I'll see about making a function for the SimpleNavigator.
* Cleaning up build exports and imports. * Adding auto uncrustify and cppcheck to the build. This will automatically run uncrustify, cppcheck, and cpplint whenever you run the test suite (eg. colcon test) Also, somewhat unrelated, I added whitespace to package.xml to make it a bit easier to read.
* Created the DijkstraPlanner based on the core algorithms from Navfn ROS1 nav package. * Updated the SimpleNavigator to use the new DijkstraPlanner * Created an initial WorldModel node and Costmap mockup to test the new planner. * Fixed bug with TaskClient. * Added a few new messages and services related to Costmap. Made a few updates to the Path messages.
…of a given task type. Also create a shell BTNavigator class and introduce namespaces.
…vigation2 into bt-navigation-shell
|
||
vector<uint8_t> costmapFree = | ||
// 0 1 2 3 4 5 6 7 8 9 | ||
{o, o, o, o, o, o, o, o, o, o, // 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.
Unfortunately, this seems to be the format that cpplint wants.
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.
😞
Wondering if we could remove the nav2_ prefix... |
Regarding the nav2_util folder structure, instead of having nav2_util/include, nav2_util/src, might be better if each folder was a package: nav2_util/costmap/, nav2_util/map_loader, etc. ? |
Regarding the nav2_prefix: the directories, as I understand the convention, should be treated as separate packages (potentially separate repos). The nav2_ prefix associates the various projects (similar to mbf_). One exception so far is that Mission Planning/Execution might be useful outside of this navigation project/set of projects. That's why I kept it "mission_planning" for now. We can add the prefix if necessary. |
About the utility directory structure. I'm thinking we have a single utility library of various, relatively simple, functions/classes. If something grows to be worth a separate package, we can make it so. In this case Costmap (so far) fits the former situation - a simple class that can be included in a utility library. |
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.
Looks good to me. Made two additional comments.
Co-authored-by: andriimaistruk <andriy.maistruk>
…segment_CM AUTO-1438 Use `/is_segment` collision monitor mode for segment action
* Return distance_traveled from output port * Read ports from on_tick * Implement for spin * Lint * Fix rebase errors * Revert "Implement for spin" This reverts commit 0acecdf. --------- Co-authored-by: redvinaa <[email protected]>
This section describes the new functionality of selecting in NavigateToPose the BT to use in bt_navigator
…of a given task type.
Also create a shell BTNavigator class and introduce namespaces.