ntlhui
commented
2 months ago Note that the current drone_based_NH is set up the following way:
simulator should be a TCP server, while the GCS should be a TCP client. Both on localhost, port 9000.
The problem is that the TCP server is not implemented as a transport factory in rctcomms. One solution may be to make a transport spec tcps1 which is a TCP server that accepts exactly 1 connection, that way it has the same semantics as tcpc.
Note that drone_based_NH is currently locked on rctcomms@819640c1e1e0feac58eaf7b707671ba2d229703a. You will need to roll rctcomms forward to latest before you do any development on rctcomms. I think this should be a trivial roll forward.
For modifying rctcomms:
You will need to add tcps1 to the LUT at https://github.com/UCSD-E4E/radio_collar_tracker_comms/blob/551f1c9d8c69aa0f42b7ca6f94341f58a04a7b5b/RCTComms/transport.py#L727.
You will then need to create a factory method similar to https://github.com/UCSD-E4E/radio_collar_tracker_comms/blob/551f1c9d8c69aa0f42b7ca6f94341f58a04a7b5b/RCTComms/transport.py#L753
That connection object will be created from https://github.com/UCSD-E4E/radio_collar_tracker_comms/blob/551f1c9d8c69aa0f42b7ca6f94341f58a04a7b5b/RCTComms/transport.py#L395.
The behavior should be that the first connection is accepted using https://docs.python.org/3/library/socket.html#socket.socket.accept. Subsequent connections should be allowed to time out and should not be handled. This connection object can be wrapped into the RCTTCPConnection object defined at https://github.com/UCSD-E4E/radio_collar_tracker_comms/blob/551f1c9d8c69aa0f42b7ca6f94341f58a04a7b5b/RCTComms/transport.py#L478 and returned from the factory function.
Make a branch from NH_branch.