I've targeted this PR to the galactic branch, but will change that ASAP if the maintainers could push a foxy branch off of the current repository head.

@aprotyas Thanks for working on this :) I've retargeted the PR to foxy (which is based on galactic).

I've also pushed a commit to your branch to make CI target Foxy (cce4273).

@jacobperron thanks for retargeting to foxy.

Question: from the TODOs in the PR description, should the preference be to backport the PRs which introduced said rclcpp functionality, or to opt for the alternative methods I listed (usually just falling back to the rmw/rcl headers)? The latter option is nontrivial for the rclcpp::*Policy enum classes and almost impossible for rclcpp::InitOptions::set_domain_id, but I've already done that for rclcpp::Context::get_domain_id in 925a5e1.

EDIT (10/30)

Alright, so domain_bridge_lib and its tests successfully compile now, but there are a bunch of test failues. It looks like they're almost all related to the fact that the domain ID is not set correctly.
There really does seem to be no way to set the domain ID. Thoughts?

Hi. I just tried to test this branch with with ROS foxy, but i encountered an error when a node begins to publish some data. I used the example_bridge_config.yaml file as mentioned in the readme file and published data in the chatter topic. the error is:

terminate called after throwing an instance of 'std::runtime_error'
  what():  unexpected callback being called

this is my example_bridge_config.yaml file:

name: my_bridge
from_domain: 0
to_domain: 3
topics:
  chatter:
    type: example_interfaces/msg/String

am i missing something alongway doing it or it's a known issue?

@antonyramsy this branch was still WIP and I didn't have enough bandwidth to get back to it for a while now.

I remember seeing these errors when I was testing this branch too, and the problem was that in Foxy, rcl offers no such API to set domain IDs -- check #60 (comment) for what I'd already (unsuccessfully) tried. I just never had time to fully verify that my approach in efa97ae works.

I might have some time to revive this PR soon-ish, but if you need this branch to work soon I think the way to go would be to run the tests in this package and debug the errors from there. As it is, I think your configuration is correct but the branch is not ready to land.

@aprotyas Thanks a lot for the response. I will consider using this package along with other approaches i can take, and will inform if any progress in the development has taken place.

@jacobperron as of ff41c31, the end-to-end tests pass in this branch. I'm still struggling against the default lifespan and deadline values in QOS profiles.

From ros2/rmw#301 (review), it looks like in Foxy, the default zero values for the lifespan and deadline means each RMW uses its own default value, which is difficult to test against compared to the "max" duration enforced post-Foxy (i.e. rclcpp::Duration(std::numeric_limits<int64_t>::max())). Is there a way around this?

@antonyramsy, this branch may be good to go now. If possible, can you test this branch out?

@aprotyas Hi, sorry for delay. I've tested the updated code both on foxy and humble. in normal condition(sending some data in one domain and receiving it in another one) both of them are ok. but i realized that bidirectional bridging in ROS foxy is not working as i expect (maybe i'm doing it in the wrong way) but in humble it works fine(by using the same YAML config file in different versions of ROS). here is the config i'm using to test bidirectional bridge:

name: my_bridge
from_domain: 2
to_domain: 3
topics:
  chatter:
    type: example_interfaces/msg/String
    remap: chitter
    bidirectional: True

with this config i was able to publish some date on topic chatter from domain 2 and receive it in domain 3 under chitter topic. and vice versa(publishing in domain 3 in topic chatter and receiving it in domain 2 in topic chitter ) in ROS humble.

but doing the same in ROS foxy, although you are able to send data from domain 2 to 3, but you wont be able to see published data from domain 3 in topic chatter in domain 2 in topic chitter (the topic chitter does not show up in ros2 topic list command result.)