Inter-robot communication

[byorgey]

This may be still a ways off, but eventually we certainly want to be able to have inter-robot communication. This would enable lots of cool things such as remotely controlling or reprogramming robots, creating teams of robots that can dynamically coordinate among one another, etc. There is some discussion of this in https://github.com/byorgey/swarm/issues/17#issuecomment-927669308 .

There is a lot of language design work to be done here. My initial vague thought is to look for inspiration to things like pi-calculus and session types. Probably full-on session types are too heavy-handed, though. Maybe something simple like typed broadcast channels: a value of type chan t is a channel over which values of type t can be broadcast, supporting operations like

write : forall t. chan t -> t -> cmd ()
read : forall t. chan t -> cmd (unit + t)

Channels will be private in the sense that only robots with a reference to a channel can use it. However, once we merge #303, binding the result of newChannel to a name will automatically make it available to later REPL commands and to robots built afterwards.

There are also game design issues to think about; e.g. what sort(s) of device(s) should be needed to use these features? How far should the signals travel? On the one hand it might be annoying to have to worry about signal strength; on the other hand it might be kind of cool to have to set up a network of robots serving as signal repeaters.

EDIT (14 April 2023): Here's a summary of my latest thinking.

• chan t represents a typed broadcast channel, as before.
• There is no plain newChannel operation. Rather, channels will be tied to specific media. For example there might be a way to get a channel corresponding to a cable (#739) or a way to get a channel corresponding to your antenna, or a channel corresponding to shouting into the air. Each channel value will keep track of what the criteria are for being able to use it successfully (e.g. you must still be sitting on top of the corresponding I/O cable).
  • However, perhaps there would be some device that would provide a newChannel : cmd (chan t) command.
• There will be some dynamic type checking going on under the hood, so if you get a channel for a cable with type chan int, and another robot gets a channel for the same cable with type chan bool, neither of you will be able to hear the other --- you only get messages with the type you expect.
• There is only a send : chan t -> t -> cmd unit function which will make the value available on the channel in the next tick. If you want to send for multiple ticks you can easily program your own function to call send repeatedly.
• There is only a primitive non-blocking read which listens for a value for a single tick.
  • If you aren't listening to a channel at the exact time a message is broadcast, you won't hear it.
  • If you are expecting the wrong type, you won't hear anything.
  • You can easily program your own readBlocking : chan t -> t -> cmd t which simply calls read in a loop until it gets a value.
• You can build asynchronous communication on top of this by e.g. programming a robot to listen to a channel continuously, remember whatever it hears, and then respond to requests for information later.

[byorgey]

I'm upgrading this from Nice to have to Moderate --- it seems to keep coming up! I think this is probably one of the first things we should tackle after the alpha release.

[byorgey]

We should also put a bit of thought into propagation delay: the time it takes for a broadcast message to reach a listener can be proportional to the distance.

[xsebek]

I'm upgrading this from Nice to have to Moderate --- it seems to keep coming up! I think this is probably one of the first things we should tackle after the alpha release.

@byorgey shall I pin this then? :slightly_smiling_face:

[xsebek]

We should also put a bit of thought into propagation delay: the time it takes for a broadcast message to reach a listener can be proportional to the distance.

I just realized that if you send a robot to walk away, then we would have to store all messages that the robot could possibly have access to by the time they reach it. That could easily be more than 10000 if you have a lot of robots broadcasting a lot of messages.

[byorgey]

Yeah, that gets complicated. For the sake of argument, what if we just limit the broadcast radius but have instantaneous propagation within that radius? And for I/O cables what if we just allow instantaneous transmission for any distance? That is "un-physical", of course, but is there any way it would mess up the game or make things inconsistent?

[xsebek]

Well, if the signal propagation was by tiles, then it might be manageable.

^{EDIT2: Also that means we could store messages keyed by time, channel and tile.}

We could discard the message once it reaches the most distant known tile. If we ignore teleport, we can even precompute when will it definitely reach that tile, because the most distant robot can only move so far after you send the message.

^{EDIT: even simpler: take the diameter of known area in tiles, add that value divided by the length of a tile and add 1. After that time all sent messages can be safely discarded.}

EDIT3: Or to get the best of both worlds, we could have a broadcast radius of a few tiles and a speed of 1 tile per tick.

I am all for cables being instantaneous, that will at least keep them useful. :+1: