Need to discuss communication specs (Rasps <-> Robot)

[nbelin]

The robot should be able to send "match begins" / how many robots are on the table / "match ends" to the Rasps. The robot can be a client OR a server of BigBrother => to discuss The robot may want raw information from Cameras (pixel-level), or high-level information (x,y on the table). BigBrother could implement an HTTP server, cOAP... Etc.

[Elioty]

Since the cup WiFi environment would (will certainly...) be overcrowded and for performance's matters, I think we should use two UDP/IP multicast channels:

• one for robots-to-bigbrother commands (234.0.0.1:4242)
• one for bigborther-to-robots period positioning data (234.0.0.2:4242)

I chose to differentiate the two channels on their IP instead of their UDP port so the packets are discarded earlier in the network stack of each systems on the network.

On the robots-to-bigbrother channel, commands should be:

• game starts (spammed until ACK is received)
• game ends (spammed until ACK is received) Any other idea? For now we can just transmit one byte on that channel.

On the bigbrother-to-robots channel, messages should be either:

• "game starts" ACK (sent each time "game starts" command is received in case the ACK was lost)
• "game ends" ACK (sent each time "game ends" command is received in case the ACK was lost)
• 4 times the tuples (x, y, detection accuracy/radius of trust)

Multicast use-case example in Python: http://stackoverflow.com/questions/603852/multicast-in-python Should be easily translatable to C/C++.

Any ideas/thoughts?

[nbelin]

Let's start with something simple: Main robot sends "GO [0|1] [0]? [1]? [2]? [3]?" when game starts. The first [0|1] corresponds to the color of the team (ie. side on the table). Then, the robot sends the list of the robots present on the table (ie. the robots which BigBrother will have to detect). For example: "GO 1 0 2" means "game starts, we are on side "1", and you must detect the robots "0" and "2". At least one robot must be specified (the main robot). Indeed, the other team could have no robot for some obscure reason (disqualified...).

There is no need for a "game ends" message. BigBrother can shutdown itself properly after about 100 seconds.

[nbelin]

During a game, BigBrother can send messages like: "(R[0-3] \<x> \<y> \<accuracy radius>){1,4}" With the first [0-3] is the ID of the detected robot, \<x> and \<y> are the position of the robot in mm, and \<accuracy radius> is the precision of the position, also in mm. \<x>, \<y> and \<accuracy radius> are all ASCII integers. We have today no need for sub-mm accuracy (and cannot be achieved anyway). For example: "R0 -90 150 10 R2 130 20 5" which means: Robot "0" is at (-90, 150) with 10mm max of error, robot "2" is at (130, 20) with 5mm max of error.

[nbelin]

Messages will be sent in binary. For example, "GO" may be "0x7", etc. The list of markers to detect will be merged into one flag 1 to F.

When a robot is detected, integers will also be sent in binary (as signed short, 2 bytes)