Go vertical, man!
bobr_
Posts: 17
I've got spaces to search, collisions to avoid, routes to place,
trucks to deliver cola, matches to make, and voxells to scan for wind shear -
No wonder I have no time !
For the last few weeks (well years) I have been thinking about some actually
massively parallel problems and the kinds of things I'd need to solve them.
At $600 for only six workable compute cells on a PS3, the cost and power consumption
(never mind space) are self limiting.
Sure there's distributed 'puting. That has its own problems. *
I'm already into distributed folding of alien radio signals to see if any of them
are gonna make it here for genetically enhanced tea before the sun goes red giant.
I've also got a screen saver for an LCD screen - but
it's not there to save the phosphor from burning!
It's there to save my sanity.
But I have been thinking even more so in the last few weeks about trying again
because I chanced to visit the Parallax site -
I was going there to see if a cheapie Stamp (lots of them)
could do what I wanted... (drumroll)
Then I came upon the propeller (cymbal) LOL
Could this be it?
I did many hours of analysis, deskpadded a lot of things
(including my head when I got overwhelmed thinking about it).
Didn't know anyone else had considered adding in a large model
besides me. Good - somebody got that. Ahh! some sram, (hx512k)
too bad it really is only random access for the low 64k, oh well,
I can fix that and make swapout pages for the large memory model...
just move a declaration around and poof - 2K 'pages' all equally accessible. done.
Next problem.
Then I see the thread on supercomputing... humm, thats me. Time to stop lurking.
... and so I'm wondering... are they really stackable?
everyone is going to say "in theory, yes".
I want to /see/ it.
Ok - So here is my challenge:
It's more mechanical than anything else...
I would like to see a 'stack' of Propeller chips,
perhaps just enough air between them for venting. Go vertical, man!
I want the inter-chip parts count to be low or nothing.
Tie as many pins together as you safely can.
I don't care which package type you use
(stacked dips with only a few pins lifted out, for instance)
or if you have to make a special mini-rack
to hold them spaced evenly apart...
(LQFP comes to mind being spring-held by its own pins at the edges)
What I don't want is flat. This has to be extendable
indefinitely in the vertical dimension. Ok so maybe you need a
dedicated high powered clock to drive all those pins...
maybe not. Lets hear why & why not.
For comms and enumeration:
A diode or a pullup in the right place to daisy chain them,
or maybe 'Z' staggered on 2 of the pins will be enough.
(like a carry on an adder)
Circle the staggered Z back to the front and you have a token ring with
(any) one a potential writer and N simultaneous readers --
Ok now I can put content-addressable-memory among the things in my solution bag.
"OOH! Will the real answer to this raise its hand?? First cog to match - raise your pin." LOL
Now those problems are fun to solve again.
What if you only needed one pin to enumerate at bootup?
What if reset of one was tied to an IO pin on the next?? -
and when each processor is done booting it reads the common
data bus and adds one to it - then takes the next device
in the chain out of reset - just some wild out of the box thinking
to liberate a pin.
IO IO -cant afford the PTO (what?)
I'm not looking for a lot of IO. (at first)
And NONE of the chips should 'specialize'.
The cogs don't, why should your design?
That would only introduce a weak single point of failure.
Been there.
Actual IO may be later and will only need
to be via a 2G USB, SDmem card or picotux on a couple of the levels.
(points if USB|sdmem|hx512k|picotux can be detected automatically)
(points if you can plug any device at any level).
In a pinch, IM ok with inserting
a local-master every so many levels which
has more pins for IO and fewer for comms.
(got to have someplace to the hx512Ks to hang
if this is gonna do swapouts) - by the way, think quick,
which is faster - a long message through the hub or
passing it via an hx512k?? ***
Spoon Feeding vs Sipping a Fire Hose
I have to consider this - the main bottle neck back in my day -
the 'problem' cray had - was how to keep the beast busy. Folks had to
put multiple traditional mainframes on it to feed it crunchworthy stuff
fast enough (and those mainframes internally had feeders).
So just like the way the tech's solved it with that box, I'm
expecting to 'feed' my personal nano-crunch-berry-beast from multiple points.
Serial comms is out. Pfft. I want that pin back for other comms.
Everybody gets the same thing from the nearest
hx512k eeprom(or equivalent). Every so often and perhaps
at the ends, is a picotux or $50 DigiConnect ME (5 IO lines available)
so that real (read that non eeprom) data can fill the
'solver rope' from multiple points.
Form factor?
I'll probably shape it myself for the one I use personally.
I kinda fancy the shape of a cane with square sides...
or a wizard staff.
Cane length - 36 inches(35840Mips ** ).
Staff length - 71680 Mips LOL
Be creative. I really only need to see a few stacked
to get the idea. I've got a heat glue gun ready. LOL
Ok, an epoxy tube.
Power?
Batteries.
It only has to run for 5 minutes at first.
Of course, I want more - but stick with handheld
and off-the-shelf cheap parts please.
I want it extensible because
I'm doing this with my own lunch money
one skipped meal at a time.
-bobR_
foot notes:
wait - notes is plural, this should be feet notes
* Note that the problems I selected have a wee bit of /urgency/ to them.
Most of the distributed/folding applications out there have to contend
with users dropping off line or turning off their computer. You cant scan for tornadoes
in a hurricane when it's convenient. Same goes for keeping airplanes in the air...
they cant just pull over for gas. And on the ground - soda delivery trucks follow a planned
route to drop off 'more syrup' that takes 25 hours to plan from the previous days' stocking levels.
** regarding the original post ...
It would seem one cog is needed in each to dedicate to communication, that lowers the
total available cogs to 448 in a 64 chip set...I've recalculated the Mips ratios accordingly.
Now a 12.5% hit is a lot for comms, but it is a nice place to put a tiny OS, perhaps a good place for those
spending effort thinking up a large model OS supervisor, and in this case - hypervisor.
*** On the other hand, if swapping programs via the hx512k is actually faster
than going through the hub (*** above) and
the internal chaining of the IO with gates in between can protect accessing
then go ahead - share the hx512K as directly as possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
trucks to deliver cola, matches to make, and voxells to scan for wind shear -
No wonder I have no time !
For the last few weeks (well years) I have been thinking about some actually
massively parallel problems and the kinds of things I'd need to solve them.
At $600 for only six workable compute cells on a PS3, the cost and power consumption
(never mind space) are self limiting.
Sure there's distributed 'puting. That has its own problems. *
I'm already into distributed folding of alien radio signals to see if any of them
are gonna make it here for genetically enhanced tea before the sun goes red giant.
I've also got a screen saver for an LCD screen - but
it's not there to save the phosphor from burning!
It's there to save my sanity.
But I have been thinking even more so in the last few weeks about trying again
because I chanced to visit the Parallax site -
I was going there to see if a cheapie Stamp (lots of them)
could do what I wanted... (drumroll)
Then I came upon the propeller (cymbal) LOL
Could this be it?
I did many hours of analysis, deskpadded a lot of things
(including my head when I got overwhelmed thinking about it).
Didn't know anyone else had considered adding in a large model
besides me. Good - somebody got that. Ahh! some sram, (hx512k)
too bad it really is only random access for the low 64k, oh well,
I can fix that and make swapout pages for the large memory model...
just move a declaration around and poof - 2K 'pages' all equally accessible. done.
Next problem.
Then I see the thread on supercomputing... humm, thats me. Time to stop lurking.
... and so I'm wondering... are they really stackable?
everyone is going to say "in theory, yes".
I want to /see/ it.
Ok - So here is my challenge:
It's more mechanical than anything else...
I would like to see a 'stack' of Propeller chips,
perhaps just enough air between them for venting. Go vertical, man!
I want the inter-chip parts count to be low or nothing.
Tie as many pins together as you safely can.
I don't care which package type you use
(stacked dips with only a few pins lifted out, for instance)
or if you have to make a special mini-rack
to hold them spaced evenly apart...
(LQFP comes to mind being spring-held by its own pins at the edges)
What I don't want is flat. This has to be extendable
indefinitely in the vertical dimension. Ok so maybe you need a
dedicated high powered clock to drive all those pins...
maybe not. Lets hear why & why not.
For comms and enumeration:
A diode or a pullup in the right place to daisy chain them,
or maybe 'Z' staggered on 2 of the pins will be enough.
(like a carry on an adder)
Circle the staggered Z back to the front and you have a token ring with
(any) one a potential writer and N simultaneous readers --
Ok now I can put content-addressable-memory among the things in my solution bag.
"OOH! Will the real answer to this raise its hand?? First cog to match - raise your pin." LOL
Now those problems are fun to solve again.
What if you only needed one pin to enumerate at bootup?
What if reset of one was tied to an IO pin on the next?? -
and when each processor is done booting it reads the common
data bus and adds one to it - then takes the next device
in the chain out of reset - just some wild out of the box thinking
to liberate a pin.
IO IO -cant afford the PTO (what?)
I'm not looking for a lot of IO. (at first)
And NONE of the chips should 'specialize'.
The cogs don't, why should your design?
That would only introduce a weak single point of failure.
Been there.
Actual IO may be later and will only need
to be via a 2G USB, SDmem card or picotux on a couple of the levels.
(points if USB|sdmem|hx512k|picotux can be detected automatically)
(points if you can plug any device at any level).
In a pinch, IM ok with inserting
a local-master every so many levels which
has more pins for IO and fewer for comms.
(got to have someplace to the hx512Ks to hang
if this is gonna do swapouts) - by the way, think quick,
which is faster - a long message through the hub or
passing it via an hx512k?? ***
Spoon Feeding vs Sipping a Fire Hose
I have to consider this - the main bottle neck back in my day -
the 'problem' cray had - was how to keep the beast busy. Folks had to
put multiple traditional mainframes on it to feed it crunchworthy stuff
fast enough (and those mainframes internally had feeders).
So just like the way the tech's solved it with that box, I'm
expecting to 'feed' my personal nano-crunch-berry-beast from multiple points.
Serial comms is out. Pfft. I want that pin back for other comms.
Everybody gets the same thing from the nearest
hx512k eeprom(or equivalent). Every so often and perhaps
at the ends, is a picotux or $50 DigiConnect ME (5 IO lines available)
so that real (read that non eeprom) data can fill the
'solver rope' from multiple points.
Form factor?
I'll probably shape it myself for the one I use personally.
I kinda fancy the shape of a cane with square sides...
or a wizard staff.
Cane length - 36 inches(35840Mips ** ).
Staff length - 71680 Mips LOL
Be creative. I really only need to see a few stacked
to get the idea. I've got a heat glue gun ready. LOL
Ok, an epoxy tube.
Power?
Batteries.
It only has to run for 5 minutes at first.
Of course, I want more - but stick with handheld
and off-the-shelf cheap parts please.
I want it extensible because
I'm doing this with my own lunch money
one skipped meal at a time.
-bobR_
foot notes:
wait - notes is plural, this should be feet notes
* Note that the problems I selected have a wee bit of /urgency/ to them.
Most of the distributed/folding applications out there have to contend
with users dropping off line or turning off their computer. You cant scan for tornadoes
in a hurricane when it's convenient. Same goes for keeping airplanes in the air...
they cant just pull over for gas. And on the ground - soda delivery trucks follow a planned
route to drop off 'more syrup' that takes 25 hours to plan from the previous days' stocking levels.
** regarding the original post ...
It would seem one cog is needed in each to dedicate to communication, that lowers the
total available cogs to 448 in a 64 chip set...I've recalculated the Mips ratios accordingly.
Now a 12.5% hit is a lot for comms, but it is a nice place to put a tiny OS, perhaps a good place for those
spending effort thinking up a large model OS supervisor, and in this case - hypervisor.
*** On the other hand, if swapping programs via the hx512k is actually faster
than going through the hub (*** above) and
the internal chaining of the IO with gates in between can protect accessing
then go ahead - share the hx512K as directly as possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Comments
That's some wish list,have 1 prop as a dedicated SRAM controller
are you sure serial comms aint fast enough??
Looks like a bandwidth problem,which exactly the trouble they had
with CRAY XMP's
Best Regards
Ian
:- The future aint what it used to be.
We used to stack Sram on the PDP 11/23 and 11/44 pulling the
chip selects out to a spare gate.
Don't think it's feasible with LQFP
:- An attic is where you store all the junk, you'd throw away if
you didn't have one.
My two obstacles:
(1) The prop is not really build to work as parallel chips; due to missing hard- and software support you have first to invent and implement a stable protocol. I posted my basic requirements in one of the regular threads coming up with this topic from time to time.
(2) The cost/perfomance ratio is not good. You will do much better with
- either a true parallel chip (64 high end processors mesh connected on a chip)
- a thousend low cost chips as AVR or even SX
Also: power dissipation is a most important consideration in all parallel architectures, so it is unlikely we can neglect it.
Nice list, different problems.
"collisions to avoid"
gets interesting when "they" turn the transponders off. I have some ideas about this particular gestalt.
Sid has gone a long way and he is almost there. You should talk to him. He has quality and capacity.
http://forums.parallax.com/forums/default.aspx?f=25&m=165060
Rich
But anything can be done if you throw enough at it
RTX2000 and Harris!!
But point taken it's not designed to be Parallel chip
and you'd have more sucess even with old tech like T450's
Best Regards To All
Ian
Chips' original post indicated "768 spare I/O pins" and I presume that was
spread out evenly over all 64 chips. This division amounts to 20 pins for
bootup and inter-chip comms. 12 for hanging 'local' devices off the 'spare' IOs
(like an hx512k or sdram or a temperature sensor or picotux). 12 is plenty.
Keep in mind that unless you have a 'roving' OS, once a Prop chip
discovers a local device is attached, its probably best to leave a cog attending to that
device and take it out of the 'working-set' till next reset.
Note: roving-OS is an advanced topic I will cover in a
different thread when you all think you are ready. LOL
If we "ignore" the top IO 4 pins because they are part of bootup. That leaves 16 for interchip.
Not many, but better than serial.
Most humans in the 'puter biz think in multiples of eight now.
I remember when they didn't!
yes - I too worked on PDP and even older dinosaurs -- I cant go to the computer museum
cause my other half is afraid I'll bring home what the museum throws out.
Now the question is - can we steal-back some of those "Ignored" pins and use them for other signaling
or enumeration?
Can we consider that the ignored/bootup pins are part of the local device set (getting all 4 back)
and have every Prop connected to every other by both row and column busses with 4 for protocol?
I think YES.
I do think we kinda have to relegate the boot up pins to be
in the local device set because a standard hx512k needs
to see the same eeprom boot pins. (3 out of 4 of them anyway).
You are talking to someone who responds to 'infeasable' challenges by coming up with the
most astonishing out of the box thinking possible. Yesterday at work
I showed some amazed folks that there is a second way to get clean windows
when "it costs too much to hire window cleaner folk".
(hint)
visionary
The idea I envisioned was to make it possible to use raw LQFPs
literally stacked in a carrier on 2 or 3 sides. the carrier has simple wire rows
matching most of the LQFP pins(on end). Perhaps evenly spaced rows of pin-holes
or a cutout which was plated-through.
Besides, I wouldn't want those at home with a single Prop nailed
to a protoboard
to miss out on the fun. protoboards stack too!
I disagree about not designed to be parallel. Are not all internal cogs in parallel?
Isn't it a simple Nand/Nor/And/Or combo that connects em? Would it help to
do that same thing on the outside? Now can you do that a different way if
you pre-agree to operate the pins using a certain protocol? If they are synced up,
what if two get the idea to write (different patterns) on the same clock cycle?
I still don't see an answer to my original question. Please.
Its a fair one and posturing doesn't answer with a way to get it done.
Work with me here. I'm asking for your help... I don't do that often.
How many pins /can/ we truly wire-or together among how many Prop chips
without a dedicated master (single point of failure)?
How many will need a safety resistor for contention (or a pullup?)?
Will a diode break or 'fix' a contention?
If we have an X and a Y buss, can we get away with only one or two
external components (resistor or diode) per bus?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Not sure I understand the entire issue, but I think you can just wire any two pins straight together, there is diode protection built in. As to how many pins you can wire to the same pin on a different Prop... dunoh.
There are a lot of experts here, but they don't all speak the same language and the diversity of backgrounds is rather impressive. How about a couple of simple drawings to illustrate the questions?
Rich
What I think is that many persons have tried the obvious approach to add-up Props - and abolished it after some time.
It would be worth to analyse the reasons... I only know mine....
My conclusion at the moment is:
Protocol first, architecture later!
Would luv to see it working
Too many folk saying it can't be done.me included
Best Regards
Ian
Yes thats the internal connection. Replicating this externally is more difficult though. A pull-down on the shared pins with prop pins being either output high or input would be the simplest way to do this. (aka just like I2C but inverted) 2-pins and an n-input OR gate would also work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
The things that make the propeller tick are however:
- time slotted "main memory" allocation of Processors (limited to at most 16, I should say, and under heavy criticism of bandwidth mis-use)
- fast semaphores ("LOCK")
- simple loading of a COG from any place of the "main memory"
Please provide these features to whatever connected multiple Chips, and I shall be very happy. First step must be to define the "main memory model". Sum of all HUB memory?
now in the process of typing it back in a few more 'ideas' took hold:
the architecture (memory description actually comes nearly /last/)
- there are no master-masters
well its a goal anyway. no single point of failure.
just multiple entrypoints for data and exitpoints for results.
- Props self-enumerate
(means they each know initially only their own identity and
how many Props there are total)
They also can 'discover' the addition of secondary storage on their own.
- there are 20 wires which make up a dynamically splittable 'broadcasting' bus
which can be taken as:
4, 4 Bit busses (4 masters communicating at once=4x4)
2, 8 bit busses (2 masters, twice the speed of the 4x4)
1, 16 bit bus (single master)
8, I2C busses (8 masters - not critical but allowable)
- of the 20 wires, 4 are used to indicate mastering and allocation..
since channels are not dedicated to tasks, a wire break may disable that bus/mode
but not the entire system. It may be actually /desired/ to have intentional breaks
between whole busses at points to permit more masters to coexist in the array as a whole.
(see bridging below)
- collision detection on the 4 8 or 16 bit wide busses
is the same as that for I2C except no limit to
number of master devices
- bridging
A bus break can be bridged using non-broadcasting IO pins to a cog
on the other side of the break. Redundant bridging is encouraged.
Standard rules apply to cancel reflections
if a duplicate msg arrives with the same originating timestamp.
- memory /is/ totally 'fractured'
(thats not necessarily a bad thing). Props with sram
can 'help' the others that are memory starved but it is far from being a linear
address space. It /will/ support a large model as described in forums here.
Memories even larger than sram/hx512k can also be interfaced as well as disk
and these simply appear as larger containers within which one places
cloned copies of objects. Even the ram in a PC can become part of the memory
space available to a large model multi-prop computer.
- Kernel support for objects and large model programs(methods).
The distributed kernel will support events, objects and methods that are run completely
in parallel. You may have many more objects than you have available cogs.
SRAMs positioned here and there, act as swap space for cogs and as cache for
containers and streams. Persistent containers can self-save to the medium they came from
(eeprom or SDcard or USBstick or other) at will.
- events
The kernel will support event 'listeners' which can monitor state changes in parallel objects.
(yes you can have multiple objects with the same name in different Props)
Objects/containers can clone and be renamed - they can even change their type.
They can also be relocated to a less busy cog or Prop if they become urgent.
Objects withing each Prop will define what to do when memory is full and swapouts
are desired.
- modeling
For scientific applications, it will be possible to have millions of small multi-byte entities
that can be affected by neighbors - speed is affected by how much parallel hardware
you add in multiple dimensions. If a message is directed at an object, all sharing
that id or handle list will be worked on eventually by one or more cogs.
Fat trees are also supported by the model as are wave-mode propagation centers.
Given dynamic choices in bus speeds, overtake models
for message propagation can also be simulated with real hardware.
As in Javascript, all objects are both [noparse][[/noparse]indexable] and .fieldable to get at methods or contained
sub-objects. This is supported in the memory allocator/kernel not just in the compiler.
Default getter and setter methods are used when any cog outside the current owning
cog tries to read or write to a field or index.
The concept of content-addressable memory actually extends into the distributed kernel.
When you have lots of spare parallel processors one can divvy up name-to-index lookups for example.
You can search lists from two directions. You can do collision detection in hardware!
"everybody within 12 meters of 40North and 45East send me a message"
One can ask for things like "make me a list of all Props holding/minding at least one 'raindrop' object"
and everybody might answer... or nobody. The days of handling
a single scalar answer are gone.
One can also say "accelerate all raindrops one cm2 downward".
More complicated things like
"if your temperature becomes 32, change into a snowflake falling slower" and
"spin yourself if any neighbor is going slower than you" and
"bow in the direction of spin" and
"add to static charge if your direction opposite the neighbor" and
"change your location (find new neighbors)"
and the protocol??? do we send "" strings all over??
no.
The above examples are in English - its not the actual protocol.
I speak C, perl, python, ruby, rebol, tcl, javascript, bash, [noparse][[/noparse]b|g]make even a little
parrot these days as part of my day job.
The protocol will make a lot more sense once you see what kinds
of broadcasts are possible on the N way bus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Engineers in my circles would call it "unvalidated requirements" rather than "architecture"
However very inspiring!!
Post Edited (deSilva) : 10/3/2007 8:01:54 AM GMT
Nutson
Has anyone considered using the base band TV out for getting the answer out to the real world? Might be OK for code cracking type stuff. Provide each propeller with the same program and a random number (some random process on a pin) use this to make each propeller try for a solution in a slightly different way when one finds a solution it shouts BINGO via RF.
Graham
a scalable multi-Prop is suited.
I'll start with one I have been kicking around at lunch.
I live (now) in an area of the US where BattleBots originated.
Chief complaint about that show was that it
was mostly driver cunning that won the fights.
Real engineers lost interest because it did not actually promote real AI.
What if it did?
It was mentioned on the Parallax web pages
that a Prop in a robot won a competition
where the second place was an i386/Linux based solution.
Ok so thats one Prop.
Is there software written that is designed to control robots
which could benefit from a many*many cpu+mem+IO
(multi-Prop) solution?
The answer is YES and I am not its author but he is right here.
I am a fan of subsumption for robotics control.
Richard (ImageCraft) wrote a subsumption library in C
a very long time ago. I was there.
Its tiny - and it uses a ton of message passing using software.
Many, many small routines which actually could be expressed in parallel.
The library makes it possible for you to build complicated things yourself.
Once the core is running, you get to write 'behaviors'.
Simple things like "when (hungry) { urgent_msg(search_for_wall_socket);}"
What if inexpensive and simple hardware could achieve the same thing
which is scalable at low power drain?
I'd like to be able to say: "humm, if we only had 2 more Props in the stack
we could have room for the extra behaviors to give Ripley an arm
and articulation control."
... more later. lunch is coming up. LOL
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Post Edited (bobr_) : 10/5/2007 4:13:37 AM GMT
The robot we were going to leave with the computer museum in Boston
was acting very strangely. It would move slightly forward, stop, move
some more... then proceed for a while then go back to being "hesitant".
It was based on an RC car with the radio control replaced
with a microprocessor board. It had an ultrasonic range finder to
locate objects (and scan for tunnels - the folks at ImageCraft can tell you
the significance of scanning for tunnels ). It also used the range finder to
verify if it was 'stuck' instead of counting wheel revolutions. A novel approach.
Most people in robotics will confirm that connector failure
is probably the most common reason for a robot to fail.
It turned out that this robot had 'adapted' on its own
to a blind-spot in its ultrasonic-vision caused by connector failure.
... a break when the range finder was swiveled a certain way.
It made up for it by moving a bit and changing the angle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Please stop laughing at people's ideas. You do this a lot and it's really irritating.
It's a multi-cultural forum here and there will always be misunderstandings and potential confusion with idioms which are not our own. I know I've misinterpreted deSilva and others, they may have misunderstood me. The best thing is to just roll with it or ask "how so ?" to elicit further clarity.
But what "double entendre" in Fred's post? I'm not seeing it.
that·would be just mean or deSilva or something.
But back to the thread, with a limited number of tools (weapons), you need to work smarter. It has seemed to me that robot sensor schemes all oversample, and that in a perfect world they could get along just fine with fewer probes. And alternatively, that in an imperfect world what the hell would happen if a bad guy (me) put an extra beep in your ultrasound scan, your ir distance scan? What if I wack your hardwire collision switch? Why stop with just a beep, how about a doppler tone that rises -- "I'm getting closer, closer, I'm here (NOT! I'm behind you &·gonna smack your puny butt)"?
Maybe instead of double entendre, sleight of hand or misdirection (that's precisely my thought) may have·been·meant.
Graham
Since one side is usually accepted as risque -
I got an image of robots rolling on the floor [noparse][[/noparse]wrestling].
Oh well, go vertical was a weak double entendre' on my part.
Ok, so I figured that, on a robot, connector failure is
such a common problem, maybe it should be addressed
at as many, perhaps every level that we can.
So:
- no single point of failure. (I have to keep coming back to this one)
- redundant broadcasting busses in the 20 pins used for a backbone [noparse][[/noparse]more on this coming up]
- minimal component count between Props (less stuff to break or get a cold solder joint)
- bridging (for breaks in the backbone or maybe at joints)
- reflection canceling (by time stamping the origin of a broadcast)
- any cog in any Prop
Now there are some subtleties in my spec:
- Devices can be hooked on anyplace (Props dont specialize)
- Props near a device auto-detect the device (for example a USB drive)
Now I never assumed in my spec there would only be a single USB drive.
Nor did I assume that they would appear separately (perhaps they are redundant).
If the drives were self-named several could answer to the same name
and you have a raid.
-- Not all robots are destined for earthbound duty --
Since one could hang a self-identifying USB drive at several points on the backbone
there would be minimized risk of something (like a micro-meteorite) disabling the entire raid array.
yes - back to the no single point of failure thing again.
Taken further:
With w,x,y and z (the 4x4bit busses I mentioned) the buss wiring would be spread out both
on lattitude and longitude lines of the sphere, cylinder or capsule... on a spiral too - it could
even be embedded in the skin of the craft - as well as radially in a harness.
Thats survivability - and its cheap.
It used to be true that only NASA eyebrows would shoot up at such a concept.
Now with things like the google challenge - private industry is giving designs
like this a go.
And what happens when you send a query out to get a block from
two drives with the same name and they both answer?
Then they had better answer the same thing. (which is what you want with raid)
Actually with the I2C protocol, as soon as 2 masters send a bit which they
don't immediately read back as what they sent - the one not getting what
it set stops sending and waits for a stop. That idea generalizes to nibbles, bytes
words and any other scalar type. I am counting on this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Post Edited (bobr_) : 10/6/2007 6:04:09 AM GMT
I think this is how DARPA startet in 1960 whith what later came out as ethernet based internet
What I am interested in is an implementation of:
- XCOGNEW which will load any of the thousends of COGs from any of the hundred Props
- XLOCK which will assur safe locking between the thousend COGs
- XREAD, XWRITE which will read or write some (1 to 16) LONGs from/to any of the thousend HUBs