Added generic comms bridge (#756)

astrobee/config/communications/comms_bridge.config

@@ -0,0 +1,96 @@
+-- Copyright (c) 2017, United States Government, as represented by the
+-- Administrator of the National Aeronautics and Space Administration.
+--
+-- All rights reserved.
+--
+-- The Astrobee platform is licensed under the Apache License, Version 2.0
+-- (the "License"); you may not use this file except in compliance with the
+-- License. You may obtain a copy of the License at
+--
+--     http://www.apache.org/licenses/LICENSE-2.0
+--
+-- Unless required by applicable law or agreed to in writing, software
+-- distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+-- WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+-- License for the specific language governing permissions and limitations
+-- under the License.
+
+require "context"
+
+-- Enable DDS communications on start --
+-- If false, a trigger call will be needed to start communications --
+initialize_dds_on_start = false
+
+-- The verbosity is used to control the output of the underlying ros
+-- publisher/subscriber. Level 2 is the most verbose and will output all of the
+-- output including debug statements. Level 1 will output all output except
+-- debug statements and level 0 will only output warnings and errors. Since
+-- all output statements go directly to the ros log, it is safest to keep it
+-- set to 2.
+verbose = 2
+
+-- ad2pub_delay is a time amount in seconds. The bridge publisher must receive
+-- the adverttisement info message for a topic before it can publish a content
+-- message for that topic. If the bridge publisher receives the content message
+-- before the advertisement info, it will save the content message if the
+-- ad2pub_delay is greater than 0. If the bridge publisher receives the
+-- advertisement info message within the ad2pub_delay time, it will process
+-- and publish the content message. If the comms bridge seems to be dropping
+-- the first few messages, try increasing this value.
+ad2pub_delay = 3.0
+
+links = {
+  -- Logically, there could be up to three two-way links between the three robots. In practice, we
+  -- will probably only have one link.
+  {
+    -- A single link entry has required fields "from" and "to" that specify the robot roles involved
+    -- in the link.
+    -- This link will only work on the ISS since it uses the names of the
+    -- robots on the ISS. Please add more links if Queen goes back to the ISS.
+    from = "Bumble",  -- manager
+    to = "Honey",     -- actor
+
+    -- The link entry has three optional fields: relay_forward (messages to be relayed only in the
+    -- `from` to `to` direction), relay_backward (to be relayed only in the `to` to `from` direction),
+    -- and relay_both (to be relayed in both directions). Providing all three fields gives the user
+    -- full directional control while minimizing repetition and copy/paste errors.
+
+    -- Each topic entry can contain an input topic and an output topic. The
+    -- in topic is the topic being published on the robot sending the data and
+    -- must be specified. The optional out topic is the name of the topic a
+    -- user wants the data published on in the receiving robot. If the
+    -- out topic is not specified, the comms bridge will set it to be the name
+    -- of the robot sending the data combined with the in topic name. For
+    -- instance, if the from robot was Bumble and the to robot was Honey and
+    -- one of the in topics in the relay forward list was "mgt/ack", then it
+    -- would be published on Honey on topic "bumble/mgt/ack".
+    -- Please note that only one unique in topic can exist in the relay forward
+    -- and relay both lists and the relay backward and relay both lists. It is
+    -- fine to have the same in topic in the relay forward and relay backward
+    -- lists.
+
+    relay_forward = {
+    },
+    relay_backward = {
+    },
+    relay_both = {
+      {in_topic = "gnc/ekf"},
+      {in_topic = "gs/data"},
+    },
+  },
+  {
+    -- This link will only work in the granite lab since it uses the names of
+    -- the robots in the granite lab.
+    from = "Bsharp",  -- manager
+    to = "Wannabee",  -- actor
+
+    relay_forward = {
+    },
+    relay_backward = {
+    },
+    relay_both = {
+      {in_topic = "gnc/ekf"},
+      {in_topic = "gs/data"},
+    }
+  }
+}

astrobee/config/communications/dds_generic_comms/NDDS_DISCOVERY_PEERS

@@ -0,0 +1,6 @@
+;; NDDS_DISCOVERY_PEERS - Discovery Configuration File
+;; This file is used to configure the dds portion of the comms bridge
+; EVERY LINE IN THIS FILE MUST END IN A COMMENT. Even blank lines.
+;
+;; Add the IP addresses of the robots to communicate with
+127.0.0.1       ; Local host is added by default