Large RF robot network

Question

A friend of mine asked me to help with thinking about a solution to create a RF communication between 8 robots and 1 access point. Not a lot of traffic, just to signal that the robot is (almost) at the end of his track and get some control information. once per few minutes. This is not very complicated and I was thinking about the nRF24L01+ chip with external antenna. We need a range of approx. 100 - 150 meter. LOS

the complex part is the following: it is used in a field with solar panels, and we need about 4000 robots and 4000/8 = 500 access points. The addresses of all the units needs to be unique but each access point needs to know the addresses of his own robots. (and these robots has to know the address of their access point)

I was thinking about a silicon ID (32bit) and use a kind of pairing during start-up. So all the units have address 0 during start-up, and after pressing a button on the Tx, he will send a message with his unique ID. The Rx will store that ID into EEPROM or SRAM. The Rx will answer a message with his own address and the Tx will store that one into his SRAM.

the cons. are that you'll have to "pair" 4000 units.... the pros. are that you have 500 "independent" networks.

Anybody can give me other/better solutions? Or some suggestions to my current idea? maybe use xbee instead of generic RF radio chip?

Thanks in advance.

Regards,

Jasper

Answer 1

A friend of mine asked me to help with thinking about a solution ...

and that solution is the subject of Petri nets.

I guess your main concern expressed in the question is not how to manage the semi-autonomous units (SAUS), but to identify them. Therefore, my mentioning Petri nets is of low value to this question, but would be of overall high value to your friend.

Unique ID database algorithm
You should already be aware that disbursing unique IDs is a frequent but non-trivial concern in normal information systems function.

In a multi-process environment. It requires locking the increment counter each time a new ID is requested and registered, if you are using an off-the-shelf database management system. If you are writing your own algorithm, you would need to lock-down the code block that performs the disbursement of unique IDs into a synchronized atomic block of code, to allow only one process to execute it at any one time.

Hard-wired vs soft-coded -IDs

1. You could hard-wire its ID into each unit and then manually register it into the database. And you have to track the increment. But you would still need to inform the hub that a unit is coming online, and assigning a SAU to a hub.

2. You could hard-wire each unit with an unique ID, and then the hub would assign the hard-id a soft-id.

Why reinvent the wheel?

There is already off-the-shelf embedded/controller boards that does all these and many much more. They are called

• Linux micro-computers like the infamous raspberry-pi
• IEEE 802.11
• IEEE 802.11 hubs and routers
• Internet protocol
• DHCP

All these technologies embedded into a Linux embedded microcomputer board (like the raspberry pi). A wireless router/hub would DHCP an address to each unit embedded with IEEE 802.11 embedded controller.

Long range IP

But 802.11 is specified to work within 100 metres. 800, 2.5 and 5 GHz are microwave RF spectrum that require line-of-sight connection. That would

There are various strategies to overcome the range

• Use a GSM or telephony-embedded/enabled controller and subscribe each unit with the phone company. This is the field of telematics.

• Use a long-range directional mother-hub, with a arrays of antennae beaming into local hubs which can also act as repeaters to connect to yet farther hubs. https://en.wikipedia.org/wiki/Long-range_Wi-Fi.

  Effectively, that would be setting up your own mini-telephony network.

I want to say that the industry practice is Telematics for long-ranged connectivity (because I used to work for a telematics company connecting cars across the US). A well-known telephony company that also engages in telematics is Verizon.

But if your SAUs do not travel more that a 100 metres away from the hub (or using extender/repeater hubs for 200 - 300 metre connectivity),

your solution would be

• an IEEE-802.11 hub with a telephony modem. Only the telephony-enabled modem needs to subscribe to the phone company. Each SAU is DHCP'd to a hub.

I have a little write-up on NAT and DHCP: https://stackoverflow.com/questions/1982222/how-do-two-computers-connect-to-same-external-address-through-nat/1985181#1985181.

You can speak to Verizon (or AT&T, Orange. T-Mobile ) on using telematics modem with their networks.

A single mother-ship

Another solution is, if your operation can be designed such that updates need to be performed only every 1 - 10 minutes, depending on the vastness of your solar array field, you could have a single telematically enabled mother-ship or rover, that roves to exchange information with each hub its passes by.

But hey, if updates are necessary only hourly, your rover needs to return to base once every hour, without even needing telematic connectivity. For redundancy and quality reasons, you certainly should have more than one rover.

However, I think that telephony-enabled hubs (like a data-plan enabled android/iphone) DHCP'ing each SAU is the most effective way.