New `tdma_multi_mac_node` node to handle switching among multiple tdma nodes using software mute

New Features / Improvements

• new node TdmaMultiMacNode and new message TdmaMultiMacStatus.msg
  • this MR will be calling an instance of TdmaMultiMacNode a tdma_manager but there is no requirement it be named this.
  • the TdmaMultiMacNode (called tdma_manager in the example test_tdma_multi_mac.launch) allows you to configure and switch between N tdma mac instances of different types and configs.
  • the tdma_manager will only have ONE tdma_namespace active at a time. It uses software_mute to keep all other tdma macs software_mute:True. (tdma macs MUST inherit from tdma_advanced to get software_mute. Only the base tdma cannot be managed by tdma_multi_mac)
  • ~default_tdma_namespace: MUST be set to string with tdma namespace relative to group tdma_manager is in to start and use as the default tdma mac.
  • ~managed_tdma_namespaces: List of strings with namespaces relative to tdma_manager. These TDMA nodes MUST exist and not crash or the tdma_manager will be blocked waiting for it to come up before being active!
  • TODO ~managed_tdma_heartbeat_timeout_sec: doesn't currently work (not hooked up). Will eventually require clients of tdma_manager to publish a heartbeat of some kind when a managed_tdma_namespace is active, else we revert to the default tdma if we don't get the heartbeat. (heart beat could be locally generated OR be an acoustic message)

Notes

• there is an example launch file here: ros_acomms/ros_acomms_tests/launch/test_tdma_multi_mac.launch. Use this as an example for the required parts of a launch file using a tdma_manager
• if you specify the managed tdma nodes out of order from the list passed to tdma_multi_mac ~managed_tdma_namespaces rosparam, unexpected behavior happens due to the serial nature of the initialization on the tdma manager (going through each tdma node at a time, blocking until that node is up and we have set it to mute and confirmed on the param server. An out of order launch file will cause the initial period before all tdma nodes are nominal to behave weird).
• make sure the ~managed_tdma_namespaces do not overlap and are all unique.
• probably a good idea to add the following to managed_tdma_namespaces node xml tag clear_params="true"
• tdma_multi_mac publishes status here: /<platform>/tdma_multi_mac_status. This is a great source of info for the currently active tdma mac. This is a latched topic so you'll get the last msg whenever subscribe happens.

Tutorial

• how to select and switch between multiple macs using a TdmaMultiMacNode instance:
  • say we have a list of managed_tdma_namespaces and a default_tdma_namespace of:

          default_tdma_namespace: 'tdma'
          managed_tdma_namespaces:
              - 'tdma_A'
              - 'tdma_B'
              - 'tdma_C'
              - 'tdma_D'

    • to select 'tdma_A', ('tdma' --> 'tdma_A') publish a std_msgs/Bool data=True to the topic /<platform>/<tdma_manager_name>/tdma_A/select
    • to select 'tdma_B', ('tdma_A' --> 'tdma_B') publish a std_msgs/Bool data=True to the topic /<platform>/<tdma_manager_name>/tdma_B/select
    • to select 'tdma_C', ('tdma_B' --> 'tdma_C') publish a std_msgs/Bool data=True to the topic /<platform>/<tdma_manager_name>/tdma_C/select
    • to select 'tdma_D', ('tdma_C' --> 'tdma_D') publish a std_msgs/Bool data=True to the topic /<platform>/<tdma_manager_name>/tdma_D/select
    • to de-select 'tdma_D', ('tdma_D' --> 'tdma') publish a std_msgs/Bool data=False to the topic /<platform>/<tdma_manager_name>/tdma_D/select, this will put you back in the default_tdma_namespace.