For the Swarm Robot Project I need a unique ID to identify each single robot and also let the robot only execute program parts which are assigned to it's ID.
Why I wanna do that?
As we are planning to reprogram all the robots at once via IR we need a way to "place" an unique ID into the robot. This should happen without much additional stuff like an external DIP switch. To write that ID into the program code would not work since all the robots are receiving the same code. So we need a kind of internal identifier which µC the robot has and create/use this as an ID.
Here some suggestions from the SB:
FrankNeon: something like "I've been on the longest, I am 1." I'me next on, I'm 2...
FrankNeon: what about writing a startup void that has each bot find its place in line.
This would be a good idea but it also has a flaw. What happens when the robot is switched off for a reason...after switching it on again it will get another ID -> so the robot can not execute the code he is supposed to run.
Chris the Carpenter: Well, that one is easy --just do your own mac address for each bot and stick it in the eeprom of the chip during programming
That seems to be doable.
What's your suggestion? And no, we don't want to put more hardware on the robot just for this!
If the startup void has an argument to verify the total populace of the array then a “lost” bot can follow the hierarchy to find a gap in the line. It would need to communicate with other bots to find its place.
Maybe the swarm can help out by including the status of the array, Through repeated transmission, one robot can report the entire swarm status.
Example: Two robots meet, one having been turned off.
“I am #8, 1234568.” Lost 'bot: “Thanks! I’m #7. 12345678”
2. No, the plan is to equip them with different tools to perform different tasks. right now it’s just an IR shield and a light seeker shield available until we got the final board running and put it in a 3D printed case.
3. No that’s not the case. Ok, many robots will have the same hardware butn there will be others with different tools and functionality.
With different tools and job sets, each type of bot would need to have its own set of arguments in order to define its role in the swarm, and they’d all need arguments included that wouldn’t necessarily ever involve them either, in order to pass commands to those who could fulfill them. Tell a bot what type of tool it has, and it finds its place in that array, then starts to fill jobs. It there are three types of tools or attachments, then there would be three arrays of robots in one swarm.
If they all have the same code, some to use themselves, and more to pass to other types in the swarm, then they can still operate with some semblance of simplicity and remember what they are.
I got your point Frank, but it’s the deatil what matters. You wrote “Tell a bot what type of tool it has”. Exactly this is what I want to achieve. Telling the bot who he is by assigning a unique ID. Thus, to tell the bot his name I need a procedure.
We thought about this too but then you have to prepare each robot with a different resistor array. Hard to “mass produce” when you want to build a swarm and you are limited to a certain number I guess.
Another idea was a DIP switch to set the ID manually…but this involves more hardware what we want to avoid.
From Wikipedia: “GUIDs generated from random numbers contain 6 fixed bits saying they are random and 122 random bits, the total number of unique such GUIDs is 2122 or 5.3×1036. This number is so large that the probability of the same number being generated randomly twice is negligible.”
Useful for a 64 bit machine perhaps but not an 8 bit micro. How many processor cycles will it take to process a number that big? I would go the opposite end and fit it in an 8 bit number just number robot 1 = 1 robot 2 =2 up to 255. If you want more than 255 robots in the swarm then 16 bits should do. Oh and hi rik why don’t I see you around as much anymore?
Random number + EEPROM == random ID A decent random number generator can be made with a reverse biased diode (google hardware random number generator and you can probably find a simple circuit)
You can test if this is the units first power on, by checking its EEPROM for invalid data (ie CRC the first 8 bytes)
If it is, use the hardware random number generator to generate the unique id. Write it to EEPROM along with its CRC and you’re set.
Of course you may encounter collisions and you’ll never know what the id is chosen, unless you can query your micro controller
Thanks for your suggestion. We do not want to add more hardware for this, so we need to find a way with the given situation. I guess using the timer to create an unique ID is a good way to go.
Could you not use Frank’s method, but with a twist. In the EEPROM, if the number is blank, then find it’s number by hierarchy and store in EEPROM. This means if the robot is switched off then the number is still retained by the EEPROM so when switched back on the number is present. Alternatively store two numbers - Robot number and highest number already used. Then interogate any swarm that are on and if required update the highest number as well on switch on.
