ros2 / ros2

The Robot Operating System, is a meta operating system for robots.

About

The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it's all open source. Full project details on ROS.org

Getting Started

Looking to get started with ROS? Our installation guide is here. Once you've installed ROS start by learning some basic concepts and take a look at our beginner tutorials.

Join the ROS Community

Community Resources

• ROS Discussion Forum
• ROS Discord Server
• Robotics Stack Exchange (preferred ROS support forum).
• Official ROS Videos
• ROSCon, our yearly developer conference.
• Cite ROS 2 in academic work using DOI: 10.1126/scirobotics.abm6074

Developer Resources

• ROS 2 Documentation
• ROS Package API reference
• ROS Package Index
• ROS on Docker Hub
• ROS Resource Status Page
• REP-2000: ROS 2 Releases and Target Platforms

Project Resources

• Purchase ROS Swag
• Information about the ROS Trademark
• On Social Media
  • Open Robotics on LinkedIn
  • Open Robotics on Twitter
  • ROS.org on Twitter

ROS is made possible through the generous support of open source contributors and the non-profit Open Source Robotics Foundation (OSRF). Tax deductible donations to the OSRF can be made here.

ros2's Issues

Disable poorly configured linters

Until we get them properly configured (#12, #13, #14) we should disable them.

AC:

• clang_format linters
• cpplint
• uncrustify

Compare OSX unit test results with Linux

Depends on #21

AC:

• either equal test counts or
• known differences
• cppcheck missing
• uncrustify missing (http://54.183.26.131:8080/view/ros2/job/ros2_batch_ci_osx/ws/workspace/build/rcl/Testing/Temporary/LastTest.log/*view*/)
• PEP8 test failing but not on Linux (due to newer version of PEP8): ament/ament_lint@9a51c71
• nosetests error about indentation in osrf_pycommon, not failing on Linux, may be specific to the flake version being used?

[demo] Visualization of Data with ROS 1 tools

Clean up cmake output

Currently there are tonnes of debug messages being output to the console, which is good while developing, but it's also starting to make it more difficult to find important information. We should go through the ament cmake code and find as many places as possible to replace message() with some macro that we can enable and disable with a CMake argument, maybe something like AMENT_VERBOSE or something like that.

Setup batch CI for Linux

Acceptance Criteria:

• Create a batch script type CI testing to be batch run
• report test result in jenkins job (# passed/failed)

Configure and Enable the cpplint QA tool

We have a tools for checking our code with cpplint but it is not configured to our liking yet.

Acceptance Criteria:

• Decide on a configuration with the team
• Address code style changes
• Reenable the linter ament/ament_lint#36

Automatically build batch job on pull request

AC:

• upgrade batch job to detect PR branch and then check out other repos with the same branch name it it exists else fallback to default branch.

Define the developer parameter API

• Determine developer API
  • What methods are made available
  • callback model

---

eliminate warnings

Things left todo:

• Fix the remaining warnings (currently 3) on OS X: http://54.183.26.131:8080/job/ros2_batch_ci_osx/156/warnings7Result/
• Audit and fix warnings for Windows (currently 1380 warnings)
• Use a narrower warning suppression with rmw_opensplice and rmw_connext: ros2/rmw_connext#40 (comment)

revisit type support identifiers

After the refactoring to support C as well as Windows the type support identifiers are not working as they were before.

E.g. for Connext XTypes a string comparison is necesssary (ros2/rmw_connext#2). For other type supports the check is not being performed anymore.

Cleanup labels

While trying a few tools some unnecessary labels got created.

AC:

• Remove any non-default, non-waffle.io related labels from ros2 and ament repository issue trackers.

generate interface headers in subnamespace

With the current approach (which is the same in ROS 1 C++) the header files of messages, services, derived service messages (request and response) all share the same namespace with the package code.

• Placing the generated code of messages / services in a subfolder / subnamespace avoids collisions with other code in the package.
• Separating the headers for messages and services in separate subfolders / namespaces (e.g. msg and srv) avoids collisions between them. It allows to have an Empty.msg as well as an Empty.srv. This is closer to the ROS 1 Python naming scheme.
• The derived service messages types (request and response) should stay together with the services (and e.g. not go into the msg subfolder).
• To prevent collisions between service names and their derived service messages the request and response files must be constructed in either of the following two ways:
  • They are defined in a subnamespace named after the service (since it creates two additional namespaces per service I would suggest the next option).
  • They are being names with a suffix starting with _ (e.g. Foo_Request.h) which is not a valid message / service name.

Pros:

• No naming collisions between package code and generated code for messages / services, the subnamespaces msg and srv are reserved.
• No collisions between message and service names.
• No collision between service names and their derived request / response types.
• The change locations keep user code and generated message / service code nicely separated.

Cons:

• User land code has to include messages / services from a subfolder and use them with a subnamespace:

#include <my_interfaces/msg/Foo.hpp
my_interfaces::msg::Foo foo;

---

Theire are two more aspects I would like to address in the process of this refactoring:

• Currently the generated header files are using camel case for the filename. Should we change that to use lowercase + underscore instead? For the _Request suffix that would imply e.g. using a double underscore as a separator (to keep avoiding collisions).
• The generated C++ header are currently ending in .h. I would propose to change them to .hpp to be consistent with our guidelines.

@esteve @tfoote @wjwwood Please provide feedback before I start working on the necessary PRs.

• Update generated C code to drop -c suffix and apply the same naming rules as for C++ and only differentiate based on the extension.

Parameter Review Roundup

• name symmetry: parameter_name or just type: https://github.com/ros2/rcl_interfaces/blob/master/rcl_interfaces/msg/ParameterDescriptor.msg
• Response callback optionally also gets original request. ros2/rclcpp#35
• Restructure Messages based on discussion:

GetParameters.srv

# A list of parameter names to get.
# TODO(wjwwood): Decide on the rules for grouping, nodes, and parameter "names" in general, then link to that.
string[] names

---

# List of values which is the same length and order as the provided names.
# If a parameter was not set yet, the value will have PARAMETER_NOT_SET as the parameter_type.
ParameterValue[] values

ParameterType.msg

uint8 PARAMETER_NOT_SET=0
uint8 BOOL_PARAMETER=1
uint8 INTEGER_PARAMETER=2
uint8 DOUBLE_PARAMETER=3
uint8 STRING_PARAMETER=4
uint8 BYTES_PARAMETER=5

ParameterValue.msg

# Used to determine which of the next *_value fields are set.
# ParameterType.PARAMETER_NOT_SET indicates that the parameter was not set
# (if gotten) or is uninitialized.
uint8 parameter_type  # wjwwood: was there a reason to not use just type here?

# "Variant" style storage of the parameter value.
bool bool_value
int64 integer_value
float64 double_value
string string_value
int8[] bytes_value

GetParameterTypes.srv

# A list of parameter names.
# TODO(wjwwood): link to parameter naming rules.
string[] parameter_names

---

# List of types which is the same length and order as the provided names.
# ParameterType.PARAMETER_NOT_SET indicates that the parameter is not currently set.
uint8[] parameter_types

SetParameterResult.msg

# A true value of the same index indicates that the parameter was set successfully.
# A false value indicates the change was rejected.
bool successful
# Reason why the setting was either successful or a failure.
# Should only be used for logging and user interfaces.
string reason

SetParameters.srv

# A list of parameters to set.
Parameter[] parameters

---

# An order list of results of the same size as the given parameters.
SetParameterResult[] results

SetParametersAtomically.srv

# A list of parameters to set.
Parameter[] parameters

---

SetParameterResult result

Parameter.msg

string name
ParameterValue value

ListParameters.srv

uint64 DEPTH_RECURSIVE=0

# The list of parameter prefixes to query.
string[] parameter_prefixes
# Relative depth from given prefixes to return.
# Use DEPTH_RECURSIVE to get the recursive parameters and prefixes for each prefix.
uint64 depth

---

# All parameters under the given prefixes.
string[] parameter_names
# All prefixes under the given prefixes.
# TODO(wjwwood): link to prefix definition and rules.
string[] parameter_prefixes

DescribeParameters.srv

# A list of parameters of which to get the description.
string[] parameter_names

---

# An ordered list of parameter descriptions of the same size as the list requested.
# If the parameter_type is set to PARAMETER_NOT_SET, then the parameter requested was not set.
ParameterDescription[] parameter_descriptions

ParameterDescription.msg

string parameter_name
uint8 parameter_type  # wjwwood: same note, seems like just type would be better.
# TODO: add additional meta data.

• [impl] ParameterContainer should use the generated ParameterValue.msg as storage
• [api] ParameterContainer should be renamed to avoid confusion that it only holds one value and to show that it is related to the ParameterValue.msg
• [api] the parameter API should take a node not be part of the node class.
• [api] refactor examples and design information based on our discussion:

auto node = ...;
auto pc = ParameterClient(node, node_name="");
auto pc = ParameterClient(node, remote_node_name="other");
auto pc = node->createParameterClient(remote_node_name="other");
pc.set...;
pc.get...;
pc.list...;

The handle approach:

auto node = ...;
auto my_node_pc = ParameterClient(node, node_name="");
auto remote_node_pc = ParameterClient(node, remote_node_name="other");
pc.set...;
pc.get...;
pc.list...;

The single client approach:

auto node = ...;
auto pc = ParameterClient(node);
pc.searchForAll('*/foo/*')
pc.setP(fqpn)
pc.setP(parameter_name, node_name)
pc.setP(parameter_name)
pc.setLocalP(parameter_name)
pc.set...(node_name, ...);
pc.set...('parameter://node.ping/foo/bar');
pc.get...;
pc.list...;

AsyncParameterClient apc = pc->get_async...

auto node = Node(parameter_server=true)
auto ps = node->getParameterServer();

• [api] Draft (header/examples) of user's Server side of the parameters.

Implementation of parameters in rcl / rclcpp

AC:

• user accessible API
• demo application using parameters
  • get
  • set
  • list
  • on_update
  • on_change
  • on_create
  • on_delete

Consolidate information about Windows

Information about running and deploying our code on Windows is in two separate wikis, it may make sense to have them in a single page, but on separate sections.

Audit build caching

It seems that repeat builds of the ROS 2 stack with ament build will result in rebuilding or even regenerating code in parts of the system.

See: ament/ament_tools#32 (comment)

Limit setup and local_setup files to .bat on Windows

Currently when building on Windows there are few places where only a .bat comes out, but in other places the Unix equivalent files are also present. We should make that consistent and not produce Unix files when building on Windows.

AC:

• No .sh, .bash, or .zsh files are generated on a full Windows.
• Conversely, no .bat files should be generated on Unix.

Patch for OpenSplice to work with white spaces

Fix all test failures on Linux CI Batch Job

AC:

• All tests should pass without failure for the Linux CI Batch Job: http://54.183.26.131:8080/job/ros2_batch_ci_linux/lastCompletedBuild/testReport/
  • insufficient version of uncrustify on all OS's ament/ament_lint#20 to be handled on #34
  • OpenSplice publish / subscribe test fails - boths binaries seem to not talk to each other
  • several lint_cmake tests failing
• Missing Connext on:
  • OS X (#31) to be handled on #33
  • Linux (ros2/rmw_connext#20)

Update copyright years to 2015

Since we're actively creating code, I think it would be nice to start off with 2015 in everything.

So we should probably go through and update all of the LICENSE files and file headers. I don't expect us to do this every year, but it seems appropriate to me this time. Anyone -1?

Link error for Connext services on OS 10.10

On OS X 10.10 I get this linkedit error:

Undefined symbols for architecture x86_64:
  "connext::check_retcode(DDS_ReturnCode_t, char const*, RTILogMessage const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool)", referenced from:
      connext::details::SampleBase<userland_msgs::dds_::AddTwoIntsResponse_, DDS_WriteParams_t>::initialize() in AddTwoInts_ServiceTypeSupport.cpp.o
      connext::details::SampleBase<userland_msgs::dds_::AddTwoIntsResponse_, DDS_WriteParams_t>::copy_from(userland_msgs::dds_::AddTwoIntsResponse_ const&) in AddTwoInts_ServiceTypeSupport.cpp.o
      connext::details::SampleBase<userland_msgs::dds_::AddTwoIntsResponse_, DDS_SampleInfo>::initialize() in AddTwoInts_ServiceTypeSupport.cpp.o
      connext::details::SampleBase<userland_msgs::dds_::AddTwoIntsResponse_, DDS_SampleInfo>::copy_from(userland_msgs::dds_::AddTwoIntsResponse_ const&) in AddTwoInts_ServiceTypeSupport.cpp.o
      void connext::details::copy_sample<userland_msgs::dds_::AddTwoIntsResponse_, DDS_SampleInfo>(connext::Sample<userland_msgs::dds_::AddTwoIntsResponse_>&, userland_msgs::dds_::AddTwoIntsResponse_ const&, DDS_SampleInfo const&) in AddTwoInts_ServiceTypeSupport.cpp.o
      connext::LoanedSamples<userland_msgs::dds_::AddTwoIntsResponse_>::move_construct_from_loans(userland_msgs::dds_::AddTwoIntsResponse_DataReader*, userland_msgs::dds_::AddTwoIntsResponse_Seq&, DDS_SampleInfoSeq&) in AddTwoInts_ServiceTypeSupport.cpp.o
      connext::details::SampleBase<userland_msgs::dds_::AddTwoIntsRequest_, DDS_SampleInfo>::initialize() in AddTwoInts_ServiceTypeSupport.cpp.o
      ...
  "connext::RequesterParams::service_name(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      userland_msgs::service_type_support::create_requester__AddTwoInts(void*, char const*, void**) in AddTwoInts_ServiceTypeSupport.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

My current theory is that the shared libraries provided by RTI was not compiled with the same version of the std library as I have here on 10.10. I'd like to reach out to RTI on this one.

Until this gets resolved, the OS X CI job will continue to fail.

Setup Batch CI for Windows

AC:

• Create Windowns Jenkins Slave
• Setup a job to run William's wiki instructions
  • preinstall system dependencies
  • job clones and builds

---

Loop in @j-rivero

Use white space in path for batch CI jobs

Use it in all possible folder paths (workspace, build space, install space, source space).

Write unit test using various types

Write unit tests ensuring correct transmission of data from publishers to subscribers, exercising all primitive types, static arrays, dynamic arrays, and some amount of nesting.

OpenSplice examples are linked against Connext

If Connext is found, OpenSplice examples are linked against Connext instead of the correct library.

However, if no other DDS vendor is found, examples are properly linked against OpenSplice

Test isolated install on Windows

See: ament/ament_package#6 (comment)

AC:

• Building with the --isolated flag works on Windows

This will test out the isolated install local_setup.bat file for Windows.

Compare Windows unit test results with Linux

Depends on #21

AC:

• either equal test count or
• different test count with rational differences

Get Windows compiling working

Acceptance Criteria:

• Get ament tools running.
• Get a simple CMake project building and installing with ament tools.
• Get all packages (listed in ros2.repos) building and installing.
• Create document to describe how to use Windows to build ros2.

Fix linking on Windows

After discussing with @esteve on the whiteboard, I'm to clean up (one more time) the symbols being used for "getting type support handles". The current setup works on Linux and could on Windows, but is pretty confusing and inconsistent.

I'll follow up with the summary of our whiteboard work after this.

AC:

• Compiling and Linking work on Linux and Windows.
• Implementation specific executables do not cross talk (the linker is still able to choose the correct library).

Review API of generated message code

Revisit generated message code, make changes, document the result.

Package new Connext with Request/Reply API

Define the exterior parameter API

AC:

• Determine the external communication API
  • message types
  • topic names service names and semantics

---

Create reusable function to overwrite template files only if changed

This will save many identical lines of code such as the 11 copies in #40

Configure and Enable clang_format QA tool

We have a tools for checking our code with clang_format but it is not configured to our liking yet.

Acceptance Criteria:

• Decide on a configuration with the team
• Reenable the linter
• Create tasks for fixing failing packages

Replace instances of ros_middleware with rmw

We've decided to replace the usage of ros_middleware with rmw for brevity.

Enhance CI launcher job to pass "default" parameter

Currently you can set the same parameters on the launcher job as on the OS specific jobs, but there is not a way to pass only some options to the downstream OS specific jobs. For example, since the launcher job has the USE_CONNEXT option, the downstream jobs have to all use the same setter, so you couldn't have it on for Linux and Windows but off for OS X.

[demo] Camera images via lossy wifi

Goals:

• Demonstrate better comms over lossy wifi with large message, e.g. Camera Images
• Provide a method to try out different QoS settings (similar DDS's shapes demo)

Risks:

• How to emulate bad network?
  • Maybe use tc?

[demo] Image Processing Pipeline

The purpose of this demo is to demonstrate how ROS 2 can be used to write efficient multi node processing pipelines without sacrificing reusability, rapid development, or introspection. The idea is to setup an image processing pipeline that consists of several nodes which are publishing and subscribing to large messages (for example rgb or yuv images at a resolution >= 1280x1024) at high rates (for example 30 or 60 Hz) and show that the pipeline can operate with minimal copying of image messages. Additionally the demo can be used to show ROS 2's ability to do the runtime mapping of nodes to system processes. Giving the developer freedom to easily try different configurations and to make use of fault isolation while developing without costing production performance hits. Finally, this demo would be a candidate for showing off the type masquerading ability of ROS 2 (this is similar to how ROS 1 allowed pub/sub of non-ROS message types). Ideally, if one node publishes a custom message type and another node in the same process subscribes to the same custom type, then no copies would be needed.

Goals:

• Demonstrate use of efficient intra-process comms.
• Demonstrate configuration time organization of nodes into process.
• Demonstrate using non-ROS types in comms (type masquerading).

---

Needed features:

Intra-process communications for Pub/Sub (services might be a stretch goal).

• prototype rclcpp/rcl/rmw/rosidl support for inprocess messages which are used to synchronize access to shared pointers, while mimicking the QoS of the DDS network link. #59
• Find a way to instrument messages to monitor their construction/destruction/copy methods. ros2/rosidl#21 (for now we'll skip this)
• Propose intra-process design based on prototype and results of instrumentation.
• Develop tests for the intra-process comms.

Node Components (Component Nodes?)

The ability for users to write nodes which are agnostic to their execution, i.e. in its own process or sharing a process with others.

• Component style API (inherit from base class, instantiated by system) (already in rclcpp)
• [ ] Provide tooling (CMake and introspection) for creating “Component” style nodes. (partially available) moved to ros2/rclcpp#114
  • Each node generates a dynamically loadable shared library
  • Each node generates an executable
  • Each node generates any marker files or related meta data for discovery/tooling support
• [ ] Provide component “container” node which can load other nodes and run them. moved to ros2/rclcpp#115
  • Provide convenience tools for loading and executing nodes in existing processes.
  • Either by a proxy (like running a nodelet in ROS 1) or a Service call.
• Provide infrastructure for discovering, introspecting, and loading nodes.
  • This requires something like class_loader from ROS 1. #60
  • This requires something like pluginlib from ROS 1. https://github.com/ros/pluginlib/tree/ros2
  • Discovery should be based on the ament_index.

Node Component life cycle

• [ ] At least a minimal life cycle will be required to handle the loading of nodes into a node container, i.e. startup, run, shutdown.

Configuration Management

• [ ] Any features (syntactic sugar) needed in the launch needed to reasonably manage configuration of nodes and processes.
  • Perhaps some higher level interfaces to represent nodes and node containers.

Type Masquerading

Type masquerading is where you can publish and subscribe to types other than the message type of the topic as long as there is a mapping between them. Type masquerading is closely related to Intra-Process Communication, because if done properly no intermediate conversion is necessary if a publisher and subscribe in the same process are using the same masqueraded type.

• [ ] Define an interface for rclcpp similar to the “message traits” interface in ROS 1.
  • This allows a user to map a custom time to a ROS message type.
  • This interface needs to have something like conversion constructors so that the custom type can be converted to and from the ROS equivalent in memory.
• [ ] Add support for type masquerading in rclcpp where appropriate.
  • Publishers and Subscribers
  • Service Clients? and Service Servers? (probably a stretch goal for this demo)
• [ ] Avoid unnecessary conversions and copies when using with intra-process comms.
• [ ] Type masquerading should work with both intra-process and interprocess communications.

---

Other tasks:

• Setup package with demo in it.
  • Should have three or more nodes.
  • Should have large images being transported between nodes in more than one place.
  • [ ] Should use a non-ROS message type like OpenCV's image format.
  • [ ] Should provide a few example "launch files" for different runtime configurations.
  • [ ] Should have instructions on how to introspect the activity, including: dropped messages, message buffering, and message object construction, copying, and conversions.

Update packages to use QA tools

AC:

• Example packages running QA tools like linters
• update c/c++ linter configurations for 1 of these
  • cppcheck
  • uncrustify - separated: #14
  • cpplint - separated: #12
  • clang_format - separated: #13
• update existing packages to use the existing tools, as an automated test
• documentation about how to use tools

---

Unify Jenkins batch jobs

Acceptance Criteria:

• Jenkins jobs are parameterized on:
  • branch to use on ros2/ros2, defaults to ci_scripts.
  • whitespace in paths, e.g. workspace, source, build and install spaces.
  • whether or not to try to use Connext.
• Unify Jenkins jobs a much as possible.
• Minimize the platform specific differences in the jobs.

Each package needs its own visibility control macros

Reusing the macros from another package does not work since they will affect how symbols from recursive headers are treated.

E.g. ros2/rosidl_dds#12 was not working since it used the ROSIDL macros from the rosidl_generator_c package.

merge api_review branches

Acceptance Criteria:

• backup of current state in braches or tags (for stable target for CI)
• merge all API review branches
• get master compiling again
• get rclcpp examples working again
• update developer documentation to include the new repositories

---

There are api_review branches on several repositories:

• examples
• ros_middleware_interface
• ros_middleware_opensplice
• rosidl
• rosidl_dds

In addition to these branches there are some new repositories with new packages:

• rcl
• rclc

These branches and new repositories mainly refactor the major internal APIs (ros_middleware_interface and rcl) to be C only rather than C++ and makes some other structural changes to better support C and C++ at the same time.

These branches are in a partial working state. There are some things that work:

• C and C++ code .msg generation
• ros_middleware_opensplice has been updated to use new C only ros_middleware_interface

Other things do not work:

• rcl and rclc are only headers, they have no implementation.
• rclcpp does not use rcl.
• The two Connext implementations have not been updated at all.
• The new service work @esteve did is not integrated yet into the new C-only version of the ros_middleware_interface headers.

Configure and Enable the uncrustify

We have a tools for checking our code with uncrustify but it is not configured to our liking yet.

Acceptance Criteria:

• Decide on a configuration with the team
• Reenable the linter
• Create tasks for fixing failing packages

Move implementation of OS X CI Batch job to a repository

Currently the tasks are contained completely in the Jenkins job configuration.

AC:

• The steps to build the OS X batch CI moved to a repository.

---

Should we create a repository with the scripts for the batch CI jobs? Currently there is a repo on @tfoote's account: https://github.com/tfoote/ros2_batch_ci which contains the Docker stuff and Linux CI batch logic.

Add testing to Batch CI for Windows

AC:

• Tests are run
• Test results are summarized in jenkins

---

Follow up to #6

Create VS2015 Connext binaries from source

Now that we have the upstream source for RTI, try building a VS2015 version of their messaging library.

This would hopefully fix ros2/rmw_connext#31

Connects to #70

Package up RTI's distribution with the extra Messaging library

AC:

• Able to apt-get install RTI with all of the extensions we need to build our stuff.

Setup Batch CI for OSX

• Create OSX Jenkins Slave
• Setup a job to run based on the wiki instructions
  • preinstall some system dependencies
  • job clones and builds
• Build and run tests, tracking the test results with Jenkins

---

Support RPC with Connext XTypes

Tasks:

• Implement a unit test for server / client use case ros2/examples#13
• Implement parsing of service files in rosidl_parser ros2/rosidl#14
• Implement dynamic type support
• Implement rmw interface

AC:

• Service examples should work with the Connext X-Types Dynamic Data
• Service tests should pass with the Connext X-Types Dynamic Data

Basic multiprocess launcher with test awareness

AC:

• use Python asyncio
  • file format for encoding processes to be launched (plain python fine)
  • output to different destinations: console, log file
• support multiple error handlers
  • ability to launch and tear down processes (local only)
  • a way designate tests in the file format
• separate launcher executable (launch) from launch file containing the process information
  • identify launch files by full path
• support nesting launch files
• example with multiple tests in a single file
  • module level setup / teardown with async launcher
  • test function running launcher and adding coroutine for the test
• ability to integrate with ament
• collect test results (or pass in test results directory) I don't think the launcher needs to know about it

The following bullets should be separated into a new ticket since they require external functionally to exist before they can be implemented:

• launch API: locate launch files in share/pkgname/launch
• launch executable: identify launch file by package name and launch file name

Future features after clarifying API needs:

• support registering global callbacks