Closed mbonani closed 5 years ago
I think this might be a good idea. A 128-bit UUID might be overkill. I don't know whether IEEE 802.15.4 provides a MAC address.
What are the use cases?
Here is what I do in asebahttp when I have several robots connected together. (Asebahttp is now a switch like asebaswitch.) The HTTP interface exposes:
id
that uniquely identifies the node on the bus. Initially it is the Aseba target id but I remap them in case of conflicts.asebaId
that identifies the node id in the AESL program. This is the role that the node plays in the network of nodes. It might not be unique.name
that comes from Dashel. It is typically not unique.Is the goal to distinguish robots that are connected in the same room, or is it to identify them anywhere in the world? Do you want the id to be fixed, or reprogrammable? In the reprogrammable case, is it enough to have a variable loaded from the SD card?
I am the original author of this wish ;-)
As far as I know, IEEE 802.15.4 does provide a MAC address. For me the use case is to identify a robot specifically, for instance within augmented reality if we provide tablet-based odometry calibration. Or in the context of some "big data" approach. So I would say the id should be fixed and global.
So, I guess a version 5 UUID according to RFC 4122, that you would generate from a namespace? If you used the URL namespace with mobsya.org then optionally you could offer a brokering service.
Actually robots sold recently do have a unique number and a corresponding barcode. As a first step, this number should be available in a variable within the Thymio. I suggest _serialNumber
.
@mbonani do you have a specific number of digits planned for the number printed under the Thymio? (so that we can estimate the size of the array necessary for the serial number) Are these numbers unique over classical and wireless Thymios?
actually the used system i so: a letter for the production batch. A B C D etc... we are actually at J and a number afterwards that go from 0 to 3000. But in the past we didn't reset the number so from A to D the production number still increase and go up to 11000-12000 if I remember, then there is also some very old thymio without any number. So having better serial number is possible, but has to be more investigated. The number are unique over Wireless and classical.
Would it be too wasteful to derive a 128-bit UUID from the name (which could be model number, serial, production date)? Because that would give strong guarantees about uniqueness.
a letter for the production batch. A B C D etc... we are actually at J and a number afterwards that go from 0 to 3000.
How are the letters encoded in the bar code? How much space is there in the bar code?
But in the past we didn't reset the number so from A to D the production number still increase and go up to 11000-12000 if I remember, then there is also some very old thymio without any number. So having better serial number is possible, but has to be more investigated.
It is important that while investigating, we do not repeat numbers.
Would it be too wasteful to derive a 128-bit UUID from the name (which could be model number, serial, production date)? Because that would give strong guarantees about uniqueness.
There is still the problem of what information is put into the bar code and in the firmware, which are probably both the lowest storage available. I think that having a unique number across all types of Thymio is important.
As an upper bound, a 29x29 ECC M QR code can store the 60 characters of an URI with a 128-bit version 5 RFC 4122 UUID of the form
http://my.thymio.org/id/xxxxxxxx-xxxx-5xxx-1xxx-xxxxxxxxxxxx
Since version 5 is a SHA1 hash of a namespace identifier and name, one could store a shorter name in the robot and rely on the hashing function to fill it out to a UUID.
Whether or not the identifier is a UUID, the advantage of putting the complete URI in the QR code is that:
done in commit 1ef26b8
Have an unique ID like MAC adress exposed in aseba. Specially for wireless Thymio