Subject:
|
Re: Brainstorms GUID
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 01:17:26 GMT
|
Viewed:
|
643 times
|
| |
|
|
In lugnet.robotics, Bruce Boyes <bboyes@systronix.com> writes:
> At 05:47 AM 8/12/2002 +0000, Wayne Gramlich wrote:
> > All:
> >
> > I'm not sure I really understand what point is trying to be
> > made. I thought that a globably unique id was a good idea
> > and put them into RoboBricks. My choice was to use a 128-bit
> > random number. There are other solutions. All of the other
> > solutions mentioned would also work. My solution uses 16
> > words of program memory out of 1K words in a part that costs
> > $1.01 (US) in quantities of 25 from DigiKey. It was the
> > solution I adopted.
>
> Maybe I completely missed the point myself?
>
> I like your idea of intelligence so small it can fit into a brick, and then
> tie into upper levels of higher intelligence. That sounds like true
> distributed processing (a good thing) to me.
That's what we thought as well.
> Here's the issue I was addressing:
>
> How do you guarantee that two vendors won't produce the same 128-bit
> pseudo-random number? If they use the same algorithm they will produce the
> same series of "random" but not unique numbers, unless you can guarantee
> that they use different seeds. Thirty two bits would give you four billion
> numbers, I'm wondering why you chose 128.
If you use a pseudo random number generator with the same seed you
will get the same `random' number. The obvious answer is don't do
that.
I personally use the /dev/random device on Linux which collects
entropy (i.e. randomness) from disk seek times, times between keystrokes,
network packet arrival times, etc. It may not be a true random number
generator, but it is done well enough that there is no real chance that
a 128-bit string will ever repeat. The /dev/urandom generator is faster
because it is a pseudo random number generator that uses /dev/random
for the seed. I actually use /dev/random to get the best random bits
I can find. I think both would work quite well.
The next issue is why did I choose 128 bits. Frankly, I choose 128
because the number was so huge, I didn't think very many people would
argue that there was any realistic chance of a collision. 64 bits
would have been good enough, but the cost of allocating 8 additional
bytes made it 2^128 which is probabaly more than the estimated number
of particles in the known universe. (I actually don't know it is,
but it should be pretty close.)
> Also the 128-bit number doesn't tell you anything about the function of
> that node. If you are stringing 16 nodes in an arm for example, how do you
> write the code to control it? Now what if you have 10 such arms? Now you
> have 160 random numbers but what do they mean? You could have an index
> somewhere and try to maintain it but why not keep the information in the
> node itself?
I thought about having a "write to EEPROM" mode, but it seemed like
more effort than it was really worth. Also, some of the chips I use
don't have EEPROM (i.e. the PIC16C505). The id string does identify
the RoboBrick flavor, but does not distinguish between several chips
of the same flavor plugged into it. I figure that people will be
swapping boards around enough that storing the information in the
board won't work all that well in practice either. I could be wrong
on this one.
> On our JCX system we have 24 to 32 SPI chip selects per backplane, each
> with an EEPROM tagging memory which holds the function, serial number, etc
> of the device at that chip select. You can have one code base applied to a
> number of robots. At startup the code scans the backplane, finds what
> resources are available and then knows what to do. There's space to add
> your own info too. For example in our 8-input passive/active sensor board
> you can label that group of sensors or any individual sensor. As you say,
> the little memories are inexpensive, and easy to talk to, without added
> logic - just I/O pins and a bit of code.
I'd never heard of the JCX system until you mentioned it above.
I found it via Google with no extra effort though. I read the site
until the tiny font made my eyes bleary; my eyes aren't what
they used to be. ;-)
Using the SPI bus seems like a much better choice than the I2C
bus for this application.
> We came up with this scheme because some users have - for example - a swarm
> lab with say 20-30 robots, almost identical, but with possible differences.
> They don't want to maintain 30 sets of firmware with hard-coded parameters.
>
> At least that's the theory. We will be building and testing this hardware
> starting in Sep.
Sounds like fun. For us, software development was always the gating
item. It is always fun when we can start working on real hardware.
Later,
-Wayne
|
|
Message is in Reply To:
 | | Re: Brainstorms GUID
|
| (...) Maybe I completely missed the point myself? I like your idea of intelligence so small it can fit into a brick, and then tie into upper levels of higher intelligence. That sounds like true distributed processing (a good thing) to me. Here's the (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
53 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
