What wireless technology to use to control robots in classroom?

Question

I want to build a cheap robot programmable in Scratch graphical language, that could be employed during lessons in school. Scratch code is interpreted on a PC, so on the robot there should be only the code that receives specific commands (i.e. drive forward) and transmits sensors' measurements.

I'm looking for a wireless technology that will allow me to exchange information between robot and PC with at least 30Hz rate. It should also allow to work at least 16 robots simultaneously in the same room and have a range of at least 20m.

I did tests with BLuetooth, but sometimes there are connectivity issues, and pairing devices can be a hassle in a classroom. I have also tried WiFi modules, but pinging it showed average time of 19ms, but maximum of more than 500ms, so I'm afraid that it won't be able to control linefollower robot for example.

Can you point me to some other, preferably cheap (under 10$ per module) wireless technologies? Or maybe my worries about WiFi are exaggerated?

Answer 1

There is a product from Pololu called the Wixel. In a classroom environment, when one of them transmits a signal all of the others will receive the message. The radio interconnections between the wixels are essentially just like serial communications.

It wouldn't be too much work to bash together a protocol that can either 'broadcast' to all devices in the room, or 'target' a specific device by including its id in the message. You'd have to program the Wixel's so that when it receives a non-broadcast message that isn't coded to its own ID, it simply ignores the message.

They are around $20 each or less if bought in bulk.

In fact with a setup like this, the wixels could actually pair up if you want one controller per bot. Even with short bursts of comms there is a possibility of data collision when two signals go out simultaneously. In those situations you could look into how such issues are handled in other technologies, such as ethernet, for example.

If you go this route, you might also want to investigate the I2C protocol which also allows numerous devices to communicate all on a common bus. The main difference there though would be that they have a CLK sync line which they can all monitor in order to decide if its their turn to talk or not. There will be no sync line to use over the air. That's where data collisions come in to play. The I2C protocol is really simple and can be learned pretty quickly. I think the same concepts could be applied.

You can also tell the Wixel to talk on a different channel. Up to 128 apparently, so you could have a fairly decent number of paired devices.

Answer 2

Unfortunately I don't have enough rep to comment or I would do that instead of a full blown answer.

I think Rf modules would be the way to go in this situation, I have played around with this trans/recv pair before and had pretty good results, however I don't think the range would quite be enough for your setup.

With regards to you mentioning 16 robots communicating at the same time, I would suggest using some kind of "call sign" system, where each message you transmit could be pre-fixed with a letter, or a number to ensure the correct messages are sent to the correct robots and vice versa. If the message does not contain the robots unique call sign, discard message, if it does, process.

You could alternatively have each robot transmitting on a different frequency, however I don't know how well this would work, and you would have to get a variable frequency RF module.

Sounds interesting though! Good luck