Bluetooth multi-robot application: two approaches
Here is a silly, swarming type application using Bluetooth and 4 robots. One robot, the master, is used to relay messages and occasionally send out a message at random. The other 3 robots, the drones go until they hit something, then back up in a turning motion, stop, send a message to the next drone, and waits to be told to go.
More precisely, drone1 starts going forward with the happy face displayed. When the touch sensor, set up in the standard configuration with a bumper, is tripped, this robot backs up slowly, sends a go message to the master to be relayed to drone2, and then waits. The display holds the text WAITING.
Drone2 starts in the waiting stage. When it receives a go message, it starts, now displaying a happy face. When it hits something, it backs up slowly, sends a go message to the master to be relayed to drone3 and then waits, displaying WAITING.
Drone3 acts the same as drone2, except that it sends a message to the master to be relayed to drone1.
The master runs the masterecho relay code (written by Brian Davis when I was having difficulties). This uses the incoming mailboxes to signal what connection to use to forward (so to speak) messages from the slaves. So a message send my drone1 over its 0 connection, therefore to the master, to mailbox 2, gets forwarded by the master over its connection 2.
Because sooner or later, all the robots stopped, presumably because messages were getting lost, and also because I wanted to add some random feature, I added a parallel thread to the master's program. In this thread, the following code is in a loop: there is a wait for 2 seconds. The dice block is used to return a random number between 1 and 100. If it is under some threshold, say 10, implemented by the compare block and the switch, then the dice block is used again to give 1, 2, or 3. This connection is used by the master to send a go message. The sound block is used to 'say' start and the connection selected is displayed.
Drone1
Drone2
Drone3
Masterechoplus:
A second approach, suggested by Sivan Toledo, makes use of just one mailbox. The messages must be numbers 0 to 9 (though the method could be modified for higher numbers such as readings from the rotation sensor). A message of 5 to be forwarded to connection 1 is sent as 15; a message of 3 to connection 2 is 23, etc. This appears to be more reliable, but more testing is needed to confirm. This does not have a random element.
The master acting as hub, runs this program, making use of a MyBlock
The MyBlock decodnum:
The first drone (goes and then sends out message):
The second and third drone are similar:
A variant, still using the number encoding approach, is to put a random element in the program running on the hub and just to make it a little more complex, the message number is multiplied by 10 to be the input to the power.
The program running on the hub: note that in the second (lower) of the parallel threads, the dice block is used twice: one to determine if any message is to be sent, and one to determine the connection (which slave). The first dice has range from 0 to 100. The comparison is to 10, meaning that one tenth of the time there will be what I term an extra message.
The first slave runs this program:
Notice that the power variable is initialized to 50 and then is reset using 10 times the numeric message.
The programs running on the other two slaves are similar: both waiting before moving.
And