Draft: pass-thru (gateway) packet_dispatcher capability

NOTE: Pipeline tests failed - Issue #36 Submitted

GATEWAY PASS-THRU

This added capability improves a gateway's functionality, which can now "pass-thru" a Rx'd ACOMMs message (ros_acomms/ReceivedPacket) if a packet payload's codec id matches a value in the ~pass_thru_codec_ids list (rosparam). If a match, the packet_dispatch_node will re-publish the entire ReceivedPacket on the ~pass_thru_topic (rosparam) to forward i.e. over Iridium, but potentially also via ACOMMS.

FAR-SIDE DECODING

On the far end e.g. shoreside (but potentially an underwater receiving station/diver), if the packet_dispatch_node decodes a ReceivedPacket and the ~decode_meta_packet (rosparam) flag is set , the packet_dispatch_node will 're-run' [the RxdPacket] thru its packet-decoder routine to get the "original" packet payloads, most importantly being able to decode from the original SRC, outputting ROSMSGs on their respective {name}/{src} topics.

This resolves the current issue involving messages received at a "gateway" and forwarded over Iridium, which are then decoded with the gateway's SRC ID instead of the original vehicle's SRC ID

src_names: {0: 'vehicle0', 1: 'gateway'}

desired outcome: vehicle0/status --> gateway --> shoreside --> {name}/status --> vehicle0/status
existing outcome: vehicle0/status --> gateway --> shoreside --> {name}/status --> gateway/status

resolved outcome: (desired)

This merge provides the following additions to the packet_dispatch_node:

• ~pass_thru_codec_ids <List[int]>: list of message codec IDs to forward over the...
• ~pass_thru_topic <str>: topic name where the `ReceivedPacket` msg (with matching msg codec ID) will be forwarded
• ~gateway_only_mode <bool>: only pass-thru macthing codec ids, do not publish locally
  • open to conversation if this USE CASE is ever wanted/desired/needed)
• ~decode_meta_packets <bool>: explicitly re-run the decoder when a ReceivedPacket type ros msg is received
  • open to conversation on whether implicit route (ALTERNATIVE METHOD) is the correct way to go

TESTING

• added ros_acomms_tests/launch/test_gateway_dispatcher.launch file that replicates the Gateway Dispatcher Overview Diagram
• uses the ros_acomms_tests/launch/test_gateway_dispatcher_config.yaml

CONSTRAINTS

• all ros msgs contained within a fwd'd ReceivedPacket will be decoded on the far end, even if only 1x msg matched the ~pass_thru_codec_ids list filter
  • e.g. gateway ReceivedPacket contains 3x ros msgs with codec ids 1, 2, 3; only codec id 1 matches the filter, but the entire RxdPacket is forwarded...
  • on the far end, all 3x ros msgs will still be decoded
• msg codec ids being passed-thru should be the same between different codec_config.yaml files (requires good housekeeping)
  • the following WILL NOT work and will lead to decoding failures on shoreside:

    • acomms_codec_config.yaml

      - id: 1
        subscribe_topic: status
        publish_topic: from_acomms/status
        ros_type: ros_remus/Status

    • iridium_codec_config.yaml

      - id: 1
        sub_topic: ack
        pub_topic: from_iridium/ack
        ros_type: ros_acomms/EncodedAck
      - id: 8
        sub_topic: status
        pub_topic: from_iridium/status
        ros_type: ros_remus/Status

ALTERNATIVE METHOD

Another method of "recursively decoding" a RxdPacket was identified, tested, and found to work. However, the method is more implicit and so I developed the more explicit approach, requiring a USER to setup a launch file's packet_dispatch_node with the explicit ~decode_meta_packets rosparam set to <True>...

Note however, this alternative approach will still work with the ~decode_meta_packets rosparam explicitly set to <False> (or not set at all)

any decoded ReceivedPacket can simply be re-published via codec_config.yaml's publish_topic: packet_rx topic and reprocessed the same...

    - id: 3
      message_codec: default
      subscribe_topic: "pass_thru"
      publish_topic: "packet_rx"
      ros_type: "ros_acomms_msgs/ReceivedPacket"

I am not a WHOI employee, I agree to the terms in the WHOI Contributor Agreement (CONTRIBUTING.md) in this repository.