Skip to content

Conversation

mjeronimo
Copy link

…of a given task type.

Also create a shell BTNavigator class and introduce namespaces.

…of a given task type.

Also create a shell BTNavigator class and introduce namespaces.
@mjeronimo mjeronimo requested review from a user, orduno, mhpanah and mkhansenbot August 21, 2018 21:22
namespace nav2_tasks
{

using ComputePathToPoseCommand = nav2_tasks::msg::PathEndPoints;
Copy link
Contributor

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.

Copy link
Contributor

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...

Copy link
Author

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;
Copy link
Contributor

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);
Copy link
Contributor

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.

Copy link
Contributor

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) ?

)

target_link_libraries(mission_execution
target_link_libraries(mission_executor
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is unnecessary.


include_directories(
include
../task/include
../navigation/include
../nav2_tasks/include
Copy link

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
Copy link

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
Copy link

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)
Copy link

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.

Copy link
Author

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.

Carl Delsey and others added 5 commits August 23, 2018 09:49
* 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.

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
Copy link
Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😞

@orduno
Copy link
Contributor

orduno commented Aug 28, 2018

Wondering if we could remove the nav2_ prefix...

@orduno
Copy link
Contributor

orduno commented Aug 28, 2018

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. ?

@mjeronimo
Copy link
Author

mjeronimo commented Aug 28, 2018

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.

@mjeronimo
Copy link
Author

mjeronimo commented Aug 28, 2018

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.

Copy link
Contributor

@orduno orduno left a 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.

@mjeronimo mjeronimo merged commit 67c1e66 into ros-navigation:ros2_devel Aug 28, 2018
@mjeronimo mjeronimo deleted the bt-navigation-shell branch August 28, 2018 23:29
ghost referenced this pull request in logivations/navigation2 Mar 7, 2022
Co-authored-by: andriimaistruk <andriy.maistruk>
doisyg added a commit to doisyg/navigation2 that referenced this pull request Nov 27, 2023
…segment_CM

AUTO-1438 Use `/is_segment` collision monitor mode for segment action
turtlewizard73 pushed a commit to turtlewizard73/navigation2 that referenced this pull request Dec 14, 2024
* 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]>
mini-1235 pushed a commit to mini-1235/navigation2 that referenced this pull request Feb 5, 2025
This section describes the new functionality of selecting in NavigateToPose the BT to use in bt_navigator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants