robotlocomotion/drake-ros

Experimental prototyping (for now)

Drake ROS

Getting Started

See drake_ros_examples for an example of getting started with both Drake and ROS 2 using colcon.

If you are using Bazel to build , please see ros2_example_bazel_installed.

About

The intended function of this repository is to provide the following ROS 2 capability:

• API for integration between Drake and ROS 2 components. See the drake_ros package.
• Examples using this API in the drake_ros_examples package.
• Bazel Starlark macros and tooling to enable ingesting (already built) ROS 2 workspaces from either installed locations or tarballs in bazel_ros2_rules.
  • Be sure to read about alternative approaches.
• Examples for using these APIs and Bazel macros in ros2_example_bazel_installed.

Supported Configurations:

• Ubuntu 22.04 + ROS 2 Humble (Recommended)
• Ubuntu 20.04 + ROS 2 Rolling
• Mac (only via Docker)
• Architecture: x86_64 (amd64), arm64 (only via Docker)
• Bazel >= 5.0

Docker Support

For users preferring Docker, we offer support for Ubuntu and Macs via Docker. You can build and interact with visualization (rviz2) directly on the Docker platform, which is particularly useful for Mac users, including those with Apple Silicon architecture. Please refer to our detailed Docker instructions in the Docker README.

Usable! But No Stability Commitment

This code is prioritized for use within the TRI Dexterous Manipulation Group. We do not presently adhere to any stability commitment (e.g., deprecations, backports, etc.), so please use this code at your own discretion. (It's still great code, of course!)

Please note that this should be considered second-party to Drake; more specifically:

• Only a small subset of Drake developers are directly involved in this project at present.
• This does not go through the same level of review as Drake's code review.
• This project does not yet align with Drake's release cycles or Drake's supported configurations.

Contributing

See CONTRIBUTING documentation.

drake-ros's Issues

ros_cc: Cannot run binaries using Rlocation via bazel-bin

In Anzu, I was trying to write a test that I could run outside of bazel run and bazel test (we must be able to do this).
However, I got errors about Drake not being able to find some basic files.

Ends up, it's an issue with how drake-ros does it's shimming in C++.

Filing PR that has sufficient testing.

Workflow unclear to make `ros2 topic echo` work for custom-generated types

In Anzu PR 9310, unable to use it for custom generated type; not immediately clear to me how to make this work.

FYI @sloretz @cottsay
\cc @IanTheEngineer @calderpg-tri

bazel: Should admit meta testing of `bazel build` via `bazel test` itself

Per @jwnimmer-tri's suggestion in #106 (comment), we should be able to test the build workflows itself, e.g. ensuring our current shims do not corrupt Runfiles resolution (#105).

For now, we can just add specific CI testing, but we should eventually use Bazel for the niceties that it can provide.

\cc @IanTheEngineer @sloretz

RViz2 has confusing behaviors - tf2 timing,

See repro in #121
Specifically, this commit / README:
https://github.com/RobotLocomotion/drake-ros/blob/bcf2eeddd355dd3e73a9cb16ccd6b91905a18138/ros2_example_bazel_installed/repro/README.md

sub issues; I'd like help with confirming these issues, dispatching this to relevant repositories and the relevant fixes:

• (1) Rviz2 is sensitive to only a few millseconds delay; it seems to have no option to control what lookup should be (timeout, use TimePointZero, etc.)
• (2) There is millseconds delay between publishing and RViz receiving it - why?
• (3) Rviz2 seems to not be showing all axes in MarkerArray - why?
• (4) Why does rclpy.spin_once(node) freeze when a node has no subscribers? That seems awkward?

For any of these, we really should not encourage any one to try and publish markers in the future, nor have them try and publish Time(0, 0).

It should be on the onus of the listener (Rviz) to handle this. My ideal is to have option to use TimePointZero, or whatever lookup means "give me the latest for this transform and its constituent lookups".

\cc @IanTheEngineer @sloretz @calderpg-tri @gbiggs

Should provide common drake-type ROS geometry/eigen conversions

From glancing around Drake and Anzu, I'm not sure if I see a consolidated place for converting eigen/geometry messages to/from Drake types.

I think they should live in drake_ros_core, and we should start ingesting them in Anzu.

Conversions (ROS <-> C++)

• Point <-> Eigen::Vector3d
• Quaternion <-> Eigen::Quaternion<double>
• Pose, Transform <-> Eigen::Isometry3d, drake::math::RigidTransformd
• Twist <-> Eigen::Vector6d, drake::multibody::SpatialVelocity
• Acceleration <-> Eigen::Vector6d, drake::multibody::SpatialAcceleration
• Wrench <-> Eigen::Vector6d, drake::multibody::SpatialForce

For flavors of Eigen::Vector6d, please keep same conventions as Drake, that is [rotational; linear]

\cc @calderpg-tri @IanTheEngineer

cross-talk check: Sometimes get error message about "lo" not being multi-cast capable

@sloretz On certain machines, if I run ./run //tools:ros2 node list, I sometimes get the following warning:

ros2: selected interface "lo" is not multicast-capable: disabling multicast

However, this only happens once per machine.
It seems to have happened on only 2 of 3 machines (I think...), which is disturbing, but I want to check.

How do I clear the cache for this warning / make it always show up across invocations?

pybind11 error: "cannot use Destroyable because destruction was requested"

In testing for #99 (comment), I suspended my laptop, then resumed it. I then disconnected from WiFi, then reconnected. I was hoping this would cause the warning about "lo" not supporting multicast to reappear.

However, when I did so, I now get the following stack trace:

$ bazel-bin/external/ros2/ros2 node list
Traceback (most recent call last):
  File "{bazel-bin}/external/ros2/archive/bin/ros2", line 33, in <module>
    sys.exit(load_entry_point('ros2cli==0.18.3', 'console_scripts', 'ros2')())
  File "{runfiles}/ros2/archive/lib/python3.8/site-packages/ros2cli/cli.py", line 89, in main
    rc = extension.main(parser=parser, args=args)
  File "{runfiles}/ros2/archive/lib/python3.8/site-packages/ros2node/command/node.py", line 37, in main
    return extension.main(args=args)
  File "{runfiles}/ros2/archive/lib/python3.8/site-packages/ros2node/verb/list.py", line 38, in main
    node_names = get_node_names(node=node, include_hidden_nodes=args.all)
  File "{runfiles}/ros2/archive/lib/python3.8/site-packages/ros2node/api/__init__.py", line 60, in get_node_names
    node_names_and_namespaces = node.get_node_names_and_namespaces()
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1109, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1450, in __request
    response = self.__transport.request(
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1153, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1169, in single_request
    return self.parse_response(resp)
  File "/usr/lib/python3.8/xmlrpc/client.py", line 1341, in parse_response
    return u.close()
  File "/usr/lib/python3.8/xmlrpc/client.py", line 655, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault 1: "<class 'rclpy._rclpy_pybind11.InvalidHandle'>:cannot use Destroyable because destruction was requested">

Unclear what state there is in the system.

@sloretz Sorry for the barrage, but any ideas? \cc @IanTheEngineer
(I will try to restart my system)

bazel_ros2_rules do not accurately hash all Python files for workspace analysis

In debugging / testing against #65, I tried making a change to ./bazel_ros2_rules/ros2/ros2bzl/scraping/system.py, but did not see any useful re-execution of this rule.

Currently, defs.bzl only lists files for resources/, but not the requisite Python files for ros2bzl. Thus, if there are changes there (i.e. bugfixes), then the workspace will not be updated.

We should ensure all relevant files are hashed and accounted for in the repository rule.

Not high priority, but we should fix this w/in next couple of months.

\cc @IanTheEngineer

Define a Styleguide for drake-ros

• Consider the Drake's take on the Google Style Guide:
  https://drake.mit.edu/code_style_tools.html
• Consider the ROS2's take on the Google Style Guide and Pep8:
  https://docs.ros.org/en/rolling/Contributing/Code-Style-Language-Versions.html
• Use amelt_link_auto tests to check for deviations from the chosen styleguide:
  https://github.com/ament/ament_lint/blob/master/ament_lint_auto/doc/index.rst

Should add provisioning / install_prereqs; possibly use for CI

We don't yet have provisioning on develop; #3 has provisioning, but I do not believe others do.

Per VC w/ Miche:

• Can maintain separate provisioning (not too much harder than joining, perhaps better for support matrix)
• Can use either order of ROS2 action + Drake containers or vice versa
• We should be careful about things like python-is-python2 from upstream provisioning #6 (review)

FYI @IanTheEngineer

Migrate bazelized github action away from ros-rolling-*-focal docker image

The bazelized workflow starts from a ROS Rolling focal image, but as Rolling rolled onto jammy I don't think it will get any more updates.

drake-ros/.github/workflows/bazelized.yml

Line 13 in 389c372

image: ros:rolling-ros-base-focal

The test steps don't actually use the ROS Rolling workspace that comes with it. They download ROS from the drake-ros-underlay archive. It seems like the image is being used for ROS tools (like rosdep). I think the job could use a plain Docker image (or the Drake focal image) with setup-ros to get the ROS tooling.

Add drake style linter configuration to drake-ros

bazel: Missing packages do not throw an error?

Encountered when authoring #101
With current develop (47b8932), a bad package name seems to be silently ignored. We should instead throw errors.

For example, apply patch:

diff --git a/ros2_example_bazel_installed/WORKSPACE b/ros2_example_bazel_installed/WORKSPACE
index 7019f71..be17e62 100644
--- a/ros2_example_bazel_installed/WORKSPACE
+++ b/ros2_example_bazel_installed/WORKSPACE
@@ -24,6 +24,7 @@ ROS2_PACKAGES = [
     "rclcpp_action",
     "rclcpp",
     "rclpy",
+    "wrong_package_name",
     # RMW implementations
     "rmw_cyclonedds_cpp",
     "rmw_fastrtps_cpp",

Then build:

bazel build @ros2//...

This will not throw any errors.

FYI @sloretz @IanTheEngineer (adding to board)

Should prevent ROS_DISTRO from polluting build

As encountered in Anzu build, if a ROS 1 workspace / setup is sourced, then the build may fail, e.g.:

INFO: Repository ros2 instantiated at:
  {source}/WORKSPACE:56:25: in <toplevel>
  {source}/tools/workspace/default.bzl:282:24: in add_default_repositories
  {source}/tools/workspace/ros2/repository.bzl:53:26: in ros2_repository
Repository rule _ros2_repository_rule defined at:
  {source}/tools/workspace/ros2/repository.bzl:42:40: in <toplevel>
ERROR: An error occurred during the fetch of repository 'ros2':
   Traceback (most recent call last):
    File "{source}/tools/workspace/ros2/repository.bzl", line 27, column 25, in _ros2_repository_impl
        base_ros2_repository(
    File "{workspace}/external/bazel_ros2_rules/ros2/defs.bzl", line 87, column 29, in base_ros2_repository
        result = execute_or_fail(repo_ctx, cmd, quiet=True)
    File "{workspace}/external/bazel_ros2_rules/tools/execute.bzl", line 16, column 13, in execute_or_fail
        fail("Failed to setup @{} repository: {}".format(
Error in fail: Failed to setup @ros2 repository: './run.bash {workspace}/external/bazel_ros2_rules/ros2/generate_distro_file.py -s {workspace}/external/ros2/ros2-linux:ros2-linux -d distro_metadata.json ros2' exited with 1
--- captured stdout ---
ROS_DISTRO was set to 'noetic' before. Please make sure that the environment does not mix paths from different distributions.

--- captured stderr ---
Traceback (most recent call last):
  File "{workspace}/external/bazel_ros2_rules/ros2/generate_distro_file.py", line 105, in <module>
    main()
  File "{workspace}/external/bazel_ros2_rules/ros2/generate_distro_file.py", line 98, in main
    args = parse_arguments()
  File "{workspace}/external/bazel_ros2_rules/ros2/generate_distro_file.py", line 64, in parse_arguments
    args.distro = json.load(args.distro_file)
  File "/usr/lib/python3.8/json/__init__.py", line 293, in load
    return loads(fp.read(),
  File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.8/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
ERROR: {source}/WORKSPACE:56:25: fetching _ros2_repository_rule rule //external:ros2: Traceback (most recent call last):
    File "{source}/tools/workspace/ros2/repository.bzl", line 27, column 25, in _ros2_repository_impl
        base_ros2_repository(
    File "{workspace}/external/bazel_ros2_rules/ros2/defs.bzl", line 87, column 29, in base_ros2_repository
        result = execute_or_fail(repo_ctx, cmd, quiet=True)
    File "{workspace}/external/bazel_ros2_rules/tools/execute.bzl", line 16, column 13, in execute_or_fail
        fail("Failed to setup @{} repository: {}".format(

\cc @IanTheEngineer

Fix build on ros-galactic-ros-base

Should ensure dependency ordering closely matches that of CMake; ensure shadowing is accounted for

• For target dependency ordering, ideally we have a (stable) order that reflects the same ordering as in CMake, at least in Starlark (unclear what may happen once Bazel ingests it).
  See: #128 (comment)
• For shadowing, we may need to ensure that this ordering is reflective of overlays, especially if shadowing happens at any level (hopefully on purpose):
  #124 (review)

\cc @sloretz @cottsay

dds, multicast: Documentation for multicast needs better troubleshooting steps / cross references

In addition to ros2/ros2_documentation#2615, the documentation for debugging multicast may need to be expanded.

From investigations on separate codebase, here are a suite of relevant commands for debugging on Ubuntu, hositing from Anzu issue 9239

---

Experiment setup, both machines Ubuntu 20.04:

• Desktop, connected to internet. Reserve one Ethernet NIC for laptop. Can configure for shared.
• Laptop, disconnected from everything. Plug NIC into Desktop NIC. Configure for Internet (Automatic DHCP), or Manual. Disconnect WiFi so there's only one possible multicast route.

Can use whatever UDP multicast, either ros2 multicast send/receive, or LCM.
Simple LCM script: RobotLocomotion/drake@fd50a9e61

Debugging commands

# see connections - raw to nicer to see
ip addr
ifconfig
nmcli

# see routes
ip route
# see specific route
ip route get <multicast-ip>

# add multicast route
sudo ip route add 224.0.0.0/4 dev <dev>
# remove multicast route
sudo ip route del 224.0.0.0/4 dev <dev>

# if using nm-connection-editor, add for 224.0.0.0, netmask 240.0.00 (/4)

# er... something
sudo iptables -L

# see existing connections - e.g. check if local address is `0.0.0.0` or specific bound address
netstat -anu

# look at connetions via wireshark, w/ display filter and autostart
sudo wireshark -i <dev> -Y 'ip.proto == "udp"' -k

Some connection notes:

Sender: Desktop, Receiver: Laptop

If both connected to LAN, should work - same as below.

If not:

• No routes - no dice.
• With route on Desktop, not (explicitly) on Laptop: Will route through "default" routing.
• With route on Desktop, explicit: Still good.

Sender: Laptop, Receiver: Desktop

If Laptop connected to LAN, ensure both machines have route to multicast (via ip route get 224.0.0.0). Then it should work, as "default" routing should route multicast.

If not, then:

• No routes - no dice.
• With route on Laptop, not Desktop: Can see traffic on Wireshark, but LCM won't receive b/c LCM receive socket will bind to the concrete address (and then get confused?. (Per Sammy, better than binding to 0.0.0.0:port and then filtering all traffic.)
• With route on both, works.

Additional Notes

Cannot explicitly route through multiple interfaces (w/o bridging), I believe.
Though it seems like kernel allows "default" to be shadowed - e.g. switching multicast from Internet (office LAN) to a more specific device.

dload: Clean up items

• Minimize generated code. At present, for C++, the template code is ~80 lines long, with character escaping. For both C++ and Python, we should break this down and provide libraries that are then used via ros_cc and ros_py.
• Do not re-shim environment variables. At present, there are no checks that we're already shimming. We should ideally say something like _BAZEL_ROS_RULES_SHIM. If set, we should not inject any new environment variables (that should be controlled by entrypoint, similar to runfiles as shown in #106). If unset, then we set env vars, and set this sentinel. This should happen in both C++ and Python.

\cc @IanTheEngineer @sloretz

Isolate `drake_ros_bazel_installed` build tooling for reuse

Precisely what the title says. As it stands, all infrastructure to build and run against ROS 2 from within a Bazel workspace lives in drake_ros_bazel_installed. This does not allow easy reuse by external Bazel projects.

Add correct topology of frames to broadcast TF2 information

The current implementation of drake_ros_tf2 provides correct transforms for all frames in a system, but they are all rooted in the world frame. Although this does not have an impact on use of the frames via tf2, it does not align with how frames are usually presented in ROS, which is as a tree with each frame being rooted in its real-world parent (i.e. a kinematic chain).

The problem is compounded when there are multiple robots in a scene. It can become confusing to find the correct frame for a particular robot except by naming - which assumes that the names of the frames are suitable for identifying their topological order.

There are some possible ways to resolve this. One is to get the topology information from the Multibody Plant. Another is to modify Drake (and push this modification upstream in a PR) so that the Scene Graph knows about topology of the objects in the graph. (See meshcat_visualizer.cc in Drake.)

Improve `bazel_ros2_rules` error handling

Failure modes for bazel_ros2_rules are quite opaque, if at all traceable -- specially when it comes to errors during CMake configuration scraping. Overall UX needs improvement.

CI is broken due to rolling + Ubuntu 22.04 shift

Currently, CI uses Docker images for rolling, and it's support (22.04) has shifted away from Drake's (20.04).

One possible solution is to use tarball approach to provision CI, even for non-Bazel workflows.

Drake Slack: https://drakedevelopers.slack.com/archives/C01B5B320QY/p1644958013772819

[bazel] Should make ROS 2 repository generation faster

Per comment and benchmarking in Anzu PR 8525:

Warning: This has some high-overhead repository rule generation, meaning any
BUILD files that depend on load('@ros2//etc', ...) will need to ensure the
repository rule fully executes before those dependencies can be analyzed.
Because of this, it may block other rules from effectively building.

For example, bazel test --config=lint //... will cause the repository rule to
be fetched (and executed if needed).

To benchmark anew, run:

cd anzu
bazel clean --expunge --async
# First, fetch stuff for simple Drake target to handle most repositories.
bazel fetch @drake//:module_py
# Now, record how long it takes for a ROS 2 target.
time bazel fetch @ros2//:rosidl

On 2022-03-10, harddrives listed for ~/.cache/bazel:

• Eric's Puget (nproc=64, 4TB SSD), took 60s
• Eric's P15 Laptop (nproc=12, 1TB NVMe), took 40s

Ideally, if not actually building any ROS 2 dependencies, we should attempt to minimize how much time is required to at least allow the loading of skylar rules from @ros2.

To do so, we need to somehow separate the ROS 2 Skylark from the actual ROS 2 dependencies.

For this, I would propose:

• Separating Starlark wrapping code to be emitted into @ros2_rules (or @ros2_bazel_rules)
• Keep the main code in @ros2

@sloretz Do you think this is something we can queue up for the next month or so?

cyclone dds: What does `/ParticipantIndex="none"` mean for usage in ROS2?

Wanted to check on rationale ROS_DOMAIN_ID, confirmed that yeah it's just direct link to DDS Domain ID, and it is used to partition port numbers.

Looked at docs for limit on number of participants:
https://docs.ros.org/en/humble/Concepts/About-Domain-ID.html#participant-constraints

Then also saw the Eclipse DDS stuff that @hidmic referenced to in rmw_isolation:
https://cyclonedds.io/docs/cyclonedds/0.9.1/config.html#controlling-port-numbers
https://github.com/eclipse-cyclonedds/cyclonedds/blob/0.9.1/src/core/ddsi/src/ddsi_portmapping.c#L39-L44
https://github.com/eclipse-cyclonedds/cyclonedds/blob/0.9.1/src/core/ddsi/include/dds/ddsi/ddsi_cfgelems.h#L1883-L1902
Looked at usage of ParticipantIndex="none" here too:

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/rmw_isolation.py

Lines 153 to 162 in c7f9c36

	builder.start('ParticipantIndex')
	builder.data('none') # disable unicast discovery
	builder.end('ParticipantIndex')
	builder.start('Ports')
	builder.start('DomainGain')
	builder.data('0') # ignore domain IDs
	builder.end('DomainGain')
	builder.start('ParticipantGain')
	builder.data(str(PARTICIPANT_ID_GAIN))
	builder.end('ParticipantGain')

Questions:

1. I am a bit confused about when multicast or unicast is used. Are there ROS-specific docs about this? (may relate #103)
2. Do we need to set ParticipantGain at all if can use auto-resolve its port (and thus overcome limitations on participant IDs)? (from code linked above, it appears not to be)
3. Should this be mentioned to some extent in ROS documentation?

\cc @sloretz @cottsay

Containerize drake-ros

This will aid in the creation of a CI pipeline. Create a dockerfile singularity example to the following requirements:

• base on prebuilt ros:${ROS_DISTRO}-ros-base docker container (rolling to start)
• install Drake and Drake's dependencies
• copy drake-ros source code into the container
• install source code dependencies
• build source code
• run unit tests, report results

ros2_example_bazel_installed: Should have simple cc,py example of using RMW isolation

Per Anzu 9275, we should have a simple cc and py test that exercises RMW isolation.
e.g. rmw_isolation_example_cc_test, rmw_isolation_example_py_test

Both can simply publish a float, and do no other verification (for now).

They should then be referenced by:
https://github.com/RobotLocomotion/drake-ros/tree/eba927fd3ecf0ce2819200e0a8176e7d3f366e2a/bazel_ros2_rules/ros2#tools

What our extended usage looks like in Anzu:
https://gist.github.com/EricCousineau-TRI/bf120a42d7aa835037642789a4c3c985

\cc @IanTheEngineer

ROS_DOMAIN_ID, ROS_LOCALHOST_ONLY: Unexpected behaviors?

I can reproduce Shane's results from #98 (but replacing bazel run //ros2_example_apps:oracle_cc with bazel-bin/ros2_example_apps/oracle_cc).
However, I have run into odd edge cases.

First, I confirm that using ros2 multicast send and ros2 multicast receive indicate a working UDP multicast route between two machines in both directions. (see #104 for debugging)
I also confirm that I have no ROS variables set in my nominal environment (env | grep ROS is empty).

To build, I use 8c20da4, and run:

cd ros2_example_bazel_installed
bazel build //ros2_example_apps:oracle_cc @ros2//:ros2

For checking crosstalk, I see if ros2 node list indicates that /oracle is present, as Shane did.

• By default, I do not see cross-talk traffic:
  Sender: bazel-bin/ros2_example_apps/oracle_cc
  Receiver: bazel-bin/external/ros2/ros2 node list
• Using ROS_LOCALHOST_ONLY=1:
  • I don't believe I have seen cross-talk.
• Using ROS_LOCALHOST_ONLY=0:
  • I don't see cross-talk if ROS_DOMAIN_ID is unset or set to ROS_DOMAIN_ID=0. Concretely:
    Sender: env ROS_DOMAIN_ID=0 ROS_LOCALHOST_ONLY=0 bazel-bin/ros2_example_apps/oracle_cc
    Receiver: env ROS_DOMAIN_ID=0 ROS_LOCALHOST_ONLY=0 bazel-bin/external/ros2/ros2 node list
    -and-
    Sender: env ROS_LOCALHOST_ONLY=0 bazel-bin/ros2_example_apps/oracle_cc
    Receiver: env ROS_LOCALHOST_ONLY=0 bazel-bin/external/ros2/ros2 node list
    • On top of that, I don't see local traffic when using ROS_LOCALHOST_ONLY=1 with ROS_DOMAIN_ID=0. Unclear why.
  • I see cross-talk traffic if ROS_DOMAIN_ID=1
    Sender: env ROS_DOMAIN_ID=1 ROS_LOCALHOST_ONLY=0 bazel-bin/ros2_example_apps/oracle_cc
    Receiver: env ROS_DOMAIN_ID=1 ROS_LOCALHOST_ONLY=0 bazel-bin/external/ros2/ros2 node list
    • I still see cross-talk traffic even if receiver has ROS_LOCALHOST_ONLY=1:
      Sender: env ROS_DOMAIN_ID=1 ROS_LOCALHOST_ONLY=0 bazel-bin/ros2_example_apps/oracle_cc
      Receiver: env ROS_DOMAIN_ID=1 ROS_LOCALHOST_ONLY=1 bazel-bin/external/ros2/ros2 node list

Concerns

1. Why does ROS_DOMAIN_ID=0 not work, locally or remotely, for ROS_LOCALHOST_ONLY=0?
   This contrasts with documentation that seems to indicate ROS_DOMAIN_ID=0 is valid: https://docs.ros.org/en/humble/Concepts/About-Domain-ID.html#choosing-a-domain-id-short-version
2. Why do I still receive on a machine with ROS_LOCALHOST_ONLY=1?

I don't believe we need to solve these now, but we should solve them ideally within next month.

This is painful to test manually, so I'd recommend we use Python + subprocess + ssh to automatically the following checks:

• sender={local,remote}, receiver={local,remote}
  • For each sender and receiver: ROS_DOMAIN_ID={unset,0,1}, ROS_LOCALHOST_ONLY={unset,0,1}

FYI @sloretz @IanTheEngineer

Non-determinsim prevents caching of cc compilation using bazel disk cache

Relates to #96

It seems like something either in our bazel_ros2_rules, or something else, is non-deterministic that prevents cache hits.

First make sure you have --disk_cache and --repository_cache configured.
The following script can configure it automatically, if you prefer: https://gist.github.com/EricCousineau-TRI/ca97ccc404ece082885d71c559d83936

Then see that multiple clean+rebuild still cause things like talker_listener.cc to be recompiled:

$ cd drake-ros
$ git log -n 1 --oneline --no-decorate
416cf8b Rename not-shimmed executables (#112)
$ git diff  # for reproducibility
diff --git a/ros2_example_bazel_installed/WORKSPACE b/ros2_example_bazel_installed/WORKSPACE
index d390251..d3af953 100644
--- a/ros2_example_bazel_installed/WORKSPACE
+++ b/ros2_example_bazel_installed/WORKSPACE
@@ -40,6 +40,7 @@ ros2_archive(
     # TODO(hidmic,cottsay): Make release-pinned snapshots of this repository once `drake-ros`
     # itself has versions.
     url = "http://repo.ros2.org/ci_archives/drake-ros-underlay/ros2-humble-linux-focal-amd64-ci.tar.bz2",
+    sha256 = "b7a8982cdc07a090b9719e35ae4735df82f9f648d5b703b93bc9db51e448f81d",
     sha256_url = "https://repo.ros2.org/ci_archives/drake-ros-underlay/ros2-humble-linux-focal-amd64-ci-CHECKSUM",
     strip_prefix = "ros2-linux",
 )
$ cd ros2_example_bazel_installed/
$ bazel clean --expunge --async
$ bazel build //ros2_example_apps:talker_listener_cc_test
...
INFO: Elapsed time: 43.834s, Critical Path: 10.97s
INFO: 150 processes: 5 disk cache hit, 142 internal, 3 linux-sandbox.
INFO: Build completed successfully, 150 total actions
$ bazel clean --expunge --async
$ bazel build //ros2_example_apps:talker_listener_cc_test
...
INFO: Elapsed time: 41.517s, Critical Path: 11.12s
INFO: 150 processes: 5 disk cache hit, 142 internal, 3 linux-sandbox.
INFO: Build completed successfully, 150 total actions

\cc @sloretz @IanTheEngineer

Add BUILD.bazel files to drake_ros_* packages

The drake_ros_* packages are CMake packages. This is convenient when working with tools in the ROS ecosystem. This is a ticket for adding BUILD.bazel files to those packages. That makes them convenient to include in a bazel workspace for those using Drake with bazel.

Attached is a bazel workspace example using #23 to display a capsule from a Drake multibodyplant in RViz using bazel.

capsule_example.tar.gz

Add integration test of the visualisation package

The drake_ros_viz package has unit tests for some aspects of its functionality, but no end-to-end test of the whole package. Add a test that verifies the correct markers are output for the iiwa sample multi-body system.

Stretch goal: Make the test give 100% coverage of all the different marker types that may be used.

Stretch goal: Make a test that verifies multiple markers (both different types and same types) can be used together.

Fix deprecation warnings from nightly Drake

After building with Drake's nightly binaries on Focal 20.04 on rolling, I encountered a few Drake API deprecation warnings in RosSubscriberSystem:

--- stderr: drake_ros_core
/home/robot/workspace/src/drake_ros_core/ros_subscriber_system.cpp: In constructor ‘drake_ros_core::RosSubscriberSystem::RosSubscriberSystem(std::unique_ptr<drake_ros_core::SerializerInterface>&, const string&, const rclcpp::QoS&, std::shared_ptr<drake_ros_core::DrakeRosInterface>)’:
/home/robot/workspace/src/drake_ros_core/src/ros_subscriber_system.cpp:74:6: error: ‘drake::systems::LeafOutputPort<T>& drake::systems::LeafSystem<T>::DeclareAbstractOutputPort(typename drake::systems::LeafOutputPort<T>::AllocCallback, typename drake::systems::LeafOutputPort<T>::CalcCallback, std::set<drake::TypeSafeIndex<drake::systems::DependencyTag> >) [with T = double; typename drake::systems::LeafOutputPort<T>::AllocCallback = std::function<std::unique_ptr<drake::AbstractValue>()>; typename drake::systems::LeafOutputPort<T>::CalcCallback = std::function<void(const drake::systems::Context<double>&, drake::AbstractValue*)>]’ is deprecated: \nDRAKE DEPRECATED: Pass a port name as the first argument.\nThe deprecated code will be removed from Drake on or after 2021-10-01. [-Werror=deprecated-declarations]
   74 |     });
      |      ^
In file included from /home/robot/workspace/src/drake_ros_core/include/drake_ros_core/ros_subscriber_system.hpp:17,
                 from /home/robot/workspace/src/drake_ros_core/src/ros_subscriber_system.cpp:21:
/opt/drake/include/drake/systems/framework/leaf_system.h:1655:22: note: declared here
 1655 |   LeafOutputPort<T>& DeclareAbstractOutputPort(
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/robot/workspace/src/drake_ros_core/src/ros_subscriber_system.cpp: In member function ‘virtual void drake_ros_core::RosSubscriberSystem::DoCalcNextUpdateTime(const drake::systems::Context<double>&, drake::systems::CompositeEventCollection<double>*, double*) const’:
/home/robot/workspace/src/drake_ros_core/src/ros_subscriber_system.cpp:128:53: error: ‘void drake::systems::EventCollection<EventType>::add_event(std::unique_ptr<_Tp>) [with EventType = drake::systems::UnrestrictedUpdateEvent<double>]’ is deprecated: \nDRAKE DEPRECATED: Use AddEvent instead.\nThe deprecated code will be removed from Drake on or after 2021-09-01. [-Werror=deprecated-declarations]
  128 |       drake::systems::TriggerType::kTimed, callback));
      |                                                     ^
In file included from /opt/drake/include/drake/systems/framework/system.h:27,
                 from /opt/drake/include/drake/systems/framework/leaf_system.h:29,
                 from /home/robot/workspace/src/drake_ros_core/include/drake_ros_core/ros_subscriber_system.hpp:17,
                 from /home/robot/workspace/src/drake_ros_core/src/ros_subscriber_system.cpp:21:
/opt/drake/include/drake/systems/framework/event_collection.h:138:16: note: declared here
  138 |   virtual void add_event(std::unique_ptr<EventType> event) = 0;
      |                ^~~~~~~~~
cc1plus: all warnings being treated as errors

I will be updating this repo with a Dockerized build and CI to catch these warnings.

Should enable drake-from-source build on CI (for Bazel build testing for C++ and Python)

From Drake Slack conversations:

• In CMake, we can do C++ and Python bindings from a binary (or source)
• In Bazel-from-source (drake_bazel_external), we can do C++ and Python bindings from source
• In Bazel-from-binary (drake_bazel_installed), we can do very unsupported C++, and Python code (but not bindings). Per Slack, there is no plan to prioritize this build mode.

Given this, we should enable source build on CI, ideally using Drake release pins + caching to minimize CI overhead + cost.

Per Jeremy's suggestion, we should try to fit w/in GitHub actions budget.
Failing that, we spend $$ (fastest) to provide sufficient CI resources to do this, as Drake budget is already fully allocated. Alternative is to help make Drake CI more efficient; however, that has a bit more overhead.

FYI @IanTheEngineer

Should remove as many hard-coded paths from generated shell files

At present, I see things like

for workspace in ~/.cache/bazel/_bazel_{user}/{hash}/external/ros2/ros2-linux; do ...

I don't believe we should be using absolute paths like this.
I suggest we use ${BASH_SOURCE} or something like $(readlink -f ${BASH_SOURCE}) instead.

Unclear when failure occurs due to lack of `dload` shim?

In Anzu, we had an issue where (somehow?) a node could run without a dload shim, but it would not communicate with other processes (e.g. because ROS_LOCALHOST_ONLY was a non-default value). See Anzu 9280.

There should be some way to warn about this, ideally? (not sure if via Starlark via deps analysis, runtime check, etc.)

\cc @IanTheEngineer

Should ensure adding new packages doesn't incur rebuild for existing packages

Not sure if this is expected, but when I added things like ros2cli to Anzu, it triggered a rebuild of several C++ programs.

I would not expected ros2cli to affect the hash / output of the dependencies.

Perhaps there is a date, timestamp, or something else somehow making it into the header files used for compilation?

Should add example usage of `rmw_isolation` in `ros2_example_apps/test`

Motivated by @sloretz's question in #75 - #75 (review)

• C++: #79
• Python

---

At present, Miche's awesome isolation work is presently only tested / shown in bazel_ros2_rules. For simplicity, we should show simple examples of isolation in a more app-oriented usage (and less about unit/stress-testing it).

C++

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/test/isolated_talker.cc

Lines 32 to 35 in e34b93b

	const char* TEST_TMPDIR = std::getenv("TEST_TMPDIR");
	if (TEST_TMPDIR != nullptr) {
	ros2::isolate_rmw_by_path(argv[0], TEST_TMPDIR);
	}

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/package.BUILD.bazel

Lines 32 to 47 in e34b93b

	cc_library(
	name = "rmw_isolation_cc",
	srcs = ["rmw_isolation.cc"],
	hdrs = ["rmw_isolation.h"],
	include_prefix = "rmw_isolation",
	data = [":generate_isolated_rmw_env"],
	local_defines = [
	"RMW_ISOLATION_ROOTPATH={}/{}".format(
	repository_name().strip("@") or ".",
	package_name())
	],
	deps = [
	"@bazel_tools//tools/cpp/runfiles",
	"//:rclcpp_cc",
	],
	)

Python

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/test/isolated_talker.py

Lines 23 to 26 in e34b93b

	def main():
	if 'TEST_TMPDIR' in os.environ:
	from rmw_isolation import isolate_rmw_by_path
	isolate_rmw_by_path(os.environ['TEST_TMPDIR'])

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/package.BUILD.bazel

Lines 62 to 73 in e34b93b

	ros_py_binary(
	name = "isolated_listener_py",
	srcs = ["test/isolated_listener.py"],
	main = "test/isolated_listener.py",
	deps = [
	"//:rclpy_py",
	"//:std_msgs_py",
	":rmw_isolation_py",
	],
	rmw_implementation = 'rmw_cyclonedds_cpp',
	legacy_create_init = False,
	)

This reflects our LCM-style testing philosophy - we explicitly let tests denote how they wish to isolate, but provide utilities to facilitate it.

Upstream Python test utility class

The ManagedSubscription class added in #24, used by tests to subscribe to a topic then wait for a given number of messages to arrive, would be generally useful. It should be upstreamed to launch_testing_ros (or elsewhere, as appropriate) so that the wider community can make use of it.

Should add Python linters; suggest black and isort

In Anzu, a subset of the team uses vanilla black (by construction ;)

We use isort with the following example config:
https://gist.github.com/EricCousineau-TRI/611327fabba051e869966f3b3883cb45

Relates to #8

rmw_isolation: Should ensure that traffic is isolated to local machine, regardless of network interfaces

In reviewing rmw_isolation for #125, I am now unsure if current rmw_isolation code is actually restricted to a local machine, e.g. for eclipse dds:

drake-ros/bazel_ros2_rules/ros2/resources/rmw_isolation/rmw_isolation.py

Lines 149 to 150 in c7f9c36

	multicast_discovery_ip_address = '.'.join(
	map(str, [239] + [int(c) for c in digest[:3]]))

For contrast, in Anzu, we have the following equivalent LCM code:

def unique_lcm_url(path):
    """Returns a unique LCM url given a path."""
    rand = [int(c) for c in hashlib.sha256(path.encode("utf8")).digest()]
    return "udpm://239.{:d}.{:d}.{:d}:{:d}?ttl=0".format(
        rand[0], rand[1], rand[2], 20000 + rand[3])

In this code, ?ttl=0 means packets should end on this machine, even if there is a viable physically outbound multicast route.

However, in rmw_isolation, I am unsure if we firmly secure the fact the equivalent of ?ttl=0.
Mayhaps we have now done it via ROS_LOCALHOST_ONLY=1; but if that is the case, we should not use set-if-unset but instead always force the env var.

\cc @sloretz

dload: Missing `set-if-not-set` for `ROS_DISTRO`?

In debugging things relevant to #103, I tried using ros2 doctor, but it would state that ROS_DISTRO is missing.

Reproduction:

$ cd drake-ros/ros2_example_bazel_installed/
$ git log -n 1 --oneline --no-decorate
eba927f Error when requested package doesn't exist in ROS 2 workspace (#109)
$ bazel build @ros2//:ros2
...

$ bazel-bin/external/ros2/ros2 doctor
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/package.py: 40: UserWarning: ERROR: ROS_DISTRO is not set.
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/package.py: 150: UserWarning: ERROR: distro packages info is not found.
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/__init__.py: 118: UserWarning: Fail to call PackageCheck class functions.
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/platform.py: 37: UserWarning: ERROR: ROS_DISTRO is not set.
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/platform.py: 69: UserWarning: ERROR: Missing rosdistro info. Unable to check platform.
1660064481.609199 [0]       ros2: selected interface "lo" is not multicast-capable: disabling multicast

1/4 check(s) failed

Failed modules: platform

$ env ROS_DISTRO=humble bazel-bin/external/ros2/ros2 doctor
${PWD}/bazel-bin/external/ros2/ros2.runfiles/ros2/archive/lib/python3.8/site-packages/ros2doctor/api/__init__.py: 118: UserWarning: Fail to call PackageCheck class functions.
1660064521.848429 [0]       ros2: selected interface "lo" is not multicast-capable: disabling multicast

All 4 checks passed

\cc @IanTheEngineer

Inject `@bazel_ros2_rules//...rmw_isolation` default deps

When instantiating a ROS 2 repository, bazel_ros2_rules drops an rmw_isolation package with its own set of ROS 2 dependencies. Currently, if the set of included packages excludes rclcpp or rclpy, the build will fail.

We need to ensure both are scraped by default.

Create a CI for drake-ros

• Consider Github Actions as the CI mechanism to minimize hosting dependencies.

bazel_ros2_rules invalid rules when workspace path ends in a trailing slash

I have a bazel WORKSPACE containing the following:

ros2_local_repository(
    name = "ros2",
    workspaces = ["/home/sloretz/ws/drake-ros/ros2/install/"],
    include_packages = ROS2_PACKAGES,
)

It fails to build because of missing input files.

ERROR: /home/sloretz/.cache/bazel/_bazel_sloretz/d43392360e412e7b55803d2e5399d634/external/ros2/BUILD.bazel:1952:11: SolibSymlink _solib_k8/_U@ros2_S_S_Cstd_Umsgs_Ucc___Uhome_Usloretz_Uws_Udrake-ros_Uros2_Uinstalllib/libstd_msgs__rosidl_generator_py.so failed: missing input file 'external/ros2/home_sloretz_ws_drake-ros_ros2_installlib/libstd_msgs__rosidl_generator_py.so', owner: '@ros2//:home_sloretz_ws_drake-ros_ros2_installlib/libstd_msgs__rosidl_generator_py.so'
ERROR: /home/sloretz/.cache/bazel/_bazel_sloretz/d43392360e412e7b55803d2e5399d634/external/ros2/BUILD.bazel:1952:11: SolibSymlink _solib_k8/_U@ros2_S_S_Cstd_Umsgs_Ucc___Uhome_Usloretz_Uws_Udrake-ros_Uros2_Uinstalllib/libstd_msgs__rosidl_generator_py.so failed: 1 input file(s) do not exist
Target //:capsule_example failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /home/sloretz/.cache/bazel/_bazel_sloretz/d43392360e412e7b55803d2e5399d634/external/ros2/BUILD.bazel:1952:11 SolibSymlink _solib_k8/_U@ros2_S_S_Cstd_Umsgs_Ucc___Uhome_Usloretz_Uws_Udrake-ros_Uros2_Uinstalllib/libstd_msgs__rosidl_generator_py.so failed: 1 input file(s) do not exist

The missing file external/ros2/home_sloretz_ws_drake-ros_ros2_installlib/libstd_msgs__rosidl_generator_py.so exists at external/ros2/home_sloretz_ws_drake-ros_ros2_install/lib/libstd_msgs__rosidl_generator_py.so, but a slash is missing. Removing the trailing slash from the workspaces argument (ex: /home/sloretz/ws/drake-ros/ros2/install) resolves the build failure.

Use CMake file API in Bazel ROS build infrastructure

Starting with CMake 3.14, CMake introduced its file API to replace its CMake server mode, which was deprecated and later dropped in CMake 3.20. Because of this, the infrastructure introduced by #3 is not compatible with CMake 3.20 and onwards.

We need to start using the CMake file API when the CMake server mode is missing.

Document drake_ros_systems package

Extend drake_ros_systems API documentation to be as complete and thorough as that of the Drake systems it was inspired in.

bazel_ros2_rules generates invalid BUILD.bazel when there's an underlay

Currently when an existing local ROS 2 workspace is sourced, bazel_ros2_rules will generate a BUILD.bazel file with absolute paths in places where Bazel labels are expected, thus making the whole build file invalid.

ros2_example_bazel_installed$ bazel build //...
Starting local Bazel server and connecting to it...
ERROR: Traceback (most recent call last):
	File "/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/BUILD.bazel", line 483, column 16, in <toplevel>
		share_filegroup(
	File "/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/tools/common.bzl", line 8, column 45, in share_filegroup
		srcs = [path for path in native.glob(
Error in glob: pattern cannot be absolute
ERROR: /home/sloretz/ws/drake-ros/drake-ros/ros2_example_bazel_installed/ros2_example_common/BUILD.bazel:6:24: no such target '@ros2//:action_msgs_defs': target 'action_msgs_defs' not declared in package '' defined by /home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/BUILD.bazel and referenced by '//ros2_example_common:_ros2_example_common_msgs__rosidl_typesupport_cpp_gen'
ERROR: /home/sloretz/ws/drake-ros/drake-ros/ros2_example_bazel_installed/ros2_example_common/BUILD.bazel:6:24: no such target '@ros2//:builtin_interfaces_defs': target 'builtin_interfaces_defs' not declared in package '' defined by /home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/BUILD.bazel and referenced by '//ros2_example_common:_ros2_example_common_msgs__rosidl_typesupport_cpp_gen'
ERROR: /home/sloretz/ws/drake-ros/drake-ros/ros2_example_bazel_installed/ros2_example_common/BUILD.bazel:6:24: every rule of type rosidl_generate_genrule implicitly depends upon the target '@ros2//:rosidl', but this target could not be found because of: no such target '@ros2//:rosidl': target 'rosidl' not declared in package '' defined by /home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/BUILD.bazel
ERROR: Analysis of target '//ros2_example_common:_ros2_example_common_msgs__rosidl_typesupport_cpp_gen' failed; build aborted: Analysis failed

Examples in BUILD.bazel

share_filegroup(
    name = "rti_connext_dds_cmake_module_share",
    share_directories = ["/home/sloretz/ws/drake-ros/ros2/install/share/rti_connext_dds_cmake_module", "/home/sloretz/ws/drake-ros/ros2/install/share/ament_index"],
)

cc_library(
    name = "rmw_fastrtps_dynamic_cpp_cc",
    srcs = ["/home/sloretz/ws/drake-ros/ros2/install/lib/librmw_fastrtps_dynamic_cpp.so", "/home/sloretz/ws/drake-ros/ros2/install/lib/libfastrtps.so.2.6"],
    hdrs = glob(["{}/**/*.h*".format(x) for x in ["archive/rmw_fastrtps_dynamic_cpp"]]),
    includes = ["archive"],
    copts = ["-isystem /home/sloretz/ws/drake-ros/ros2/install/include/rmw_fastrtps_dynamic_cpp"],
    defines = [],
    linkopts = ["-Wl,-rpath,/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_cpp/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_c/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rcpputils/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rcutils/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rmw/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rmw_dds_common/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rmw_fastrtps_shared_cpp/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_runtime_c/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_fastrtps_c/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_fastrtps_cpp/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_introspection_c/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/rosidl_typesupport_introspection_cpp/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/fastcdr/lib:/home/sloretz/ws/drake-ros/ros2/install/lib:/home/sloretz/.cache/bazel/_bazel_sloretz/effac4167a518523c467e34b5d8c3dd7/external/ros2/archive/fastrtps/lib"],
    data = [":rmw_fastrtps_dynamic_cpp_share", "/home/sloretz/ws/drake-ros/ros2/install/lib/librmw_fastrtps_dynamic_cpp.so", "/home/sloretz/ws/drake-ros/ros2/install/lib/libfastrtps.so.2.6"],
    deps = [":rmw_dds_common_cc", ":rcutils_cc", ":rmw_fastrtps_shared_cpp_cc", ":rcpputils_cc", ":rosidl_runtime_c_cc", ":rosidl_typesupport_fastrtps_cpp_cc", ":rosidl_typesupport_introspection_c_cc", ":rosidl_typesupport_introspection_cpp_cc", ":rosidl_typesupport_fastrtps_c_cc", ":fastcdr_cc", ":fastrtps_cc", ":rmw_cc", ":fastrtps_cmake_module_cc"],
)

ros_import_binary(
    name = "ament_clang_format",
    executable = "/home/sloretz/ws/drake-ros/ros2/install/bin/ament_clang_format",
    data = [":action_msgs_cc", ":rclpy_cc", ":rcl_lifecycle_cc", ":rcl_lifecycle_transitive_py", ":builtin_interfaces_cc", ":tracetools_cc", ":rosidl_runtime_c_cc", ":rosidl_runtime_c_transitive_py", ":rclcpp_action_cc", ":rclcpp_action_transitive_py", ":rcl_interfaces_cc", ":unique_identifier_msgs_cc", ":rmw_cc", ":rmw_transitive_py", ":rcl_yaml_param_parser_cc", ":rosgraph_msgs_cc", ":rcutils_cc", ":rcl_cc", ":rcl_transitive_py", ":rosidl_default_generators_cc", ":rosidl_default_runtime_cc", ":rosidl_default_runtime_transitive_py", ":rmw_implementation_cc", ":rmw_implementation_transitive_py", ":rcpputils_cc", ":rcpputils_transitive_py", ":yaml_cc", ":rosidl_runtime_cpp_cc", ":rcl_logging_interface_cc", ":rcl_logging_interface_transitive_py", ":rosidl_typesupport_fastrtps_cpp_cc", ":rosidl_typesupport_introspection_cpp_cc", ":rmw_connextddsmicro_cc", ":ament_index_cpp_cc", ":rosidl_generator_c_cc", ":rosidl_typesupport_introspection_c_cc", ":rcl_action_cc", ":rcl_action_transitive_py", ":rosidl_typesupport_interface_cc", ":rosidl_generator_cpp_cc", ":rosidl_parser_cc", ":rcl_logging_noop_cc", ":rcl_logging_noop_transitive_py", ":rosidl_typesupport_fastrtps_c_cc", ":rmw_fastrtps_dynamic_cpp_cc", ":rmw_fastrtps_dynamic_cpp_transitive_py", ":rosidl_typesupport_c_cc", ":rosidl_typesupport_cpp_cc", ":rmw_cyclonedds_cpp_cc", ":rmw_cyclonedds_cpp_transitive_py", ":fastcdr_cc", ":rosidl_generator_py_cc", ":rclcpp_cc", ":rclcpp_transitive_py", ":lifecycle_msgs_cc", ":rmw_fastrtps_cpp_cc", ":rmw_fastrtps_cpp_transitive_py", ":libyaml_vendor_cc", ":rmw_connextdds_cc", ":ament_cmake_cc", ":ament_cmake_transitive_py", ":rmw_implementation_cmake_cc", ":ament_cmake_core_cc", ":ament_cmake_export_targets_cc", ":rmw_connextdds_common_cc", ":rmw_connextdds_common_transitive_py", ":rcl_logging_spdlog_cc", ":rcl_logging_spdlog_transitive_py", ":rosidl_cmake_cc", ":ament_cmake_version_cc", ":libstatistics_collector_cc", ":libstatistics_collector_transitive_py", ":rti_connext_dds_cmake_module_cc", ":ament_cmake_export_interfaces_cc", ":ament_cmake_test_cc", ":rmw_fastrtps_shared_cpp_cc", ":rmw_fastrtps_shared_cpp_transitive_py", ":fastrtps_cmake_module_cc", ":std_msgs_cc", ":ament_cmake_export_link_flags_cc", ":statistics_msgs_cc", ":rmw_dds_common_cc", ":ament_cmake_export_libraries_cc", ":ament_cmake_python_cc", ":ament_cmake_export_dependencies_cc", ":ament_cmake_export_include_directories_cc", ":rosidl_adapter_cc", ":ament_cmake_libraries_cc", ":ament_cmake_export_definitions_cc", ":ament_cmake_gen_version_h_cc", ":spdlog_vendor_cc", ":fastrtps_cc", ":ament_cmake_target_dependencies_cc"],
    deps = [":action_msgs_py", ":rclpy_py", ":builtin_interfaces_py", ":rcl_interfaces_py", ":unique_identifier_msgs_py", ":rpyutils_py", ":rosgraph_msgs_py", ":rcutils_py", ":rosidl_typesupport_fastrtps_cpp_py", ":rosidl_typesupport_introspection_cpp_py", ":ament_index_python_py", ":rosidl_generator_c_py", ":rosidl_typesupport_introspection_c_py", ":rosidl_generator_cpp_py", ":rosidl_parser_py", ":rosidl_typesupport_fastrtps_c_py", ":rosidl_typesupport_c_py", ":rosidl_typesupport_cpp_py", ":rosidl_generator_py_py", ":lifecycle_msgs_py", ":rosidl_cmake_py", ":rosidl_cli_py", ":ament_cmake_test_py", ":std_msgs_py", ":statistics_msgs_py", ":rmw_dds_common_py", ":rosidl_adapter_py"],
)

`bazel build @ros2//:rviz_rviz` is misconfigured w/ amdgpu setup?

@calderpg-tri ran into this:

$ bazel build @ros2//:rviz2_rviz2
ERROR: {bazel_cache}/external/ros2/BUILD.bazel:551:11: @ros2//:rviz_ogre_vendor_cc: invalid label '/opt/amdgpu/lib/x86_64-linux-gnu/libGL.so.1' in element 24 of attribute 'srcs' in 'cc_library' rule: invalid target name '/opt/amdgpu/lib/x86_64-linux-gnu/libGL.so.1': target names may not start with '/'
ERROR: {bazel_cache}/external/ros2/BUILD.bazel:551:11: @ros2//:rviz_ogre_vendor_cc: invalid label '/opt/amdgpu/lib/x86_64-linux-gnu/libGL.so.1' in element 25 of attribute 'data' in 'cc_library' rule: invalid target name '/opt/amdgpu/lib/x86_64-linux-gnu/libGL.so.1': target names may not start with '/'
ERROR: error loading package '@ros2//': Package '' contains errors
...

for more info, see #59

Python bindings for the drake_ros_viz package may not cover the complete public API

The drake_ros_viz package added by #23 has some Python bindings added in #24. These Python bindings are sufficient to set up a visualiser system and connect it to a Drake system, as shown here.

However, it may give users more flexibility and feature availability if the remaining API of this package is made available via Python bindings.

This task is to investigate the remaining API of drake_ros_viz and determine if any of it is/should be public API, and then create Python bindings for the API calls and types that are identified as public.

ci: Not currently running on `develop`? Possible to see badges?

Current workflows on develop are not running.
https://github.com/RobotLocomotion/drake-ros/actions

Possible to see badges?

\cc @IanTheEngineer

Bazel based CI for Drake-ROS packages

Requires #68

Once there are BUILD.bazel files for using Drake-ROS packages in Bazel, this is a ticket to extend those files with unit tests and add to the existing CI to test pull requests against it.