ROS2 Navigation WG - Thursday 3:00 pm Pacific (GMT-7:00)

That link redirects to, and results in DNS_PROBE_FINISHED_NXDOMAIN.

OK, well I tried the Google Docs “Publish to web” which I guess didn’t work. Sorry. I had thought that would work. I won’t try that again… :roll_eyes:

Here they are.

3/7/19 - ROS2 Navigation WG Notes

Nav2 usage examples / tutorials needed

  • Bringup on your robot
    • Similar to ROS1 Navigation tutorials
    • Also see Nav section of the book Quigley, Gerkey, et al
    • Create page link from main README
  • Steve - PDF Navigation tuning guide
  • Look to use GH Pages
  • Carl will look at what OSRF is using for main ROS2 tutorials

Nav2 Dashing Roadmap -

  • Need to update each line with relevant issues & PRs

  • Add “Help Wanted” where needed

Real-time support

  • ROS2 deadlines, liveliness

  • Meeting held yesterday, decision made to focus on Topics first, then Services and Actions later

    • Look for issue above to be updated
  • Mike Jeronimo also working on some proposed enhancements to ROS2 rates and timers for monitoring if they’re meeting deadlines

Linux Foundation RT kernel - full RT support will be available this Summer

  • PREEMPT_RT will be “built in” and can be turned on / tuned on system without rebuilding

Safety certified Linux - Eliza project?

  • Geoff will look for a link to send out

They have significant industry backing and apparently a very large budget to work with.

1 Like

Due to resource limitations, we’re not directly involved in the nav. stack @mkhansen however we’re very interested on getting some alignment here, specially with regard our ongoing work on MoveIt! 2.

+1 to the ELISA project, we recently joined the initiative and seems to be rather well oriented.


Ive been talking with @davetcoleman semi-regularly regarding our Nav2 work, and he attended the WG yesterday. I’m glad to hear about the MoveIt! 2 project happening too. Let me know what alignment you’re looking for, and I’m happy to collaborate.

Update, due to Daylight Saving time in the US, we’re pushing back the WG to 3pm to allow for participants in the Asian continent.

We’re meeting today 3/21 at 3pm Pacific.

No meeting this week (3/28/19) - I’m on family vacation

Here are the notes from last weeks meeting. Navigation 2 WG 3/21/19

Jacob Perron
Steve M
Devin Bonnie
Emerson Knapp


LifecycleHelper Class - Issue #654 (Mike Jeronimo)

  • Will this work for Actions?

  • Jacob will follow up with Karsten & comment in issue

Nav2 RViz plugins

  • LIfecycle control (Startup and shutdown)
  • Loop time monitoring

Lifecycle implementation PR #1 -

  • Up for review, requesting feedback

Random Crawl - (Mohammad H)

  • Robot will move randomly without hitting obstacles
  • Can be used to test AMCL, by checking location vs. Gazebo
  • Can also be used to “explore” a map for SLAM
  • Could be used for auto-localization
  • Only relies on Keras and Tensorflow, not using OpenAI
  • Not released yet, WIP

Pose Persistence - (Carl)

  • In ROS, AMCL saved pose to parameter server
  • In ROS2, no parameter server, how can we save?
    • Is this a more general issue?
      • Pose, trajectory, map?

PR change for QOS settings -

Opens - None

All - calling for topics for Nav2 WG meeting tomorrow 4/25

Meeting notes:
Navigation 2 WG 4/25/19

Mike J
Steve M
Geoff B
Chris B

Lifecycle staging - see multiple PRs in review right now

Parameters change upstream broke master branch, need to fix build and test

Parameters discussion

  • can we add metadata to enumerate the lifecycle state a parameter can be changed in.
  • Need to review this PR and provide feedback:
  • Authentication for parameters - would need to talk to security WG about this

Actions API change is coming -

Architecture diagram - Mike J. to present next week

FYI, changes to the action client API are merged to master now. You can find a new example here.

In case it affects the navigation team, yet another small change to the action API adding a response code to the cancel service response:

All, here is the diagram that @mjeronimo presented last week which shows the high-level overview of the architecture with lifecycle nodes and the lifecycle manager.

I’m cancelling this week’s meeting due to travel.

I’d also like to do a ‘call for topics’ for upcoming meetings. If there are items you want to discuss, please post them here. Also, as usual, if you want to be added to the meeting invite, message me through the discourse messaging app and include the email address you want added to the invite.


Thanks for providing that diagram, and sorry I couldn’t be there for the explanation. It was 10 days of enforced holidays. I did intend to participate but ended up sleeping through my alarm.

Looking at the diagram, unfortunately there are aspects that I can’t understand without that explanation. Was a recording of the meeting made?

Sorry, no I didn’t think to record the meeting. Would you mind opening an issue in the repo to make sure we address your questions in the documentation? We can also discuss this week in the meeting.

No meeting today (5/23/19), we’re swamped trying to hit the Dashing release deadline next week. I’ll send a cancellation to those on the Google Calendar invite.

This is a call for topics for this week’s Nav2 WG - please reply below if you have topics you want to discuss!

Here are the notes from today’s meeting (6 Jun 2019)

Matt (@mkhansen )
Mike (@mjeronimo)
Carl (@cdelsey)
Geoffrey (@gbiggs)
Jacob (@jacob)


  • Mike presented the idea of using a behavior tree based lifecycle manager.
    • Current implementation is not configurable.
    • We could, instead, use a behavior tree to control the startup and shutdown behavior.
    • Lifecycle manager could execute a startup tree, a runtime tree, and a shutdown tree, etc, based on the operation requested of lifecycle manager.
    • Mike showed a brief demo of an implementation.
    • Question from Geoffrey - Could this be integrated into the ROS 2 launch mechanism.
      • Response - Launch seems to be more startup focused. It doesn’t allow swapping the startup and shutdown sequencing.
      • Launch and Lifecycle Manager seem to be two sides of the overall “Deployment Manager” concept.
      • Error handling and monitoring are part of the problem as well.
      • (Open)Shift is a conceptionaly similar concept, although it is a bit too simplistic for our use cases. It is limited to binary concepts.
      • We should bring up the idea to TSC and William Woodall, to see about integrating this concept into launch.
      • Mike to document this in an issue and add slides.
  • Safety WG
    • Safety WG had second kickoff meeting
      • Discussed architectures for using ROS in safety critical ways.
      • Planning to provide sample safety cases in the same way as the security WG has done.
        • Lawn tractor is a potential scenario to build a safety case for
          • Would like to have a navigation subsystem safety case.
    • Next WG is targeted for end Jun or beginning of Jul
    • ROS Agriculture or warehouse based scenarios are of interest to WG participants
  • Status from Scott
    • Haven’t had a chance to work with latest navigation stack yet.
    • Planning to look into this soon, in order to find underlying stack issues
      • Matt would like to see any list of underlying issues to provide feedback.
      • Scott is mostly working with OpenSplice right now.
      • Matt requested that Scott present any known issues or plans at next week’s WG meeting.
1 Like

Any topics for today’s WG?

Here are the notes from today’s (20 Jun 2019) meeting.

- Geoffrey (@gbiggs)
- Scott
- Dan
- Matt (@mkhansen)
- Mohammad
- Mike (@mjeronimo)
- Yathartha
- Melih
- Brian
- Carlos
- Carl (@cdelsey)

- Dashing status update
- Autoware

- It would be nice to get an overview of what the autoware team is working towards.

- It was suggested getting the Navigation 2 system test integrated into the OSRF build farm and it was agreed to. Navigation2 team will work with OSRF to make that happen.
- Scott developed some tools to help layer builds on top of builds that may help with this
- Build farm uses AWS to support testing. There is capacity to add tests.
- Will file an issue on to track it. AR Matt

Dashing Status:
- Major outstanding issues
○ Catching exceptions and printing out useful info during state transitions
○ Collision checking in motion primitives
○ Documentation
- OSRF will do a dashing sync when we do a release so people can take advantage of the nav stack.
- Navigation 2 dashing release is targeted for this month (Jun)

- Apex has made an improved Lifecycle node mechanism with better error handling.
- Navigation 2 team is interested in taking advantage of Lifecycle improvements and would like to be involved in design discussions on this.

Waiting for intial pose
- In some cases, there is a need for user input before a transition can happen. For instance, world model can’t fully come up till the intial pose is set
- Discussion on the correct behavior when the robot comes up without knowledge of its current location. No resolution.
- Could make it configurable by using a param

- Work on porting diagnostics support is starting to get underway. It would be nice if the nav stack could make use of this mechanism

- ROS based self-driving software - started by TF4 and currently maintained by Autoware foundation
- Moving to gitlab.
- Two projects:
○ - existing vision - level 4 autonomy
○ - next generation. Restarting from scratch.
- Most work being done by Apex.
- Complete lidar stack - velodyne lidar to clustering and so on. Completely deterministic and real-time.
- Spinning up a bunch in July - architecting
- Has a defined a set of milestones.
- Would like to take advantage of navigation stack other existing ROS software.
- LGSVL - has advantages for camera simulation and looks pretty. LG is part of the Autoware foundation. Autoware is intended to work with multiple simulators

1 Like

Notes from yesterday’s WG meeting

- Dan R.
- Steve M.
- Carlos O.
- Mike J.
- Mohammad H.
- Yathartha T.
- Brian W.
- Melih E.
- Carl D.

- BT Navigator discussion (Steve)
- Planner API
- Parameter Dumper
- Parameter usage guidelines
- Parameter server design
- What’s going on with Geometry (Dan)

TF Related errors with latest code
- Lot’s of transform errors. Seems to be something has changed in ros2/geometry
- Nav test are failing much more frequently

Behavior Tree Related Code Cleanup
- Behavior tree naming - use of action is confusing. It is overloaded between BT Action and ROS Action. Need better naming here.
- Delete the navigate to pose behavior tree action function/class
- Create a clear costmap recovery service as a recovery
- We could create a separate BT package that is generic.
- BTActions should be pluggable. That capability is now in BT library V3. We need to port to V3.
- Keep new capabilities in this repo until we need to move elsewhere.
- Recovery object in BT tree. This node is not a base class for recovery. Instead it is a BT control flow that allows adding recovery behaviors into the tree.
- Too many include files in BT tree directory. Need to define base classes for common functionality like recoveries. Need to group things to help improve understandability for people new to the project (and the rest of us too)
- Synchronous and asynchronous operations - need background tasks. Recovery behaviors could be background tasks. There is a BTAsyncNode capability, but can we fit this into the nav tree easily.

Current get pose function is tied to AMCL.
- Poses to come from TF. Need a way to respond in the behavior tree if the robot becomes delocalized.
- We have a BT node that monitors covariance for autolocalization
- We can provide example usage for AMCL. Other localizers may need something else

Local Planner API
- Local Planner API to be define

Parameter Dumping Tool
- PR 902 - Parameter dumping utility
- Utility for getting all params in nav stack with their metadata. Saves to YAML or markdown.
- This should update the docs with this data
- Could be added to ros2 command line.

What should be a parameter and what should be hard coded
- What do we need to make a parameter?
- Target user is an engineer at a robotics company. They want to not compile every time they need to tweak a value.
- TF tolerance, over the wire timeouts, and fast rate variables are good candidates for ros params
- Two sets of parameters - the set of most commonly modified parameters and the full set of everything.
- Timeouts could be specified in the launch file.
- Timeouts could be specified in terms of multiple of round-trip time. DDS implementations tend to keep this statistic.

1 Like