Add the requirements document #5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
crdelsey
reviewed
Jul 3, 2018
doc/README.md
Outdated
| @@ -0,0 +1,10 @@ | |||
|  | |||
There was a problem hiding this comment.
I think it'd be best to not copy the ros2-logo into our repo due to potential copyright and trademark issues.
There was a problem hiding this comment.
Sure, I'll check into the copyright status.
mikeferguson
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| GP001 | Global Planning | 1 | The Navigation System SHOULD have a Global Planning module which generates the route for the robot to follow for the specified primitive, respecting any policy guidance contained in the Mission Plan | Could use pluggable cost functions | ||
| GP002 | Global Planning.Inputs.Static Map | 1 | The Global Planner SHALL have a static map available that describes the environment | Assumes the map has already been created and available as an input |
There was a problem hiding this comment.
Should we try to move away from calling this "static map" -- a common use case would be running navigation at the same time as mapping -- to explore the environment. In this case, the map isn't "static" but rather slowly changing. In particular, the important part is that the map must have some "constant reference frame" even as it changes over time (for instance, you can arbitrarily move 0,0 and expect things to still work, but if you add onto the map at runtime, the system should be able to handle it).
There was a problem hiding this comment.
Yes, I think moving away from the "static" terminology is a good idea for the reasons you mention. The doc can simply mention "map" without indicating whether it is static or dynamic. I think the expectation is that it is slowly changing, as you mention.
mikeferguson
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| GP005 | Global Planning.Inputs.Policy | 1 | The Global Planner SHALL have policy guidance associated with the primitive operation to execute | This could be global policy and/or per-primitive policy | ||
| GP006 | Global Planning.Multiple Global Planners | 1 | As part of the Navigation System, there SHOULD be multiple global planners available and chosen depending on the primite to be executed | Dynamic selection of global planners | ||
| GP007 | Global Planning.High-End Planner | 1 | The Navigation System SHOULD implement a state-of-the-art planner | Can serve as an example to others developing global planners | ||
| GP008 | Global Planning.Low-End Planner | 1 | The Navigation System SHOULD implement a planner for low-compute targets | Can serve as an example to others developing global planners |
There was a problem hiding this comment.
Ideally, this module should also be extremely well commented and documented, such that it can be used as a teaching tool -- I presume it will be a fairly straight forward A* implementation, which means it can be easily understood by students and adapted during various coursework.
There was a problem hiding this comment.
Ok, I'll add that requirement. I suppose that goes for each of the (replaceable) modules in the navigation system.
mikeferguson
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| GP003 | Global Planning.Inputs.Current Pose | 1 | The Global Planner SHALL have the robot's current pose | The pose could be be provided manually or automatically determined (outside of this module) | ||
| GP004 | Global Planning.Inputs.Primitive to Execute | 1 | The Global Planner SHALL have the primitive operation to execute | ||
| GP005 | Global Planning.Inputs.Policy | 1 | The Global Planner SHALL have policy guidance associated with the primitive operation to execute | This could be global policy and/or per-primitive policy | ||
| GP006 | Global Planning.Multiple Global Planners | 1 | As part of the Navigation System, there SHOULD be multiple global planners available and chosen depending on the primite to be executed | Dynamic selection of global planners |
There was a problem hiding this comment.
In supporting this, I think you'll find that you also want to make it easy to "reset or disable" a planner. Most of these planners may have large memory usage, and for efficiency may not want to recreate them for each plan -- if you have multiple running at once, each taking up memory, you might actually run out of memory quickly. Having an easy API to say "hey, not using this planner for a while, have it release resources" would be very useful.
There was a problem hiding this comment.
Do you think that's worth the complexity versus simply loading and unloading them? If so, we can introduce this intermediate "disabled" state with the appropriate calls/messages.
mikeferguson
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MAP002 | Mapping.Dimensionality.2D | 1 | The Mapping System MUST provide 2D map information | ||
| MAP003 | Mapping.Dimensionality.2D+ | 1 | The Mapping System MUST provide 2D+ map information | *TODO: How is this defined?* | ||
| MAP004 | Mapping.Dimensionality.3D | 1 | The Mapping System SHOULD provide 3D map information | *TODO: Use voxel-based?* | ||
| MAP005 | Mapping.Multiple Maps Per Environment | 1 | The Mapping system SHOULD provide multiple maps of the same environment. | *TODO: Different scales and elevations?* |
There was a problem hiding this comment.
Any thoughts around tiling? Especially for out-of-memory situations?
mikeferguson
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
|
|
||
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| LOC001 | Localization.Robot Pose | 1 | The Localization module MUST provide the robot's current pose to the Navigation System | This could be manual or as a result of automatic localization; the Navigation System wouldn't know either way |
There was a problem hiding this comment.
This won't be exact -- so it should also provide an estimate of the accuracy (current navigation stack can't take that into account, but future local planners certainly could). The current message is PoseWithCovariance to accomplish this in ROS1.
|
I realize that it may be desirable to use Apache2 -- has any thought gone into the fact that the existing navigation stack is BSD? Are we intending that all planners/costmaps/etc will be entirely implemented from scratch? I can see that taking a very long time to debug the numerous edge cases that the current stuff covers.... |
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| * **Local Planning** - The Local Planning module, of which there could also be several specialized implementations, uses the defined route from the Global Planner and information from robot sensors to handle any required deviations from the route to achieve its goal. | ||
| * **Robot Interface** - The Robot Interface is an abstraction of the robot platform, providing the means to control the robot and learn about its capabilities. There should be a standard set of messages to control the robot and, perhaps, a standard way to determine a robot's capabilities and attributes. This may require a layer on top of the vendor interface. | ||
|
|
||
|  |
There was a problem hiding this comment.
Do you think this use of the turtlebot image falls under the "fair use" defense?
There was a problem hiding this comment.
I would think so. But furthermore, I think the turtlebot BDFL group would OK it either way. The Turtlebot is designed to be the onboarding point for using the core ROS apps. It depends heavily on the nav stack in ROS1, and will almost certainly depend on this package in ROS2.
There was a problem hiding this comment.
I'll look into the status of the turtlebot image as well (and any future images).
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
|
|
||
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| IC001 | Developer's Guide | 1 | The Navigation System SHALL be developed in accordance with the ROS 2 Devloper's Guide | [ROS 2 Developer's Guide](https://github.com/ros2/ros2/wiki/Developer-Guide) |
There was a problem hiding this comment.
Should be a SHOULD instead of a SHALL. There are always exceptional circumstances where it is better to not follow the style guide.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| IC001 | Developer's Guide | 1 | The Navigation System SHALL be developed in accordance with the ROS 2 Devloper's Guide | [ROS 2 Developer's Guide](https://github.com/ros2/ros2/wiki/Developer-Guide) | ||
| IC002 | Implementation Language.C++.Version | 1 | Developers SHALL assume the availability of C++14 language features | Per the ROS 2 Developer's Guide |
There was a problem hiding this comment.
Also, should be a SHOULD.
We MUST build on Windows, where the Visual Studio compiler almost certainly doesn't support all C++14 features.
There was a problem hiding this comment.
Hmm. The ROS2 Developer's Guide mentions C++14 and I just called it out here for emphasis. I suggest we do assume C++14 and deal with any issues encountered with the Microsoft compiler (conditionalize, if necessary).
There was a problem hiding this comment.
If there's a known list of unsupported C++14 features in Windows, let's review that offline. Do we know if such a list exists?
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| -- | ------ | -------- | ----------- | ----- | ||
| IC001 | Developer's Guide | 1 | The Navigation System SHALL be developed in accordance with the ROS 2 Devloper's Guide | [ROS 2 Developer's Guide](https://github.com/ros2/ros2/wiki/Developer-Guide) | ||
| IC002 | Implementation Language.C++.Version | 1 | Developers SHALL assume the availability of C++14 language features | Per the ROS 2 Developer's Guide | ||
| IC003 | Implementation Language.C++.API Preference | 1 | Developers SHALL prefer standard C++, then Boost, then custom code, in that order. | Boost may be used if equivalent functionality is not already available in the C++ standard library |
There was a problem hiding this comment.
Another SHOULD. I can imagine circumstances where the Boost or Standard Library options are less convenient than custom code, or where the custom code is so small it doesn't make sense to bring in a additional boost dependency.
There was a problem hiding this comment.
True, there could always be an exception and we should leave it up to the developer.
There was a problem hiding this comment.
Does it make sense to have this section at all or just point to the ROS2 standard and only call out any additions or exceptions to that standard that we're making? Aren't IC002-IC006 already covered in the ROS2 standard? Sorry I haven't looked specifically for these.
There was a problem hiding this comment.
Yeah, we could take that approach. I was calling out a few key items for emphasis.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| IC004 | Implementation Language.C++.Supported Compilers.Clang | 1 | The Navigation System code SHALL compile with Clang, version *x* | ||
| IC004 | Implementation Language.C++.Supported Compilers.Intel C++ Compiler | 1 | The Navigation System code SHOULD compile with the Intel C++ Compiler, version *x* | Could be useful for optimization purposes | ||
| IC005 | Implementation Language.Python.Version | 1 | Any Python code developed for the Navigation System MUST use Python 3 | ||
| IC006 | Implementation Language.GUI | 1 | Any GUIs developed as part of the Navigation System MUST use the Qt library, via C++ or Python (PyQt) | *Which version?* |
There was a problem hiding this comment.
This seems like it should be an implementation detail, depending on the GUI.
There was a problem hiding this comment.
Yes, the section is on specific implementation constraints we want to call out. If we're OK with GUIs being implemented using any library, we can drop the requirement. Any other opinions?
There was a problem hiding this comment.
I think the word MUST here is too strong. Maybe SHOULD is the right word. I think this is a development preference, but not a hard requirement. Either that or remove completely as Carl suggested.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| IC005 | Implementation Language.Python.Version | 1 | Any Python code developed for the Navigation System MUST use Python 3 | ||
| IC006 | Implementation Language.GUI | 1 | Any GUIs developed as part of the Navigation System MUST use the Qt library, via C++ or Python (PyQt) | *Which version?* | ||
| IC006 | Implementation Language.GUI.QML | 1 | Any GUIs developed as part of the Navigation System MAY use QML | ||
|
|
There was a problem hiding this comment.
We need to figure out what the Windows and OS X build tools will be.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| DEV001 | Tools.ROS2.Version | 1 | The Navigation System WILL be developed against the latest stable version of the ROS 2 stack | *What is the current latest version?* | ||
| DEV002 | Tools.Unit Test.Library | 1 | *TODO: GTest and GMock?* |
There was a problem hiding this comment.
Implementation detail.
And Catch 2 seems like an interesting alternative to Gtest
There was a problem hiding this comment.
Only if we're OK with using any unit test library (or various unit test libraries). If we care, we should call it out.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| -- | ------ | -------- | ----------- | ----- | ||
| DEV001 | Tools.ROS2.Version | 1 | The Navigation System WILL be developed against the latest stable version of the ROS 2 stack | *What is the current latest version?* | ||
| DEV002 | Tools.Unit Test.Library | 1 | *TODO: GTest and GMock?* | ||
| DEV003 | Tools.Unit Test.Module Requirements | 1 | *TODO: What are the module level requirements?* |
There was a problem hiding this comment.
Actually, all the rest of this section seems like implementation details.
There was a problem hiding this comment.
Sure. We can define this section elsewhere.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| MP001 | Mission Planning.Primitives | 1 | The Mission Plan MUST be able to express the plan as a sequence of the following Primitives (MP002 - MP010) | ||
| MP002 | Mission Planning.Primitives.Navigate to Position | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified destination pose. |
There was a problem hiding this comment.
What if the planner can't find a path? Then we can't meet this requirement.
There was a problem hiding this comment.
Yeah, should be rephrased to allow for failure (and the resulting reporting of the failure).
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP001 | Mission Planning.Primitives | 1 | The Mission Plan MUST be able to express the plan as a sequence of the following Primitives (MP002 - MP010) | ||
| MP002 | Mission Planning.Primitives.Navigate to Position | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified destination pose. | ||
| MP003 | Mission Planning.Primitives.Navigate to Area | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified area. | *TODO: How to define "area"?* | ||
| MP004 | Mission Planning.Primitives.Enqueue | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a position behind another specified robot. |
There was a problem hiding this comment.
This requires a much more complicated understanding of the world than I think we want to incorporate into the navstack. It implies we can identify what things in the environment are robots and distinguish a particular one even as it moves around in traffic, possibly goes out of view etc.
There was a problem hiding this comment.
I concur -- this should provide a tool for generic navigation, and higher level "applications" would then call into the navigation stack.
There was a problem hiding this comment.
Yes, it comes back to the discussion of how much autonomy does the robot have and the location of the intelligence. It's important for us to draw that line. For example, the navigation could simply come down to NavigateToDestinationPose and the intelligence to allow for more complex maneuvers could be outside of the robot. Another example is the perception subsystem. It will track and classify objects in the environment (and, perhaps, predict their trajectories). The robot could "understand" these objects and respond accordingly, or the mapping from object to behavior could be outside of the robot and the resulting desired motion communicated to the robot. I think this discussion is key.
There was a problem hiding this comment.
I was think this could be done inside a planner as a "follow" maneuver. It wouldn't be part of the "standard" planners. Maybe the wording here should be "MUST allow for a planner to navigate..."
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP002 | Mission Planning.Primitives.Navigate to Position | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified destination pose. | ||
| MP003 | Mission Planning.Primitives.Navigate to Area | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified area. | *TODO: How to define "area"?* | ||
| MP004 | Mission Planning.Primitives.Enqueue | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a position behind another specified robot. | ||
| MP005 | Mission Planning.Primitives.Follow | 1 | The Navigation System MUST be able to direct the Robot to follow another specified robot. | This one doesn't have a completion state (reaching the goal), unless it specifies some more information such as "follow until destination reached" |
There was a problem hiding this comment.
Are we planning to implement object detection and tracking to accomplish this task? Or does the Nav stack gets a series of waypoints from other supporting modules?
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP003 | Mission Planning.Primitives.Navigate to Area | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a specified area. | *TODO: How to define "area"?* | ||
| MP004 | Mission Planning.Primitives.Enqueue | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a position behind another specified robot. | ||
| MP005 | Mission Planning.Primitives.Follow | 1 | The Navigation System MUST be able to direct the Robot to follow another specified robot. | This one doesn't have a completion state (reaching the goal), unless it specifies some more information such as "follow until destination reached" | ||
| MP006 | Mission Planning.Primitives.Orbit | 1 | *TODO: How is this defined?* | Similar to Follow in that it doesn't complete (unless it specifies time) |
There was a problem hiding this comment.
Orbit what? I can see potentially orbitting a fixed position in the world. Orbitting an object seems outside our scope.
There was a problem hiding this comment.
I forgot who suggested this one, but I had it in my notes. Hopefully, someone will recognize and comment.
There was a problem hiding this comment.
I see this also as a 'special' planner. In the navigation stack itself, we must allow for these types of operations to be implemented as extensions.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP004 | Mission Planning.Primitives.Enqueue | 1 | The Navigation System MUST be able to navigate the Robot from its current location to a position behind another specified robot. | ||
| MP005 | Mission Planning.Primitives.Follow | 1 | The Navigation System MUST be able to direct the Robot to follow another specified robot. | This one doesn't have a completion state (reaching the goal), unless it specifies some more information such as "follow until destination reached" | ||
| MP006 | Mission Planning.Primitives.Orbit | 1 | *TODO: How is this defined?* | Similar to Follow in that it doesn't complete (unless it specifies time) | ||
| MP007 | Mission Planning.Primitives.Wait | 1 | The Navigation System MUST be able to idle at the current location until directed otherwise |
There was a problem hiding this comment.
Could this just be reduced to not having a specified objective? What would the robot do if it isn't given a wait primitive?
There was a problem hiding this comment.
"Wait" should be changed to "HoldPose". For example: the robot is on an inclined plane and the user wants the robot to stay at its current pose. @crdelsey If the HoldPose primitive is not given the robot would role in this example.
There was a problem hiding this comment.
HoldPose may also be considered to be out of scope for Nav stack. The robot's base controller should take care of holding the pose.
There was a problem hiding this comment.
The wait state might be part of the mission plan, but may be implemented in the mission executor/controller and not the planners.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP005 | Mission Planning.Primitives.Follow | 1 | The Navigation System MUST be able to direct the Robot to follow another specified robot. | This one doesn't have a completion state (reaching the goal), unless it specifies some more information such as "follow until destination reached" | ||
| MP006 | Mission Planning.Primitives.Orbit | 1 | *TODO: How is this defined?* | Similar to Follow in that it doesn't complete (unless it specifies time) | ||
| MP007 | Mission Planning.Primitives.Wait | 1 | The Navigation System MUST be able to idle at the current location until directed otherwise | ||
| MP008 | Mission Planning.Primitives.Park | 1 | *TODO: What does parking mean? Some low-power state?* |
There was a problem hiding this comment.
Going to a low power state seems out of scope for the navstack.
There was a problem hiding this comment.
Do you think it would be automatically handled in the robot (if at all)?
There was a problem hiding this comment.
I agree, low power state seems out of scope.
There was a problem hiding this comment.
Does this mean dock to a charger? That maneuver could be a primitive, but then what happens next is platform dependent.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
|
|
||
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| MP001 | Mission Planning.Primitives | 1 | The Mission Plan MUST be able to express the plan as a sequence of the following Primitives (MP002 - MP010) |
There was a problem hiding this comment.
Is the intent to provide the nav stack a queue of commands eg. Go to position A, wait 5 minutes, go to position B, enqueue?
There was a problem hiding this comment.
I understand the desire to be able to "plan several legs of a trip at once, so if one is impassable you don't start the trip at all", but I feel like that is fairly incongruent with how actions typically are implemented. I know actionlib isn't implemented in ROS2 yet, but the issue I see arising is: how do you cancel part way through?
There was a problem hiding this comment.
Yes, that's the idea - what is the language that one would use in composing mission plans?
There was a problem hiding this comment.
I think of the plan as "Go to position A", "Go to position B", etc, but with a handshake between the steps put in place by the mission execution (control) module.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP006 | Mission Planning.Primitives.Orbit | 1 | *TODO: How is this defined?* | Similar to Follow in that it doesn't complete (unless it specifies time) | ||
| MP007 | Mission Planning.Primitives.Wait | 1 | The Navigation System MUST be able to idle at the current location until directed otherwise | ||
| MP008 | Mission Planning.Primitives.Park | 1 | *TODO: What does parking mean? Some low-power state?* | ||
| MP009 | Mission Planning.Primitives.Enter Elevator | 1 | The Navigation System MUST be able to navigate the Robot from its current location onto an elevator. | *TODO: Would the elevator door be automated?* |
There was a problem hiding this comment.
Why is this a special primitive? Can't "go to area" suffice?
There was a problem hiding this comment.
I'm not sure. We'd have to capture that the floor isn't always present, at least. It can't be freely navigated into.
There was a problem hiding this comment.
I'm not sure this is a primitive either, more a sequence of actions. "Move to area A (outside elevator)", "Move to area B" (inside elevator).
There was a problem hiding this comment.
Yes, I agree. I've updated the doc accordingly to mention that this could be a series of actions.
crdelsey
reviewed
Jul 3, 2018
doc/requirements/requirements.md
Outdated
| MP007 | Mission Planning.Primitives.Wait | 1 | The Navigation System MUST be able to idle at the current location until directed otherwise | ||
| MP008 | Mission Planning.Primitives.Park | 1 | *TODO: What does parking mean? Some low-power state?* | ||
| MP009 | Mission Planning.Primitives.Enter Elevator | 1 | The Navigation System MUST be able to navigate the Robot from its current location onto an elevator. | *TODO: Would the elevator door be automated?* | ||
| MP010 | Mission Planning.Primitives.Exit Elevator | 1 | The Navigation System MUST be able to navigate the Robot from its position in an elevator to a specified location outside the elevator. |
There was a problem hiding this comment.
Can't we just use go to location/area to get out of the elevator.
There was a problem hiding this comment.
I think we need to consider how to handle elevators and other kinds of lifts, where the mechanism has various states. If there's an external controller that's handling the elevator doors, etc., the Execution mechanism for the robot needs to at least feedback that it's ready to enter (or exit) an elevator and wait for the go-head. I think we should mock up some example mission plans and work through these issues.
There was a problem hiding this comment.
The misssion controller may just need to observe the robots pose and hold the door until it is out of the elevator a sufficient distance.
There was a problem hiding this comment.
Yes, I agree. I think this is also a sequence of more primitive actions.
added 7 commits
July 6, 2018 17:37
mkhansenbot
requested changes
Jul 12, 2018
doc/requirements/requirements.md
Outdated
| * **Performance** - *TODO: What are the performance goals?* | ||
| * **Scalability** - *TODO: How low should the implementation scale?* *Specify a minimum platform?* | ||
| * *Other important design goals?* | ||
|
|
There was a problem hiding this comment.
For these "TODO" items, lets open issues here in the github repo for discussion and tracking
There was a problem hiding this comment.
@mkhansen-intel I've addressed your feedback and have opened the issues in Jira as you've suggested. I also put the open issues at the end of the document for reference. Take a look and see if it's good to go.
doc/requirements/requirements.md
Outdated
|
|
||
| Id | Handle | Priority | Description | Notes | ||
| -- | ------ | -------- | ----------- | ----- | ||
| IC001 | Developer's Guide | 1 | The Navigation System SHOULD be developed in accordance with the ROS 2 Devloper's Guide | [ROS 2 Developer's Guide](https://github.com/ros2/ros2/wiki/Developer-Guide) |
LICENSE
Outdated
| @@ -0,0 +1,201 @@ | |||
| Apache License | |||
There was a problem hiding this comment.
Please remove the LICENSE file from this PR, we can add it in a separate PR
doc/README.md
Outdated
| See the [requirements document](requirements/requirements.md) for the current list of requirements. | ||
|
|
||
| # Contributing | ||
| To propose additions or changes to the requirements, modify the requirements document and submit a pull request for review. |
There was a problem hiding this comment.
Alternately, we may want people to file an issue for a requirement so that we can discuss first, then if it is good, we can ask them to submit a PR and link to the issue. That would be more consistent with a bug filing / fixing process.
doc/requirements/requirements.md
Outdated
| IC007 | Implementation Language.Python.Version | 1 | Any Python code developed for the Navigation System MUST use Python 3 | ||
| IC008 | Implementation Language.GUI | 1 | Any GUIs developed as part of the Navigation System SHOULD use the Qt library, via C++ or Python (PyQt) | *Which version?* | ||
| IC009 | Implementation Language.GUI.QML | 1 | Any GUIs developed as part of the Navigation System MAY use QML | ||
| IC010 | ROS2.Version | 1 | The Navigation System WILL be developed against the latest stable version of the ROS 2 stack | *What is the current latest version?* |
There was a problem hiding this comment.
This one is a little tricky. We should be developing against the 'latest' ROS2 code whenever possible, as we're targeting the "Crystal Clemmys" ROS2 release. That won't always be stable until after the release. So I would remove the word 'stable' and put "Crystal Clemmys"
doc/requirements/requirements.md
Outdated
| PLN006 | Planning.Inputs.Prediction.Predicted Trajectories | 1 | The Planning Module MUST have access to predicted trajectories of objects detected by the Perception Subsystem. | ||
| PLN007 | Planning.Inputs.Localization.Current Pose | 1 | The Planning Module MUST have access to the robot's current pose. | The pose could be be provided manually or automatically determined (outside of this module). | ||
| PLN008 | Planning.Outputs.Path | 1 | The Planning Module MUST output the Path for the robot to follow to execute the input Navigation Command and MUST respect any associated policy. | ||
| PLN009 | Planning.Feedback.Inputs | 1 | The Planning Module MUST receive error input from the downstream Execution Module. | So that it can attempt to recover from execution failures. |
There was a problem hiding this comment.
I think MUST is MAY for this one. The Mission Execution MUST receive the errors, but the planner may not need to do anything when an error occurs.
doc/requirements/requirements.md
Outdated
| PLN007 | Planning.Inputs.Localization.Current Pose | 1 | The Planning Module MUST have access to the robot's current pose. | The pose could be be provided manually or automatically determined (outside of this module). | ||
| PLN008 | Planning.Outputs.Path | 1 | The Planning Module MUST output the Path for the robot to follow to execute the input Navigation Command and MUST respect any associated policy. | ||
| PLN009 | Planning.Feedback.Inputs | 1 | The Planning Module MUST receive error input from the downstream Execution Module. | So that it can attempt to recover from execution failures. | ||
| PLN010 | Planning.Feedback.Inputs.Error Recovery | 1 | Upon receipt of a downstream failure, the Planning Module SHOULD attempt to automatically recover from the error. | Handling a robot that gets stuck or handling a collision, for example. |
There was a problem hiding this comment.
I thought this one is part of the Mission Execution role, to recover from downstream errors?
There was a problem hiding this comment.
I think it may be in both places. I'm thinking of it as handling errors as close to the source as possible. If the Planner can handle an error for downstream in the stack, it should. Otherwise, it can propagate as well as send any other kinds of errors that it can't handle itself. Then, MIssion Execution has a shot at handling. If it can't handle, then it too has to propagate. Let's get into architecture a bit to see if this is realistic. If not, I can update the requirements accordingly to reflect the new understanding.
doc/requirements/requirements.md
Outdated
| -- | ------ | -------- | ----------- | ----- | ||
| EXE001 | Execution | 1 | The Navigation System SHOULD have an Execution Module that generates commands to the robot to achieve a specific Path. | ||
| EXE002 | Execution.Inputs.Path | 1 | The Execution Module SHALL receive a Path that the robot is to follow. | ||
| EXE003 | Execution.Inputs.Policy | 1 | The Planning Module SHALL receive policy information associated with the Path to follow. | Could filter down from higher-level policy specification. |
There was a problem hiding this comment.
This should read "Execution Module"
doc/requirements/requirements.md
Outdated
| MAP014 | Mapping.Multiple Maps Per Environment | 1 | The Mapping System MAY provide multiple maps of the same environment. | Such as for different scales and elevations. | ||
| MAP015 | Mapping.Data Model.Extensibility | 1 | The Mapping System SHOULD be extensible, to allow for the description of additional entities in the environment. | ||
| MAP016 | Mapping.Dimensionality.2D | 1 | The Mapping System MUST provide 2D map information. | ||
| MAP017 | Mapping.Dimensionality.2D+ | 1 | The Mapping System MUST provide 2D+ map information. | *TODO: How is this defined?* |
doc/requirements/requirements.md
Outdated
| MAP015 | Mapping.Data Model.Extensibility | 1 | The Mapping System SHOULD be extensible, to allow for the description of additional entities in the environment. | ||
| MAP016 | Mapping.Dimensionality.2D | 1 | The Mapping System MUST provide 2D map information. | ||
| MAP017 | Mapping.Dimensionality.2D+ | 1 | The Mapping System MUST provide 2D+ map information. | *TODO: How is this defined?* | ||
| MAP018 | Mapping.Dimensionality.3D | 1 | The Mapping System SHOULD provide 3D map information. |
mkhansenbot
approved these changes
Jul 12, 2018
This was referenced Sep 7, 2018
This was referenced Jul 27, 2022
doisyg
added a commit
to doisyg/navigation2
that referenced
this pull request
Oct 5, 2023
AUTO-573 RPP update
Closed
turtlewizard73
referenced
this pull request
in turtlewizard73/navigation2
May 29, 2024
* correct error message * clean up * cleanup * remove header Co-authored-by: Joshua Wallace <josho.wallace@gmail.com>
turtlewizard73
referenced
this pull request
in turtlewizard73/navigation2
May 29, 2024
* Update nav2_multirobot_params_2.yaml * Update nav2_multirobot_params_1.yaml * Humble backport of MPPI controller (#3439) * Adding new MPPI controller to Nav2 (#3350) * adding new MPPI controller to Nav2 * fixing rename for Nav2 staging * using larger resource class * fix plugin name * wz typo * add mppi gif * Update defaults.yaml * Update makeflags to match core count of resource_class: large * Bump cache version for testing CI changes * fixing tests * remove unused function * Update config.yml * adding a little more detail * adding contextual note * adding contextual exceptions * Fix using different frame for global and local costmap (#3425) * getGlobalPlanConsideringBoundsInCostmapFrame Replace transformPlanPosesToCostmapFrame and getGlobalPlanConsideringBounds by getGlobalPlanConsideringBoundsInCostmapFrame * use stamp from robot pose for transform * style * fix test * lint test --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> --------- Co-authored-by: ruffsl <roxfoxpox@gmail.com> Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> (cherry picked from commit 8d4f6f4e2dcd37afae94d74e7b5b806ea78e9813) * Replace nav2_core exceptions with std::runtime_error * Get inflation layer parameters from node params * remove changes unrelated to mppi * fix eol * Add reset behavior (draft) * initialize last_time_called_ * add readme for reset_period * Revert "remove changes unrelated to mppi" This reverts commit 55fec35fdb82356e7952c9c9c3ee7fd7195422f4. * changing MPPI's SG filter to 9-point formulation (prev. 5) (#3444) * changing filter to 9 * fix tests (cherry picked from commit 7aee1e7be0349d486a0567aa397c34faa51e1018) * Adapt tests to humble Costmap2DROS constructor * cpplint * Update nav2_mppi_controller/README.md Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * address time comment * fix API change rclcpp::ServicesQoS() * fix CI --------- Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * fix ServicesQoS error (#3449) * [MPPI] Fix transformed path oscillations (#3443) (#3453) * use path distance instead of euclidean for upper bound search * rename to pruned_plan_end * rename to pruned_plan_end * fix tests * do not use prune_distance to limit the search for the closest pose --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> (cherry picked from commit 34f18d9222e33a2fddb2e45653cd5c0ef7b3bb11) Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> * Update photo_at_waypoint.cpp * Update photo_at_waypoint.hpp * hot patch to fix transform error in MPPI caused by #3425 (#3458) (#3459) (cherry picked from commit d4291438eea0abfdfc1632886cef0adfeea1e831) Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Fix out of bound vector (#3461) (#3463) (cherry picked from commit 0a63bf956e5da6e89946fde131303942e282c23b) Co-authored-by: Tony Najjar <tony.najjar.1997@gmail.com> * Trajectory visualizer namespaces (#3467) (#3469) * namespace trajectory visualizer markers (cherry picked from commit 124843cafe13d34d193699278f7163072328bbe3) * fix linters * fix typo (cherry picked from commit d8a22fa21d77ce0df8a8d4fc9693806115114b3b) Co-authored-by: Tony Najjar <tony.najjar@logivations.com> * fix segfault when path is empty (#3484) (#3485) a Co-authored-by: Guillaume Doisy <guillaume@dexory.com> (cherry picked from commit 26ac8104862b25151d98981da1731931fa16d1b3) Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> * Check compile options (#3487) (#3489) (cherry picked from commit e7259030f834ff19599206ae80a1ed5d05cd32d2) Co-authored-by: Tony Najjar <tony.najjar@logivations.com> * ackermann motion model bug (#3498) (#3501) Prevent cost to be modified twice. (cherry picked from commit 482017ce02ec08eadd3a23440e619b0e506cb9c5) Co-authored-by: HAIDAR OBEID <31267966+ObeidHaidar@users.noreply.github.com> * Fix robot navigator params getting overriden (#3562) * Humble sync 6 June 9: 1.1.7 (#3616) * Option allowing to use simple lookupTransform API (#3412) * Option allowing to use simple lookupTransform API ignoring time shifts between source and base frame during the movement * Refine comments * Fix wrong warning message format (#3416) * Fix wrong warning message format (Closes #3415) * fix code formatting * nav2_dwb_controller: add forward_prune_distance parameter (#3374) Until now, the prune_distance was used as distance threshold to shorten the upcoming path when shorten_transformed_plan was enabled. However, the prune and shortening mechanisms are de-correlated mechanisms. One could wish to use a different shortening distance for upcoming points, than the prune distance used for passed points. For this reason, a new parameter "forward_prune_distance" was added. * Fix service_name for server_name in cancel assisted teleop node * Fix mask coordinates calculation in worldToMask (#3418) * Remove goal checker default from follow path node * Correct CostmapFilters copyrights (#3423) * Correct the parameter description for AMCL (#3451) Signed-off-by: Trung Kien <letrungkien.k53.hut@gmail.com> * Add default service name to BTServiceNode (#3448) * Add default service name to BtServiceNode * docstring * fix initialization-list order * Update nav2_behavior_tree/include/nav2_behavior_tree/bt_service_node.hpp Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> --------- Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Fix Typos (#3452) * removing galactic from table as EOL (#3460) * Support for Dev Containers and Codespaces (#3457) * Alias image tag over current branch name * Duplicate build and push steps for dev tag * Alias image tag over current branch name * Modify build and push steps for dev tag * Build and push dev tag first to not cache from stale stages as otherwise caching from multple regestry images seems error prone * Revert "Build and push dev tag first" as otherwise the build failer durring the dev tag could then still block build of the main tag This reverts commit 12dd5b1a4e3f37847e6333b9e9ae9ef480a80623. * Cache from multple reference images while giving layers from the main tag priority this assumes that cache-from prioritizes firstly listed references https://github.com/moby/buildkit/blob/0ad8d61575be009ce6478edf1d85716849c8ff1a/solver/llbsolver/bridge.go#L92 * Cache tests in dev image as well colcon cache can then skip tests for uneffected packages * Add devcontainer.json * Ignore doc for image builds * Add more extensions * Change workspaceFolder to root src path to avoid auto generating .vscode folder in repo created by ms-iot.vscode-ros extension upon configuring ros packages with c_cpp_properties.json * Enable features for github-cli * Add docs about codespaces and have it opened when starting codespaces * Update update_ci_image.yaml to fix duplicate step ids and add workflow file to push paths * Patch CI actions and Dockerfiles (#3468) * Unset default value for FAIL_ON_TEST_FAILURE as unsetting it via --build-arg seems unreliable https://github.com/docker/compose/issues/3608 * Use build arg default for failing on test failers * Update from deprecated set-output commands https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ * Use Codespaces prebuilds (#3470) * Add commands to devcontainer * Set builtin bash to be safe https://gist.github.com/mohanpedala/1e2ff5661761d3abd0385e8223e16425 https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_pipefail/ * Setup workspace on create * Revert use of set -u for bash don't raise error due to variables otherwise colcon setup.sh chokes from using an unbounded path variable * Add safe.directory for git config otherwise colcon cache errors out because of issues with git due to complex user mapping magic that vscode does with devcontainers https://stackoverflow.com/questions/72978485/git-submodule-update-failed-with-fatal-detected-dubious-ownership-in-repositor also used by Moveit2: https://github.com/ros-planning/moveit2/pull/1994 https://github.blog/2022-04-12-git-security-vulnerability-announced/ * Set env using remoteEnv instead of inlining them in scripts * Revert to using the main tag now that the tester stage has been replicated with the new devcontainer script commands instead * formating * Scrap `-dev` image tag and use codspaces prebuilds instead * Build incrementally from update content command by copying the build workspace steps from circleci config * Adapt the build workspace steps for bash * Fix for different ceres isinf() API (#3471) * Fixing name of security launch file * Clean up pending service client request on interrupt/timeout (#3479) Signed-off-by: Øystein Sture <os@skarvtech.com> * Added str cast to parse int (#3486) Co-authored-by: antoniomarangi <antonio.marangi@alba-robot.com> * Add flag to not send request in BTServiceNode (#3431) * Add flag to not send request in BTServiceNode * rename goal to request * Fail if should not send goal * Update nav2_behavior_tree/include/nav2_behavior_tree/bt_service_node.hpp Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Update nav2_behavior_tree/include/nav2_behavior_tree/bt_service_node.hpp Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * . * fix linter * fix CI --------- Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Prepare test results to only use junit/xunit schema (#3441) * Set ctest arg to output junit To try and help CircleCI to parse the output files https://stackoverflow.com/a/70774733/2577586 * Replace the original Test.xml by outputting the junit to the same filename Context: https://github.com/colcon/colcon-cmake/blob/8f1b92a190b2ad4289ecf837c3200d540c13fdd9/colcon_cmake/task/cmake/test.py#L133 * Fix default formatting to a list WARNING:colcon.colcon_defaults.argument_parser.defaults:Default value 'ctest-args' for parser 'test' should be a list, not: --output-junit Test.xml * Revert junit file name https://circleci.com/docs/collect-test-data/#ctest-for-c-cxx-tests * Fine and rename ctest summary Test.xml * Fix find path * Simplify extention renaming * Copy ctest junit file into test_results so that they can be stored by CI * Revert ctest config modifications * Prepare Test Results by removing Test.xml generated by ctest to simplify fix for circleci * Reorder storage of test result artifacts before Test.xml files are removed so that they can still be archived and viewed for later * Use find command * Container retention via version tagging (#3491) * Use github action expression syntax to alias over github repository name * Tag by version instead of by timestamp * Avoid pushing untagged image to GHCR by setting provenance to false now that provenance is enabled by default as of v4 of docker/build-push-action - https://github.com/docker/build-push-action/pull/781 - https://github.com/docker/build-push-action/issues/778 * Use checkout action to set version output (#3492) Otherwise there is no source code to use to set the version output. Fixes: #3491 * Change directory to inside checked out repo (#3493) or relative path under $GITHUB_WORKSPACE that actions/checkout places the repository * Write and read from correct output mapping (#3494) * Revert "Change directory to inside checked out repo (#3493)" This reverts commit 332c1fb07bd787bab8a8eeea5fc896a944bb54d8. * Add `version` to outputs for check step and use output from `check` id * Use output from check_ci_files job * updating world in simple commander for TB3 package change (#3495) * Ensure version output is always set (#3503) even when github.event_name != 'push' by moving run step to same job as build-push action. Also set context path provided by checkout action to avoid future nonintuitive behavoir using default Git context, even when the checkout action appears to be being used. - https://github.com/docker/build-push-action#git-context - https://github.com/docker/build-push-action#path-context * Add labels to pushed image versions (#3505) using Pre-Defined Annotation Keys as defined by The OpenContainers Annotations Spec - https://specs.opencontainers.org/image-spec/annotations/#pre-defined-annotation-keys - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows - https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#get-a-repository * Typo README.md (#3506) * [Velocity smoother] Set zeros command if timeout (#3512) * Set zeros command if timeout * Fix lint * Fix gtest increase time to allow deceleration * Always update last_cmd_ * Revert test modif * remove test logs * Fix paste error * Update velocity_smoother.cpp * Update velocity_smoother.cpp * Improve Dev Container ergonomics (#3482) * Install and enable bash autocompletion by using apt durring on create command and by copying skelton .bashrc file that sources it by default * Edit apt for autocomplete by disabling docker-clean from containerized ubuntu * Add ROS2 Ament Task Provider extension Provides tasks and problem matchers for ROS2 projects using ament https://marketplace.visualstudio.com/items?itemName=althack.ament-task-provider * Source underlay for extentions to allow them to find the path to ros binaries such as ament_cpplint needed for althack.ament-task-provider * Target new dever stage in Dockerfile * Reduce need for internet after image build by installing developer dependencies earlier * Edit apt caching before apt updating * Source underlay systemwide this is a hacky workarround to ensure VS Code can run ShellExecution tasks with the ros envorment included in PATH otherwise, postponing this to the on-create-command results in vscode extentions not finding system installed ros commands this also works for all user shells regardless of how devontainers could change the user * Postpone bashrc setup to postCreateCommand once the dev container has been assigned to a user for the first time * Cleanup onCreateCommand as we don't use ros_entrypoint.sh for development and so it doesn't really need to be updated * Quite down the logs when building devcontainer * Formatting * Add refrence ccp properties config file generated from the vscode ROS extention but with the hardcoded paths in includePath deleted * Update version of cppStandard for ROS Rolling * Update workspaceFolder to use new .vscode folder * Mount ccache directory to volume to speed up rebuilding devcontainer whenever onCreateCommand is triggered because of modifications to .devcontainer/ files * Avoid use of containerEnv to express ccache direcotry as doing so is not possable, for more info: - https://stackoverflow.com/a/75759647/2577586 - https://github.com/microsoft/vscode-remote-release/issues/7147#issuecomment-1237779733 Just target a path in the temp direcotry instead * Stage auto generated includePath * Remove workspace install from include path except for autogenerated headers from message packages * Avoid hardcoded path to sorce folder * Avoid hardcoded path to install folder but this is still rather fragile as the reletive path between workspaceFolder and the colcon workspace isn't fixed * Sort list of paths * Remove cpp properties configuration as it seems it's existance prevents autoupdating the includePaths property unless user manually runs the vscode command `>ROS:Update C++ Properties` https://github.com/ms-iot/vscode-ros/blob/47d8f14f4ec0498cd9e8381e6fcc5f47abb340f2/src/extension.ts#L71 and even when this command is invoked it blows aways any customizated properties anyhow issue about wrong cppStandard tracked here: https://github.com/ms-iot/vscode-ros/issues/818 * Fix typo to move docker-clean from loaded config path * fix data race: addFilter() and resizeMap() can be executed concurrently (#3518) Co-authored-by: Dirk Braunschweiger <dirk.braunschweiger@symovo.de> * fix data race: prohibit resizeMap() during plugin/filter initialization (#3522) Co-authored-by: Dirk Braunschweiger <dirk.braunschweiger@symovo.de> * Mount overlay workspace into Dev Container via volume (#3524) * Add volume for overlay to avoid rebuilding it from scratch whenever the dev container is rebuilt this saves startup time locally when fiddling with the configs * Append devcontainerId to volume name to avoid conflicts with other devcontainers note that devcontainerId is stable across rebuilds - https://containers.dev/implementors/json_reference/#variables-in-devcontainerjson * Call updateContentCommand from onCreateCommand to deduplicate scripts and keep setup DRY given the addition of a mounted overlay volume which could include a prebuilt colcon workspace well before the dev container is created/rebuilt * Comment out colcon clean from setup to avoid unintentional removal of built packages from the persistent overlay workspace volume. Users can uncomment the line locally or simply remove the overlay workspace volume if they want to rebuild packages from scratch. * Format json * Add headless and use_rviz LaunchConfigurations to demo launch files (#3527) * Add headless and use_rviz LaunchConfigurations in nav2_simple_commander demo launch files for whether to start rviz or gzclient to simplify their use in headless environments * Fix headless logic to match tb3_simulation_launch.py for launch arg consistency * Fix State-Lattice planner crashes due to FP precision loss (#3531) * Fix State-Lattice planner crashes due to FP precision loss * Move testcase comment * Add PoseProgressChecker (#3530) * add rotation progress checker * clean include * add stopped goal checker reset test * add rotation progress checker tests * uncrustify * better name: PoseProgressChecker instead of RotationProgressChecker * camelCase * uncrustify * rename in tests * more rename * simplify parentheses * faster and better tests --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> * [velocity_smoother] Fix accel and deccel inverted for negative speeds (#3529) * fix inverted accel / deccel * handle speed through 0.0 * add applyConstraints tests * fold logic * same logic in findEtaConstraint * lint * Update nav2_velocity_smoother/src/velocity_smoother.cpp * Update nav2_velocity_smoother/src/velocity_smoother.cpp * findEtaConstraint tests * space * lint * typos * comment typos --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Enable Visualizations for Dev Container (#3523) * Add visualizer stage to install demo dependencies * Install foxglove * Install gzweb * Add hack for resolvable mesh URIs located by the aws SDL model files - https://github.com/aws-robotics/aws-robomaker-small-warehouse-world/pull/24 * Revert hack and use fork that fixes issues with deploy.sh - https://github.com/osrf/gzweb/pull/248 * Update target stage to visualizer * Comment out gzclient and rviz for debugging * Add hack for resolvable mesh URIs as migrating the python3 scripts still hasn't resolved the issue * Reorder stages for readability by keeping sequential builder and tester stages adjacent while keeping tester stage the default exported target * fix typo * Install gdb for launching ros launch files using the ROS VS Code extension - https://github.com/ms-iot/vscode-ros/issues/588 * Add vscode tasks file * Add Start Gzweb task * Add Start Foxglove tasks for bridge and studio * Add Start Foxglove compound task using dependsOn * Set default problemMatcher to empty to avoid nagging the user to select one as currently none really support our use case * Source overlay before running foxglove_bridge to ensure nav2 message types are defined by inlining all args into command and sourcing workspace setup * Formatting * Generalize and simplify hack * Generalize gazebo model discovery * Patch gzserver to run headless using xvfb to avoid host/platform specific x11 quirks exposed by vscode automatic x11 forwarding This is needed to provide gazebo a virtual frame buffer as it still need one after all these years. This also avoids the need modifying launch files to call xvfb-run - https://github.com/microsoft/vscode-remote-release/issues/8031 - https://github.com/gazebosim/gazebo-classic/issues/1602 * Set isBackground for start tasks * Add stop tasks * Add restart foxglove task * Switch to shell for commanding pkill to gracefully return 0 when process is not running allowing sequence of dependsOn tasks to run such as for the restart tasks * Add icons to tasks for readability * Add restart gzweb task * Add global start, stop, and restart tasks for all background visualization tasks * Formatting * Hide tasks users need not run manually to avoid cluttering up the run task quick pick * Shorten label for background tasks so they succinctly show from the running task list * Show global start and stop visualizations tasks as they may be too helpful to hide * Revert "Comment out gzclient and rviz for debugging" This reverts commit 0addae2a1ee70c5771055c5dd8fa050af438b896. * Add --ipc=host to runArgs to enable shared memory transport - https://community.rti.com/kb/communicate-between-two-docker-containers-using-rti-connext-dds-and-shared-memory * Add --pid=host to runArgs to simplify discovery - https://community.rti.com/kb/communicate-between-two-docker-containers-using-rti-connext-dds-and-shared-memory * Add to runArgs to simplify debugging - https://code.visualstudio.com/docs/devcontainers/create-dev-container#_use-docker-compose * Add comments * Comment out runArgs unintended side effects or cross talk between containers by default also avoids interfering with vscode's X11 forwarding * [nav2_planner] Fix costmap thread reset on cleanup (#3548) * remove costmap thread reset on cleanup * Init costmap thread in on_configure method * Move costmap_thread init in on_configure method * Add IsBatteryChargingCondition (#3553) * Add IsBatteryChargingCondition * Minor fixes in battery charging and add testing * Fix format * Added isBatteryChargingCondition BT node to params * Impl noise filtering layer in the costmap_2d (#2567) Signed-off-by: ryzhikovas <ryzhikovas@gmail.com> * Improve Dev Container Web App Visualization (#3551) * Add Caddyfile to reverse proxy websockets in an attempt to avoid authentication tokens in headers when forwarding ports from codespaces via web interface - https://docs.github.com/en/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace#using-command-line-tools-and-rest-clients-to-access-ports - https://caddyserver.com/docs/quick-starts/reverse-proxy - https://caddy.community/t/caddy-v2-how-to-proxy-websoket-v2ray-websocket-tls/7040/13 * Update caddy related tasks * Rename Gzweb task to Gzweb Bridge to make room for more gzweb tasks * Add Gzweb Client Task * Add Caddyfile to reverse proxy websockets now for Gzweb * Specify config file to avoid crosstalk between caddy stop commands * Fix reverse proxy for websockets by correcting matcher using headers as websocket request header value is lowercase for gzweb and foxglove * Comment out log output files for debugging * Simplify tasks by removing client tasks * Stop tasks by using terminate via the workbench.action.tasks.terminate command * Move Caddyfile * Add Web Server tasks * Move Caddyfile * Update log output file path * Update root path * Update reverse_proxy for both gzweb and foxglove by using the path argument for respective matchers - https://caddyserver.com/docs/caddyfile/matchers#path-matchers * Use snippets to keep Caddyfile DRY - https://caddyserver.com/docs/caddyfile/concepts#snippets * Use rewrite to catch trailing slash as file_server defaults do not correct reverse_proxy. This make typing the websocket URL more forgiving - https://caddyserver.com/docs/caddyfile/patterns#trailing-slashes * Improve websocket snippet to keep Caddyfile DRY * Use header_regexp for case-insensitive matching given web port forwarding from Codespaces is odd and rewrites the value of this header field to lowercases even when local browser request is sent as `Upgrade` * Add helper index page to web server to link to web apps for reverse proxy * Limit templates to fix gzweb by adding matcher for only root index otherwise gzweb's own index.html gets overwritten * Add comments to Cadyfile to document tricky configuration * Stage working redirect * Simplify index.html * Add helper redirect to simplify foxglove to set the respective queries values to automate websocket setup, and ensure the websocket schema matches the https request * Avoid hardcoding port number * Clean up comments * Use header to compute redirect to take into account requesting forwarding or more codespace port forwarding shenanigans * Use shorthand placeholders - https://caddyserver.com/docs/caddyfile/concepts#placeholders * Formatting * Keep trailing slash to stay consistent with caddy file_server directive that serves a 308 Permanent Redirect for both foxglove and gzweb paths anyway * Refactor matcher logic to account for requests either from host ports from local dev containers or forwarded requests from codespace web port forwarding * Split snippet into globals for composability * Update comments * Add Placeholders for debugging * Use tables to center * Use github markdown - https://github.com/sindresorhus/github-markdown-css * Simplify vars * Rename vars * Revert "Rename vars" as dotted var names do not work in Caddyfile This reverts commit 3e2d1b3fe30f8a4ffb5134fc2f6f5cffd574bcdc. * Add System Monitor to debug CPU load and memory issues * Update headings * Update layout * Update layout * Add Foxglove layout for Nav2 * Symlink assets folder for web server * Fetch Foxglove layout using layoutUrl a new parameter to load layout json data from URL - https://github.com/orgs/foxglove/discussions/217 * Cleanup * Use fork to fetch Foxglove layout using layoutUrl until this PR is merged: - https://github.com/foxglove/studio/pull/5987 * Update Caddyfile to handle relative root by using local srv folder * Inject mobile view html tags using the caddy replace module - https://caddyserver.com/docs/modules/http.handlers.replace_response - https://github.com/caddyserver/replace-response * Simplify Caddyfile * Use snippet for apps * Simplify Caddyfile * Simplify Caddyfile * Build caddy using custom modules * Remove unused symlinks * Add comments * Use environment and defined variables for config to avoid hard coded paths * Add FoxgloveUrl to vars for reuse in templates * Fix trailing slash for DataSourceUrl * Use exec to run gzserver with xvfb to prevent ros launch from orphaning process and ensure gzserver receives SIGTERM signal given gzserver often hangs after only SIGINT - https://unix.stackexchange.com/a/196053/213124 * Update redirect for foxglove to redirect from path /foxglove/autolayout * Add redirect for foxglove to redirect from path /foxglove/autoconnect but does not use LayoutUrl as to not change from cached layout * Use web app manifest to set display as standalone - https://web.dev/add-manifest/ - https://developer.mozilla.org/en-US/docs/Web/Manifest * Template manifest files to embed host info into app name * Add manifests for other web apps * Add shortcuts for Foxglove - https://developer.mozilla.org/en-US/docs/Web/Manifest/shortcuts - https://web.dev/app-shortcuts/ * Format * Update comments * Revert use of fork * Remove debug directive * Improve usability of PWAs in Dev Containers (#3576) * Add WIP icons * Add WIP icons for gzweb * Add WIP icons for glances * Set cross origin to use credentials ensuring auth cookie is included in request header when requesting for web app manifest file thus avoiding CORS policy violations in browser when accessing forwarded codespaces ports from the web > The request for the manifest is made without credentials (even if it's on the same domain), thus if the manifest requires credentials, you must include `crossorigin="use-credentials"` in the manifest tag. - https://web.dev/add-manifest/ - https://stackoverflow.com/a/57184506/2577586 * Use ReqHost variable in templates to account for X-Forwarded-Host value in header * Delete duplicate manifest * Set id property in app manifests so we can address them independently from their start_url - https://developer.chrome.com/blog/pwa-manifest-id/ * Ensure apps are uniquely identifies by adding trailing slash to id and thus different URI directories * Refactor root landing page into nav2 app by moving page file into nav2 sub folder adding root redirect pointing to /nav2/ and updating html, markdown, manifest files respectively * Fix https detection for Caddy reverse proxies by also checking X-Forwarded-Proto in request header * Remove unnecessary files * Prune smaller images * Prune duplicate icon * Clean up html tags * Update manifest icons * Rename icons * Revert "Prune duplicate icon" This reverts commit 571040173ca83716dfd2f6d5db4b351389a557a8. * Add back favicon for shortcut * Add self index for completeness and bookmarking * Simplify icon linking * Delete binary files * Fix hyperlink path * Include image files using gitattributes to track these binary files via git LFS * Add icons using git lfs * Standardized all icon paths * Use external links for icons to avoid the need for using git LFS although this is a bit of a hack * Stage any and maskable icons * Use any and masked icons * Set colors to match maskable icon colors * Update icon * Use lossless compression without removing background - https://shortpixel.com/online-image-compression * Use WebP instead of PNG for smaller file sizes - https://en.wikipedia.org/wiki/WebP * Move icons into icons folder * Use _SRV environment variables for service paths * Download media files from github during docker image build to avoid adding always online dependencies when creating or starting dev containers * Delete media icons from git repo now that we download media from anonymized URLs on github - https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/attaching-files * Add comments * Enable file browsing for non app paths for remote debugging of media and asset files * Consolidate assets into single folder * Add links for file browser paths to Server Diagnostics * Delete unused symlink * Update landing page to match manifest by including same shortcuts and start url * Patch gzweb to disable modelList avoiding 404s for thumbnails as they are hardcoded into js * Update comments * Simplify Caddyfile by reverting to symlinking but add ROOT_SRV env for custom overriding * Loop over nav2 srv folders when symlinking to generalize over folder names * Add matcher for file browsing root directory while still redirecting to nav2 app by default * Use placeholders for root variable to consolidate env default fallback settings e.g `:/srv` * Promote file browser in Nav2 app shortcuts * Fix and update SRV envs * Postpone symlinking for Nav2 web app to when post-create-command script then runs given full repo is not copied into builder stage in Dockerfile. While this could be postponed to update-content-command leaving it here avoids blowing user changes after the container has been created or modified. * Add guard to check if srv folder exists * Add refresh rate shortcuts to glances * Add file browser shortcut to nav2 * Set scope for nav2 PWA to root to allow for opening child apps inside nav2 app * Display child apps in fullscreen mode by default as users can still open them in standalone via nav2 app given the nav2 app's scope is the parent root path * Update shortcuts and landing page * Document PWA scope and installation order when using Nav2 PWA scoped as root * Revert setting scope for nav2 PWA to root path as adding file browser shortcut to nav2 PWA is not worth the trouble of having to explain installation order caveats and URL launch behavior. File browser shortcut is still accessible from inside nav2 pwa launcher but merely displays in browser preview given root / is out of scope for /nav2/ * Update server diagnostics for troubleshooting * Verify checksum of archive before extraction incase anonymized URL changes expected archive * Fix the condition in ackerman motion model constraints (#3581) * Fix the condition in ackerman motion model constraints * Fix ackerman motion model tests * Fix another ackerman motion model test * Fix broken symlink for gzweb (#3585) to load world models * Fix broken link to contributing guidelines (#3587) The original URL (https://navigation.ros.org/contribute/index.html) seems not to exist, returning an HTTP 404. Hence, I've replaced the link with a page that seems most relevant. * Adding Our Sponsors - May 2023 (#3593) * adding our sponsors - may 2023 * adding blurb * adding links * adding links * adding links * adding Open Nav * Add CostmapFilterInfoServer as a component (#3596) * Resolve #3532: reset i (#3597) * [MPPI] empty path_follow_critic proper fix (#3599) * [MPPI] empty path_follow_critic proper fix * fix linting issue --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * bumping humble to 1.1.7 for release --------- Signed-off-by: Trung Kien <letrungkien.k53.hut@gmail.com> Signed-off-by: Øystein Sture <os@skarvtech.com> Signed-off-by: ryzhikovas <ryzhikovas@gmail.com> Co-authored-by: Alexey Merzlyakov <60094858+AlexeyMerzlyakov@users.noreply.github.com> Co-authored-by: Jose Luis Blanco-Claraco <joseluisblancoc@gmail.com> Co-authored-by: DylanDeCoeyer-Quimesis <102609575+DylanDeCoeyer-Quimesis@users.noreply.github.com> Co-authored-by: Trung Kien <letrungkien.k53.hut@gmail.com> Co-authored-by: HovorunB <87417416+HovorunB@users.noreply.github.com> Co-authored-by: Tony Najjar <tony.najjar@logivations.com> Co-authored-by: Ruffin <roxfoxpox@gmail.com> Co-authored-by: Øystein Sture <oysstu@users.noreply.github.com> Co-authored-by: mrmara <48493979+mrmara@users.noreply.github.com> Co-authored-by: antoniomarangi <antonio.marangi@alba-robot.com> Co-authored-by: Tony Najjar <tony.najjar.1997@gmail.com> Co-authored-by: Griswald Brooks <griswald.brooks@gmail.com> Co-authored-by: BriceRenaudeau <48433002+BriceRenaudeau@users.noreply.github.com> Co-authored-by: Dirk Braunschweiger <1677757+dirkmb@users.noreply.github.com> Co-authored-by: Dirk Braunschweiger <dirk.braunschweiger@symovo.de> Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: Alberto Tudela <ajtudela@gmail.com> Co-authored-by: ryzhikovas <ryzhikovas@gmail.com> Co-authored-by: Alexandr Buyval <alexbuyval@gmail.com> Co-authored-by: Hyung-Taik Choi <htc.refactor@gmail.com> Co-authored-by: Filipe Cerveira <filipecerveira@gmail.com> * Fix merge conflict error (#3619) * fixing a second merge conflict resolution error (#3621) * fixing merge conflicts for release on humble sync 6 (#3623) * Fixing 3629 (#3630) * Fixing 3629 * Update planner_server.cpp * bumping humble to 1.1.8 for release sync 6 + bug patch * Fixing build warning (#3667) (#3673) (cherry picked from commit 7d4b1992811ccc9d36566d29251fdc8eaee66efc) Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Fix the velocity smoother being stuck when the deadband is too high (#3690) (#3715) * Move last_cmd update before deadband * fix lint (cherry picked from commit cb34d0ce1d24c1c437f548834a31a2ee8c4d9889) Co-authored-by: BriceRenaudeau <48433002+BriceRenaudeau@users.noreply.github.com> * Humble sync 7 August 4 1.1.9 (#3739) * Fix map not showing on rviz when navigation is launched with namespace (#3620) * updating mppi's path angle critic for optional bidirectionality (#3624) * updating mppi's path angle critic for optional bidirectionality * Update README.md * fixing path angle critic's non-directional bias (#3632) * fixing path angle critic's non-directional bias * adding reformat * adapting goal critic for speed to goal (#3641) * adapting goal critic for speed to goal * retuning goal critic * add readme entries * Update critics_tests.cpp * Fix uninitialized value (#3651) * In NAV2, this warning is treated as an error Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com> * Fix rviz panel node arguments (#3655) Signed-off-by: Nick Lamprianidis <info@nlamprian.me> * Reduce out-of-range log to DEBUG (#3656) * Adding nan twist rejection for velocity smoother and collision monitor (#3658) * adding nan twist rejection for velocity smoother and collision monitor * deref * MPPI: Support Exact Path Following For Feasible Plans (#3659) * alternative to path align critic for inversion control * fix default behavior (enforce_path_inversion: false) (#3643) Co-authored-by: Guillaume Doisy <guillaume@dexory.com> * adding dyaw option for path alignment to incentivize following the path's intent where necessary * add docs for use path orientations * fix typo --------- Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> * Fix smoother server tests (#3663) * Fix smoother server tests * Update test_smoother_server.cpp * nav2_bt_navigator: log current location on navigate_to_pose action initialization (#3720) It is very useful to know the current location considered by the bt_navigator for debug purposes. * nav2_behaviors: export all available plugins (#3716) It allows external packages to include those headers and create child classes through inheritance. * changing costmap layers private to protected (#3722) * adding error warnings around incorrect inflation layer setups in MPPI and Smac which impact performance substantially (#3728) * adding error warnings around incorrect inflation layer setups in MPPI and Smac which impact performance substantially * fix test failures * Update RewrittenYaml to support list rewrites (#3727) * allowing leaf key rewrites that aren't dcits (#3730) * adding checks on config and dynamic parameters for proper velocity and acceleration limits (#3731) * Fix Goal updater QoS (#3719) * Fix GoalUpdater QoS * Fixes * bumping Humble to 1.1.9 for release * fix merge conflict resolution in collision monitor node --------- Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com> Signed-off-by: Nick Lamprianidis <info@nlamprian.me> Co-authored-by: Filipe Cerveira <filipecerveira@gmail.com> Co-authored-by: Ryan <ryanfriedman5410+github@gmail.com> Co-authored-by: Nick Lamprianidis <info@nlamprian.me> Co-authored-by: BriceRenaudeau <48433002+BriceRenaudeau@users.noreply.github.com> Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: DylanDeCoeyer-Quimesis <102609575+DylanDeCoeyer-Quimesis@users.noreply.github.com> Co-authored-by: gyaanantia <78275262+gyaanantia@users.noreply.github.com> Co-authored-by: Tony Najjar <tony.najjar@logivations.com> * Fixing 3768: planner server lifecycle transition down (#3786) * Use ParameterFile (allow_substs) (#3706) (#3806) Signed-off-by: ymd-stella <world.applepie@gmail.com> Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com> * Added missing destructor to MPPI critic manager (#3812) * Added missing virtual destructor * Updated CriticManger Destructor to be same as other branches * mppi: return NO_INFORMATION when the checked point is outside the costmap (#3816) (#3818) otherwise the controller crashes at ObstaclesCritic::costAtPose because x_i and y_i isn't initialized. (cherry picked from commit 6b250a7c57536ee43a402c9820ac2a2acdb8bc13) Co-authored-by: Chuanhong Guo <gch981213@gmail.com> * [Humble] Sync 8 - Sept 25 (#3836) * Same orientation of coordinate frames in rviz ang gazebo (#3751) * rviz view straight in default xy orientation Signed-off-by: Christian Henkel <christian.henkel2@de.bosch.com> * gazebo orientation to match rviz Signed-off-by: Christian Henkel <christian.henkel2@de.bosch.com> * rotating in direction of view --------- Signed-off-by: Christian Henkel <christian.henkel2@de.bosch.com> * Fix flaky costmap filters tests: (#3754) 1. Set forward_prune_distance to 1.0 to robot not getting lost 2. Correct map name for costmap filter tests * Fix missing mutex in PlannerServer::isPathValid (#3756) Signed-off-by: ymd-stella <world.applepie@gmail.com> * Rewrite the scan topic costmap plugins for multi-robot(namespace) before launch navigation. (#3572) * Make it possible to launch namspaced robot which rewrites `<robot_namespace>` to namespace. - It allows to apply namespace automatically on specific target topic path in costmap plugins. Add new nav2 params file for multi-robot(rewriting `<robot_namespace>`) as an example. - nav2_multirobot_params_all.yaml Modify nav2_common.ReplaceString - add condition argument * Update nav2_bringup/launch/bringup_launch.py Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Add new luanch script for multi-robot bringup Rename luanch script for multi-robot simulation bringup Add new nav2_common script - Parse argument - Parse multirobot pose Update README.md * Update README.md Apply suggestions from code review Fix pep257 erors Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> --------- Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * use ros clock for wait (#3782) * use ROS clock for wait * fix backport issue --------- Co-authored-by: Guillaume Doisy <guillaume@dexory.com> * fixing external users of the BT action node template (#3792) * fixing external users of the BT action node template * Update nav2_behavior_tree/include/nav2_behavior_tree/bt_action_server_impl.hpp Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> --------- Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> * Using Simple Commander API for multi robot systems (#3803) * support multirobot namespaces * add docs * adding copy all params primitive for BT navigator (to ingest into rclcpp) (#3804) * adding copy all params primitive * fix linting * lint * I swear to god, this better be the last linting issue * allowing params to be declared from yaml * Update bt_navigator.cpp * some minor optimizations (#3821) * fix broken behaviortree doc link (#3822) Signed-off-by: Anton Kesy <antonkesy@gmail.com> * [MPPI] complete minor optimaization with floating point calculations (#3827) * floating point calculations * Update optimizer_unit_tests.cpp * Update critics_tests.cpp * Update critics_tests.cpp * 25% speed up of goal critic; 1% speed up from vy striding when not in use * bumping 1.1.9 to 1.1.10 for Humble release --------- Signed-off-by: Christian Henkel <christian.henkel2@de.bosch.com> Signed-off-by: ymd-stella <world.applepie@gmail.com> Signed-off-by: Anton Kesy <antonkesy@gmail.com> Co-authored-by: Christian Henkel <6976069+ct2034@users.noreply.github.com> Co-authored-by: Alexey Merzlyakov <60094858+AlexeyMerzlyakov@users.noreply.github.com> Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com> Co-authored-by: Hyunseok <yanghyunseok@me.com> Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: Anton Kesy <antonkesy@gmail.com> * Update CMakeLists.txt (#3843) (#3845) (cherry picked from commit 2d6e9a96354c0ea763e70eedd81225635f7b9db5) Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * bump to 1.1.11 for release for AVX512 fixes * add option for sse4 and avs512 (#3853) (#3855) (cherry picked from commit 7274811c5cb512a05b87523183e29e75ace77f4a) Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Bumping to 1.1.12 for binary release of AVX512 patches * [MPPI Optimization] adding regenerate noise param + adding docs (#3868) (#3870) * adding regenerate noise param + adding docs * fix tests * remove unnecessary normalization * Update optimizer.cpp (cherry picked from commit 924f167382080f3ccdd000ffc34b921cb64bcf95) # Conflicts: # nav2_mppi_controller/README.md Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Updating default map path * [MPPI] Reworked Path Align Critic; 70% faster + Tracks Paths Better! Edit: strike that, now 80% (#3872) (#3882) * adding regenerate noise param + adding docs * fix tests * remove unnecessary normalization * Update optimizer.cpp * adding refactored path alignment critic * fix visualization bug * speed up another 30% * remove a little jitter * a few more small optimizaitons * fixing unit tests * retain legacy critic * adding tests for legacy (cherry picked from commit 7009ffba5f85c50ac97fd0057924b0f1447c5e85) Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Fix incorrect auto merge conflict issue * Pluginizing BT Navigators (#3345) * initial prototype * linting * Create service get_current_navigator * Publish feedback through blackboard * Expections (#3244) * added result codes for global planner * code review * code review * cleanup * cleanup * update smac lattice planner * update planner instances * cleanup * updates * renaming * fixes * cpplint * uncrusitfy * code review * navfn exceptions * theta_star_planner * fix code review * wrote timeout exception * consistent exception throwing across planners * code review * remove * uncrusitfy * uncrusify * catch exception * expect throw * update string of exceptions * throw with coords * removed start == goal error code * code review * code review * uncrustify * code review * message order * remove remarks * update xml * update xml * Update nav2_behavior_tree/nav2_tree_nodes.xml * fix Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> Co-authored-by: Joshua Wallace <josho.wallace.com> * Controller exceptions (#3227) * added result codes for global planner * code review * code review * cleanup * cleanup * update smac lattice planner * update planner instances * cleanup * added controller exception * renaming * follow path updates * rename exceptions * updated regulated pure pursuit * completed pure pursuit * completed dwb * linting fixes * cleanup * revert planner server * revert planner server * revert planner server * revert planner server * code review * code review * cleanup * cleanup * bug fix * final cleanup * set follow path error on bt * update groot * code review Co-authored-by: Joshua Wallace <josho.wallace.com> * exceptions for compute path through poses (#3248) * exceptions for compute path through poses * lint fix * code review * code review Co-authored-by: Joshua Wallace <josho.wallace.com> * Pipe error codes (#3251) * issue with finding key * passed up codes to bt_navigator * lint fix * updates * adding error_code_id back in * error codes names in params * bump error codes * lint * spelling * test fix * update behavior trees * cleanup * Update bt_action_server_impl.hpp * code review * lint * code review * log fix * error code for waypoint follower * clean up * remove waypoint error test, too flaky on CI * lint and code review * rough imp for waypoint changes * lint * code review * build fix * clean up * revert * space * remove * try to make github happ * stop gap * loading in param file * working tests :) * lint * fixed cmake * lint * lint * trigger build * added invalid plugin error * added test for piping up error codes * clean up * test waypoint follower * only launch what is needed * waypoint test * revert lines for robot navigator * fix test * waypoint test * switched to uint16 * clean up * code review * todo to note * lint * remove comment * Update nav2_behavior_tree/include/nav2_behavior_tree/bt_action_server_impl.hpp Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * rename error_codes * error code for navigate to pose * error codes for navigate through poses. * error codes for navigate through poses * message update for waypoint follower * rename to error code * update node xml Co-authored-by: Joshua Wallace <josho.wallace.com> Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> * Smoother error codes (#3296) * minimum error code set * test for invalid smoother * undo * added rest of error tests * Solve bug when CostmapInfoServer is reactivated (#3292) * Solve bug when CostmapInfoServer is reactivated * Smoothness metrics update (#3294) * Update metrics for path smoothness * Support Savitzky-Golay smoother * preempt/cancel test for time behavior, spin pluguin (#3301) * include preempt/cancel test for time behavior, spin pluguin * linting * fix bug in code * removed changes to simple_smoother * reverted simple_smoother * revert * revert * updated constrained smoother * revert * added smoother error for invalid path * linting * invalid path test * added error codes * Timeout exception thrown by smoothers * code review Co-authored-by: Joshua Wallace <josho.wallace.com> Co-authored-by: MartiBolet <43337758+MartiBolet@users.noreply.github.com> Co-authored-by: Alexey Merzlyakov <60094858+AlexeyMerzlyakov@users.noreply.github.com> Co-authored-by: Stevedan Ogochukwu Omodolor <61468301+stevedanomodolor@users.noreply.github.com> * Behavior Tree uses Error Codes (#3324) * rough outline for condition node * completed error code condition * behavior tree with error codes * created generic code ex * test for error_code_condition * generic error code bt node * remove error code condition * updates * updated error code condition * would a controller recovery help * rename * added planner recovery condition * initial draft * complete with one error code as input * revert cmake * bt conversion test * code review * code review * code review * refactor behavior tree tests * cleanup * final cleanup * uncomment * removed logger * function header update * update bt to include would a planner recovery help * copyright cleanup * added bt node for smoother recovery * smoother test * costmap filter test fix * remove include * test if commit counted * update copyright * code review Co-authored-by: Joshua Wallace <josho.wallace.com> * Behavior server error codes (#3539) * empty error codes * add error codes for behaviors * updated assisted teleop * pass tests * added error codes to bt nodes * Enable Visualizations for Dev Container (#3523) * Add visualizer stage to install demo dependencies * Install foxglove * Install gzweb * Add hack for resolvable mesh URIs located by the aws SDL model files - https://github.com/aws-robotics/aws-robomaker-small-warehouse-world/pull/24 * Revert hack and use fork that fixes issues with deploy.sh - https://github.com/osrf/gzweb/pull/248 * Update target stage to visualizer * Comment out gzclient and rviz for debugging * Add hack for resolvable mesh URIs as migrating the python3 scripts still hasn't resolved the issue * Reorder stages for readability by keeping sequential builder and tester stages adjacent while keeping tester stage the default exported target * fix typo * Install gdb for launching ros launch files using the ROS VS Code extension - https://github.com/ms-iot/vscode-ros/issues/588 * Add vscode tasks file * Add Start Gzweb task * Add Start Foxglove tasks for bridge and studio * Add Start Foxglove compound task using dependsOn * Set default problemMatcher to empty to avoid nagging the user to select one as currently none really support our use case * Source overlay before running foxglove_bridge to ensure nav2 message types are defined by inlining all args into command and sourcing workspace setup * Formatting * Generalize and simplify hack * Generalize gazebo model discovery * Patch gzserver to run headless using xvfb to avoid host/platform specific x11 quirks exposed by vscode automatic x11 forwarding This is needed to provide gazebo a virtual frame buffer as it still need one after all these years. This also avoids the need modifying launch files to call xvfb-run - https://github.com/microsoft/vscode-remote-release/issues/8031 - https://github.com/gazebosim/gazebo-classic/issues/1602 * Set isBackground for start tasks * Add stop tasks * Add restart foxglove task * Switch to shell for commanding pkill to gracefully return 0 when process is not running allowing sequence of dependsOn tasks to run such as for the restart tasks * Add icons to tasks for readability * Add restart gzweb task * Add global start, stop, and restart tasks for all background visualization tasks * Formatting * Hide tasks users need not run manually to avoid cluttering up the run task quick pick * Shorten label for background tasks so they succinctly show from the running task list * Show global start and stop visualizations tasks as they may be too helpful to hide * Revert "Comment out gzclient and rviz for debugging" This reverts commit 0addae2a1ee70c5771055c5dd8fa050af438b896. * Add --ipc=host to runArgs to enable shared memory transport - https://community.rti.com/kb/communicate-between-two-docker-containers-using-rti-connext-dds-and-shared-memory * Add --pid=host to runArgs to simplify discovery - https://community.rti.com/kb/communicate-between-two-docker-containers-using-rti-connext-dds-and-shared-memory * Add to runArgs to simplify debugging - https://code.visualstudio.com/docs/devcontainers/create-dev-container#_use-docker-compose * Add comments * Comment out runArgs unintended side effects or cross talk between containers by default also avoids interfering with vscode's X11 forwarding * ignore warning (#3543) * Split overlay setup into multiple steps by skipping slower to build leaf packages during preparation, then store cache and repeat setup without skipping packages * Skip restore steps after already preping overlay to avoid needlessly downloading the same overlay cache * Revert resource_class to default medium as the build resource usage seldom maxes out 4 cores nor uses more than 2GB RAM * Fix circleci config syntax by setting skip default as empty string to keep it an optional parameter * Fix circleci config syntax missing angle brackets * ignore warning * Revert "Revert resource_class to default medium" This reverts commit 44375a1c6ef6e730e47e30c7d910a15145d4ee2f. * Fix nested defaults to avoid dropping of cache after storing during test jobs by ensuring restore_overlay_workspace still sets restore: true --------- Co-authored-by: ruffsl <roxfoxpox@gmail.com> * code review * code review * removed unsigned short * lint errer * error codes in main bts * behavior error code range change --------- Co-authored-by: Ruffin <roxfoxpox@gmail.com> * correct error message (#3631) (#5) * correct error message * clean up * cleanup * remove header Co-authored-by: Joshua Wallace <josho.wallace@gmail.com> * Option for ObstacleLayer to not override StaticLayer's unknown parts (#3612) (#6) * Add updateWithMaxWithoutUnknownOverride * Add missing break to switch case * Add additional NO_INFORMATION check to make more robust * Add CombinationMethod enum with combination_method_from_int * Rename override to overwrite * Update docs of combination_method_from_int * Move definitions to costmap_layer and remove function_name param * Replace logger with node's logger * Fix linting errors * Add test * Add CombinationMethod::Max test as a counter-case * Let Navigators have different error codes (#3642) (#7) * Change ERROR to DEBUG * INFO message on init * format code * Replace newlines with spaces * Return feedback from bt action node * Fix feedback type error * Increase wait for action server timeout * Add param to calculate remaining time * Add orientation difference to distance remaining * Fix distance remaining crash * Add doors to distance remaining * Revert "Add doors to distance remaining" This reverts commit e0334ea57a66824d06e1089a400e43f4e87c1867. --------- Signed-off-by: Trung Kien <letrungkien.k53.hut@gmail.com> Signed-off-by: Øystein Sture <os@skarvtech.com> Signed-off-by: ryzhikovas <ryzhikovas@gmail.com> Signed-off-by: Ryan Friedman <ryanfriedman5410+github@gmail.com> Signed-off-by: Nick Lamprianidis <info@nlamprian.me> Signed-off-by: ymd-stella <world.applepie@gmail.com> Signed-off-by: Christian Henkel <christian.henkel2@de.bosch.com> Signed-off-by: Anton Kesy <antonkesy@gmail.com> Co-authored-by: Steve Macenski <stevenmacenski@gmail.com> Co-authored-by: Tony Najjar <tony.najjar@logivations.com> Co-authored-by: HAIDAR OBEID <31267966+ObeidHaidar@users.noreply.github.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Guillaume Doisy <doisyg@users.noreply.github.com> Co-authored-by: Tony Najjar <tony.najjar.1997@gmail.com> Co-authored-by: nakai-omer <108797279+nakai-omer@users.noreply.github.com> Co-authored-by: Alexey Merzlyakov <60094858+AlexeyMerzlyakov@users.noreply.github.com> Co-authored-by: Jose Luis Blanco-Claraco <joseluisblancoc@gmail.com> Co-authored-by: DylanDeCoeyer-Quimesis <102609575+DylanDeCoeyer-Quimesis@users.noreply.github.com> Co-authored-by: Trung Kien <letrungkien.k53.hut@gmail.com> Co-authored-by: HovorunB <87417416+HovorunB@users.noreply.github.com> Co-authored-by: Ruffin <roxfoxpox@gmail.com> Co-authored-by: Øystein Sture <oysstu@users.noreply.github.com> Co-authored-by: mrmara <48493979+mrmara@users.noreply.github.com> Co-authored-by: antoniomarangi <antonio.marangi@alba-robot.com> Co-authored-by: Griswald Brooks <griswald.brooks@gmail.com> Co-authored-by: BriceRenaudeau <48433002+BriceRenaudeau@users.noreply.github.com> Co-authored-by: Dirk Braunschweiger <1677757+dirkmb@users.noreply.github.com> Co-authored-by: Dirk Braunschweiger <dirk.braunschweiger@symovo.de> Co-authored-by: Guillaume Doisy <guillaume@dexory.com> Co-authored-by: Alberto Tudela <ajtudela@gmail.com> Co-authored-by: ryzhikovas <ryzhikovas@gmail.com> Co-authored-by: Alexandr Buyval <alexbuyval@gmail.com> Co-authored-by: Hyung-Taik Choi <htc.refactor@gmail.com> Co-authored-by: Filipe Cerveira <filipecerveira@gmail.com> Co-authored-by: Ryan <ryanfriedman5410+github@gmail.com> Co-authored-by: Nick Lamprianidis <info@nlamprian.me> Co-authored-by: gyaanantia <78275262+gyaanantia@users.noreply.github.com> Co-authored-by: ymd-stella <7959916+ymd-stella@users.noreply.github.com> Co-authored-by: Vineet <52542471+VineetTambe@users.noreply.github.com> Co-authored-by: Chuanhong Guo <gch981213@gmail.com> Co-authored-by: Christian Henkel <6976069+ct2034@users.noreply.github.com> Co-authored-by: Hyunseok <yanghyunseok@me.com> Co-authored-by: Anton Kesy <antonkesy@gmail.com> Co-authored-by: redvinaa <redvinaa@gmail.com> Co-authored-by: Joshua Wallace <josho.wallace@gmail.com> Co-authored-by: MartiBolet <43337758+MartiBolet@users.noreply.github.com> Co-authored-by: Stevedan Ogochukwu Omodolor <61468301+stevedanomodolor@users.noreply.github.com> Co-authored-by: turtlewizard73 <mate.laszlo703@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding a requirements document and starting to add some directory structure (placeholders).