utexas-bwi / bluetooth_bridge Goto Github PK

It would be helpful to have some tools that could identify possible strengths or weaknesses of the bluetooth_bridge suite as a multi-robot communication system.

In addition to raw statistics like cross-machine message latency and bandwidth, it is prudent to analyze how these things scale when resources become scarce, i.e. when

1. more than 1 agent is connected at the same time
2. agents are sharing large messages such as video streams

While the serial_bridge does not fail on a connection loss event, the previously connected agent's topics are still available locally but no longer publishing data.

The serial_bridge does have the ability to deregister publishers and subscribers, but ideally this would happen when the connected bluetooth device is no longer within range- something the port manager has access to in theory. The ability for the port manager to notify the serial_bridge of this is likely blocked due to the reliance on system calls (see #2)

Cohesive documentation is needed:

• consolidate information in the READMEs
• add docstrings to functions
• add document headings
• add license and author information where needed

The port manager sets up a virtual serial port through system calls to make the port accessible to the entire Linux machine.

While this works, it has many shortcomings:

1. it limits the degree of error handling around the creation and maintenance of ports, especially when connection is lost
2. it requires the port manager to be run with sudo access
3. it has a fundamental limit on scalability, as there are a finite number of virtual ports that can be made
4. it requires a serial_bridge instance for each port

if feasible, virtual ports should be eliminated and migrated to serial port objects that emulate the RFCOMM bluetooth profile.

Some standard topics can have needlessly high publish rates. /odom for instance on the V4s have a publish rate of 100Hz. The ability to cap incoming messages to a lower publish rate would reduce the load on the limited bluetooth bandwidth.

The Subscriber class works as intended bidirectionally- the local machine is expected to have those topics already available, subscribes to them internally and then relays them over the socket to the bridge on the remote, which in turn makes Publisher objects to handle the incoming flow.

Ideally Publisher objects could handle the opposite case, i.e. the local machine specifically wants to listen to a particular topic on a remote bridge.

This functionality should be close to working in its current state, but doesn't quite work as intended.
Other classes have not been thoroughly tested at all ( ServiceClient, ServiceServer ) as their use for close proximity, multi agent interactions is lower priority than data sharing. Even so, these should be tested and modified if needed for completeness.

Given the limitations of bluetooth bandwidth, compression is especially useful for this use case

While #8 lays the groundwork for multiple simultaneous connections, this has not been extensively tested

Proper IO handling system between bluetooth_port_manager and port_manager_interface, the latter being introduced by #8. While port_manager_interface acts as an intermediary between the Python library bluetooth_port_manager and the ROS nodes of serial_bridge, there is useful output from port_manager_interface that isn't logged by ROS due to the fact that it is printed directly to the console.