ros-planning / navigation2 Goto Github PK

@tfoote @wjwwood @dirk-thomas - can we get a Github Project created for the Navigation2 work so that we can have a public Kanban board for tracking issues and progress on the project? Thanks, Matt

We shouldn't need this file. Include rclcpp.hpp and use rclcpp::get_logger() instead
src/planning/nav2_dijkstra_planner/src/Logger.h

In the behavior tree version of the navigator, run the global planner continuously, feeding the updated plan to the control module.

Note: Rename the class to follow the naming standard: StrUtils and the filename strutils.hpp.
The file name to include should be: "nav2_util/strutils.hpp"

The mission plan should have a schema against which we can validate that the incoming mission plan is syntactically valid. The Mission Executor will perform this validation before using the plan to create the behavior tree.

Determine if the TaskServer should spawn its own thread or use the callback thread for the work.

Port ROS AMCL package to ROS2 and then integrate it as a supporting module to Navigation2 package.

Some food for thought: currently I'm working on a robot that could use collisions as one of its localisation inputs (think of a Roomba-like vehicle). I'm not at the stage of developing planners yet, but my intention was to implement a planner that plans for collision in some specific cases like walls or other static objects.

What's the idea regarding the collision avoidance requirement (i.e. what kind of restrictions on the design) and how would or relate with my idea?

Add a waitForServer method to the TaskClient template class which waits for the TaskServer to be running. This method should take a timeout value with a default value.

Right now all the RCLCPP_INFO messages look like this one for example:
RCLCPP_INFO(get_logger(), "MissionExecutor::~MissionExecutor")

Let's change these to something more useful to the end user. For example, this one instead could be "Shutting down Mission Executor".

For demonstration purposes, add a recovery behavior to the BtNavigator to show a more complex behavior tree.

We need to verify that our localization can work with the robot_localization package which has recently been ported to ROS2.

Coming from the standard nav stack and having built a few alternatives over time, I dont look at this project and have a good understand what's happening or how the elements interact.

Is there a plan to make a block diagram much like the move_base one to clear up your architectural intentions? It's challenging to get involved or track without it.

We need to resolve the licensing. ROS Navigation uses BSD 3. Most of ROS2 core uses Apache 2.0. For new code, we could license it Apache 2.0, but we assume there will be some code ported from ROS (BSD). How is this being handled by other ROS2 projects?

Test project /home/crdelsey/src/ros_dev_workspace/navigation2/build/nav2_dijkstra_planner
Start 1: copyright
1/5 Test #1: copyright ........................***Failed 0.46 sec
Start 2: cppcheck
2/5 Test #2: cppcheck ......................... Passed 0.50 sec
Start 3: cpplint
3/5 Test #3: cpplint .......................... Passed 0.75 sec
Start 4: lint_cmake
4/5 Test #4: lint_cmake ....................... Passed 0.48 sec
Start 5: uncrustify
5/5 Test #5: uncrustify ....................... Passed 0.62 sec

80% tests passed, 1 tests failed out of 5

Currently, the robot's starting pose is stubbed out in the BtNavigator and SimpleNavigator classes. Instead, it should come from the Localization module.

Replace the stub DWA Controller with the actual DWA algorithm.

Currently the metapackage exists under 'src' directory, the navigation stack and most other ROS metapackages are not organized this way and leads to a level of confusion

Start re-factorization by factoring out Particle Filter, Sensors, and Map from the AMCL package.

Including task canceling.

Most of the .gitignore files are empty. These need to be either populated or removed.

Go over the code to see if it has functionality to ignore dynamic objects.

Right now ROSRobot is an empty shell class with no functionality. It needs to be defined and implemented or the code should be removed.

Test project /home/crdelsey/src/ros_dev_workspace/navigation2/build/nav2_amcl
Start 1: copyright
1/5 Test #1: copyright ........................***Failed 0.47 sec
Start 2: cppcheck
2/5 Test #2: cppcheck ......................... Passed 0.51 sec
Start 3: cpplint
3/5 Test #3: cpplint ..........................***Failed 0.75 sec
Start 4: lint_cmake
4/5 Test #4: lint_cmake .......................***Failed 0.46 sec
Start 5: uncrustify
5/5 Test #5: uncrustify .......................***Failed 0.77 sec

20% tests passed, 4 tests failed out of 5

The Mission Executor will interpret the incoming mission plan, creating a behavior tree. It will then execute the resulting behavior tree.

We need to create a metapackage that brings in all our sub-packages as dependencies.

Test project /home/crdelsey/src/ros_dev_workspace/navigation2/build/nav2_util
Start 1: copyright
1/5 Test #1: copyright ........................***Failed 0.46 sec
Start 2: cppcheck
2/5 Test #2: cppcheck .........................***Failed 0.53 sec
Start 3: cpplint
3/5 Test #3: cpplint ..........................***Failed 1.15 sec
Start 4: lint_cmake
4/5 Test #4: lint_cmake ....................... Passed 0.46 sec
Start 5: uncrustify
5/5 Test #5: uncrustify .......................***Failed 1.06 sec

Current method uses spin_some and count_subscribers in a loop, without sleeping.

To ensure we are warning free, we should add the -Werror flag to our CMakeLists.txt files.

We have several build dependencies right now, like message_filters, that aren't available as packages. We need a method to track and then automate the pull and build of those if possible. Something like a build script that pulls the source, sources the correct setup files and runs colcon build.

Currently we're building only executables for the various ROS nodes. We also need to build libraries to enable composition in a single process.

Support an extensible framework of map representations via a Mapping Interface and incorporate relevant static, dynamic, object, and semantic map data into an Environmental Model to be used by map dependent algorithms.

First aim is to support & refactor grid-based map representations such as grid_map, occupancy grids, and costmap_2d with further aim to support interface for other tree/node-based representations such as octomap.

Currently when building AMCL, there are a lot of warnings spewing out. I realize that this code will be refactored, but want an issue to make sure these are cleaned up. I want to be able to add the -Werr compiler flag to the CMakeLists.txt going forward, so I'll file a separate issue for that.

Test project /home/crdelsey/src/ros_dev_workspace/navigation2/build/nav2_dwa_controller
Start 1: copyright
1/5 Test #1: copyright ........................ Passed 0.46 sec
Start 2: cppcheck
2/5 Test #2: cppcheck ......................... Passed 0.46 sec
Start 3: cpplint
3/5 Test #3: cpplint .......................... Passed 0.49 sec
Start 4: lint_cmake
4/5 Test #4: lint_cmake .......................***Failed 0.45 sec
Start 5: uncrustify
5/5 Test #5: uncrustify ....................... Passed 0.47 sec

80% tests passed, 1 tests failed out of 5

How do we handle the dependency on the BTpp library since it doesn't have an Ubuntu package. We could require anyone building this repo to first build Btpp from source and install. Other options?

Currently, the TaskServer derives from the ROS Node class. Instead, it should accept a ROS Node SharedPtr in its constructor. This will allow more flexibility in deployment, such as having multiple TaskServers per node. Once the TaskServer is updated, the TaskClient can also be updated to accept a Node::SharedPtr instead of a Node *.

Right now the Mission Plan message is defined as a string.src/mission_execution/nav2_mission_execution_msgs/msg/MissionPlan.msg

We need a real Mission Plan, whether that is an array of actions or something else is not clear yet.

Now that we're getting some code working, we need some automated testing using CI (Jenkins? Travis?) to run for every pull request and periodically on every branch (or at least on the master branch).

Integrating path planner based on ros1 move_base navfn planner.

We're depending on Actions being implemented in ROS2, which aren't implemented yet. We need to try and pull that in, and some work is needed to design how they should be implemented. I'm linking this issue to the issue in ROS2 for this discussion.

Port ROS1 move_base NavFn Global Planner to ROS2

README files are empty, these should be populated with basic descriptions of each package.

Test project /home/crdelsey/src/ros_dev_workspace/navigation2/build/nav2_bt_navigator
Start 1: copyright
1/5 Test #1: copyright ........................ Passed 0.46 sec
Start 2: cppcheck
2/5 Test #2: cppcheck ......................... Passed 0.46 sec
Start 3: cpplint
3/5 Test #3: cpplint .......................... Passed 0.50 sec
Start 4: lint_cmake
4/5 Test #4: lint_cmake .......................***Failed 0.45 sec
Start 5: uncrustify
5/5 Test #5: uncrustify ....................... Passed 0.49 sec

80% tests passed, 1 tests failed out of 5

It could be interesting to start inventorying existing navigation-related solutions to draws inspiration, lessons etc from.
How about a design/community_package folder with per-topic collection ??

Here is a first few

Map representation :

• grid_map

Localization:

• robot_localization

Framework:

• move_base_flex

Use an existing format or create one. Would like to leverage existing GUI tools, if possible, to generate mission plans.