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)
Attendees
Matt (@mkhansen )
Mike (@mjeronimo)
Carl (@cdelsey)
Geoffrey (@gbiggs)
Jacob (@jacob)
Scott
Carlos
Brian
Topics
- 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.
- Lawn tractor is a potential scenario to build a safety case for
- Next WG is targeted for end Jun or beginning of Jul
- ROS Agriculture or warehouse based scenarios are of interest to WG participants
- Safety WG had second kickoff meeting
- 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.
Attendees:
- Geoffrey (@gbiggs)
- Scott
- Dan
- Matt (@mkhansen)
- Mohammad
- Mike (@mjeronimo)
- Yathartha
- Melih
- Brian
- Carlos
- Carl (@cdelsey)
Agenda:
- Dashing status update
- Autoware
- ROS 2 TSC
Autoware:
- It would be nice to get an overview of what the autoware team is working towards.
TSC:
- 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 build.ros2.org 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)
Lifecycle
- 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
Diagnostics
- Work on porting diagnostics support is starting to get underway. It would be nice if the nav stack could make use of this mechanism
Autoware:
- ROS based self-driving software - started by TF4 and currently maintained by Autoware foundation
- Moving to gitlab.
- Two projects:
○ Autoware.ai - existing vision - level 4 autonomy
○ Autoware.auto - 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
Attendees
- Dan R.
- Steve M.
- Carlos O.
- Mike J.
- Mohammad H.
- Yathartha T.
- Brian W.
- Melih E.
- Carl D.
Agenda:
- BT Navigator discussion (Steve)
- Planner API
- Parameter Dumper
- Parameter usage guidelines
- Parameter server design
- What’s going on with Geometry (Dan)
Notes:
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
Nav2 WG 7/25/19
-
Matt
-
Carl
-
Mohammad
-
Dan R
-
Melih
-
Brian
-
Yathartha
-
Carlos
Topics
Documentation
- GH pages
- Requires some learning curve
- Would conform with ROS2 documentation
- Would allow PRs to update documentation
- Help wanted - getting our GH pages set up
Map_saver (Dan)
- Working on PR to update / rewrite map_saver
- Will add SCALE and RAW mode support
- Changing libraries to Graphics Magic (similar to Image Magic), available in Ubuntu 18.04
Rover update
- Working on master branch
- Using OpenSplice by default
- Submitted rosidl_typesupport_opensplice repo, PR #34
Master branch issues
- Seeing exceptions when running in CI “promise already satisfied”
- Carl will try with OpenSplice