Considering remote sensing in "real-time"

[tygamvrelis]

Brandon mentioned the idea of having 2 copies of the lamp setup: one mounted on a boat in recording mode, and one mounted in a gallery in playback mode. Data would be sent from the one on the boat to the one in the gallery for actuation, hence linking the two setups.

Things to figure out:

• How to set up the network send/receive for this?
• What kind of latency and reliability can we expect from the network?

[bturep]

Very excited about this. Will be thinking about and speaking to people at the Marine Centre for Simulation at Memorial University regarding the possibility of getting the lamp out on a ship as a "remote sensing unit"

[tygamvrelis]

If we do this, we will want to use UDP for the transport layer over the internet. This is an unreliable transport protocol, but it's very low overhead and low latency. UDP is used in real-time applications that can tolerate a bit of loss, such as gaming.

[tygamvrelis]

I had some luck today transferring angle data between two computers on different networks using the code on on the networking branch. I used LogMeIn Hamachi to create a VPN for these computers, and used the IP addresses for the virtual network adapters for the communication.

Some next steps I can think of are:

• Measure latency
• Measure bit rate (what are our packet sizes? What's the overhead like of the VPN stuff?)
• Add buffering on the playback side
  • As a configurable setting, we could allow it to pool data for X seconds. This will add an X-second delay to playback relative to the source being recorded, but it will also make the system less sensitive to fluctuations in network throughput
  • How to deal with sequence numbers intelligently?
• Packet size. Should each new data sample be sent as its own packet, or should we collect a couple of them together (fewer transmissions)?
• How to process data in real-time?
  • The angle estimation can already be done in real-time without significant code changes. But other types of data processing (e.g. NaN removal) are not implemented as real-time functions
  • Smoother limiting filter
• If one side goes down, how to make application fail smoothly?
  • If recording side goes down:
    • Playback side: can we detect this and smoothly stop the motion before smoothly restarting it? Or should we perhaps loop over the past minute or so of received data?
    • Recording side: can we make the RPi restart the program?
  • If playback side goes down, debug it there in person. Recording side will probably have no awareness of this
• If a client leaves the VPN while the system is running, how will the recording side and playback side behave? Can we make them behave gracefully when this failure occurs, and recover?
• On which device(s) should persistent records be made of the angle data?
  • i.e., do we want the recording device to maintain a text file containing the angle data, or should the playback device do this? Or both?
• What kinds of (non-angle-data) commands might we want to have between the networked recording device and the networked playback device?

[tygamvrelis]

For measuring bit rate, I downloaded a tool called GlassWire and recorded the throughput over a 2 minute duration. Approximately 373.5 kB were transmitted from the Python program during this time, meaning that the average bit rate was:

373.5 kbyte * 8 bits per byte / 2 minutes / 60 sec per minute = 24900 bits per second

This was without Hamachi on.

With Hamachi on, the average bit rate was measured to be 22360 bits per second (probably just a random fluctuation). The Hamachi Client Tunneling Engine also sent 26400 bits over a 1-min period (25600 of which were when I first started up Hamachi though)

Also note that we were not getting 100 samples per second with this rate.