Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 11 Aug 2002 13:09:38 GMT
|
Original-From:
|
Steve Baker <SJBAKER1@AIRMAIL.nomorespamNET>
|
Reply-To:
|
SJBAKER1@AIRMAIL.saynotospamNET
|
Viewed:
|
936 times
|
| |
|
|
Wayne Gramlich wrote:
> Everything is a compromise. Here is a discussion of the issues
> that caused us to pick 2400 baud for RoboBricks:
<snipped some reasonable arguments>
This is why I recommend that 'brainstorms' goes with something like I2C.
That protocol is fast and built into the chip. No software serial I/O
is ever needed and every chip already speaks the protocol so there is
often no need to add a microprocessor at every node (although you undoubtedly
would add microprocessors into nodes that might benefit from some local
compute power).
I2C works at 400k bits per second and has zero software overhead,
it's been around in this form for 10 years and in a 100k bits/sec
version for another 10 years before that - so it's an extremely well
tried and tested solution.
If all the devices we are ever likely to need are already available
with I2C (and are VERY cheap BTW), why compromise?
Even if some obscure things we might one day think of don't come
with I2C, we could just slap a little 8 pin microprocessor and an
8 pin ROM onto that node to decode the I2C and drive whatever the
real device is.
> 3) Surprisingly enough, since the RoboBricks are doing all of
> the time critical stuff, the time latency introduced by
> communicating at a relatively slow 2400 baud is not very critcal.
I think that makes very large assumptions about what you want to do
with this stuff. I design large embedded computer systems for flight
simulators - and it's amazing how the traffic can add up when you want
to build complex machines.
240 characters per second is going to translate into a mere couple of
dozen messages per second - you only need a handful of devices sending
things to multiple nodes to swamp that bandwidth.
Whilst I can imagine a lot of things you could do with 2400 baud links
that would work just fine, I want to design a system with no unreasonable
built-in limits to scale. I want it to be like Lego bricks where someone
can take 100,000 2x4 bricks and build a life-size dinosaur. When someone
has plugged together 1024 brainstorms nodes (the maximum that I2C can
handle), there is 400 bits per second of bandwidth for every node (if they
all talk at once) - and that seems pretty reasonable.
> 5) I should mention that the neurons that we humans use are not
> particularly fast either. We seem to get along just fine
> with significant delays from remote sensors in our toes
> to our brain and back.
But the systems are hardly comparable. Each neuron has dozens of
inputs and each one does a truly miniscule amount of work. In the
brain, the amount of bandwidth scales better than linearly with
the number of neurons.
Also, the 'software' in your brain is horrible - it does things
that we humans are totally unaware of at the top level - but which
would be *disgusting* kludges to a software design for a robot.
For example:
* When you dart your eyes from one place to another, your
brain cannot process all the fast-moving data that results.
So your eyes are actually 'turned off' during the 'jump' in
position. However, all of those blackouts would be terribly
distracting - so some intermediate process 'fills in' the
blackouts with data from your memory.
* Latency between an incoming event and our reaction to it is
'edited out' by the brain so we are not aware of the delay
at a conscious level. All sorts of time-shifting is done to
disguise some of the problems that result from our slow comms
pathways.
This seems impossible to us as thinking beings but when we are
thinking about it, we are using the very organ that contains all
the kludges. It takes some quite subtle experiments to show that
these things are going on.
----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
http://prettypoly.sf.net http://freeglut.sf.net
http://toobular.sf.net http://lodestone.sf.net
|
|
Message has 1 Reply:
 | | Re: Brainstorms
|
| (...) The RoboBricks project was started 2-1/2 years ago. At that time, there were no readily available and 8-pin microcontrollers with built in I2C support. The Atmel tinyAVR series had some I2C support, but the chips were extremely difficult to (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Brainstorms
|
| Steve: Everything is a compromise. Here is a discussion of the issues that caused us to pick 2400 baud for RoboBricks: 1) Most of the various PIC's that we use (PIC12C509A, PIC12C672, PIC16C505) run at 4MHz. The 4MHz clock rate is divided by 4 to (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
53 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
