Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 11 Aug 2002 20:29:48 GMT
|
Viewed:
|
946 times
|
| |
|
|
In lugnet.robotics, sjbaker1@airmail.net writes:
> 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.
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 obtain. The PIC16C7x chips
had I2C, but only came in 28-pin skinny DIP's. Even today,
Microchip *still* only has I2C support in their high end chips,
which cost 5-7 times more than their low end chips. The Atmel
chips are more readily available, though. I do expect I2C
support to keep migrating down the food chain, but it is no where
near as ubiquitous as UART's are in microcontrollers.
I2C is a multi-drop bus that requires proper termination. As
an electrical engineer, I understand this issue. Try to think
of the support nightmare of dealing with calls from confused
people who do not understand why their robot is unreliable
because of a missing termination.
My biggest problem with I2C is addressing. Each device needs
needs to have its address pins properly set. The 10 bit
(2^10=1024 total) address space means that many dissimilar
devices have address conflicts. The only way I can see to
work around these issues is to front end every device with
a dedicated microcontroller. I still do not see a way to
reliably assign a a unique address to each microcontroller
on the I2C bus. It seems quite likely that people will
accidentally get the same device programmed with the same
I2C address and I2C bus chaos will ensue.
I suspect somebody who is sufficiently motivated can figure
all these I2C issues out. At the time I started RoboBricks,
I2C did not look like the way Bill and I wanted to go.
Having said all of that, the PIC876Hub10 board is capable
of talking both I2C and to 8 RoboBricks at the same time.
It is still up to the end user to figure out the addressing
issues with I2C. If you accidently download the same address
I2C address into two different PIC's, I2C bus confusion will
ensue.
> > 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.
RoboBricks is a hub and spoke design. There is no reason why a
RoboBrick master can't be sending and receiving multiple messages
at the same time. To date we haven't needed to do that, but the
architecture definitely supports it. The PIC876Hub8 RoboBrick
module we designed sure has enough horsepower to talk to 8
RoboBricks at the same time.
> Whilst I can imagine a lot of things you could do with 2400 baud links
> that would work just fine, ...
We concluded that we could build just about every robot that we wanted
to build using the architecture. Our model is to build robots together
via sub-systems. For an anthropomorphic robot, we might have one
processor controlling each finger, another for the hand, another for
each arm, another for the whole upper torso, etc. Our expectation
is that the major subsystems would talk via a faster serial port
speed than 2400 baud, say 115.2kbps.
> ... 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.
I think you are seriously overrating what I2C can do. There is no
realistic way you can plug 1024 devices into a single bus without
overloading the bus. There are line length and capacitance issues
that will stop you long before you exhaust the 1024 device space.
It makes much more sense to plug a dozen or so sensors and actuators
into a module and chain those modules together in a tree-like fashion.
Not all levels of the system have to use the same bus. Our thoughts
are that as you got closer to the central behavior processor,
that the buses could get faster (and more expensive.) Thus,
the leaf sensors and actuators would be talking at a slower
speed, but the sub-system processors could be using a faster
bus, like I2C, USB, Ethernet, or Firewire.
> > 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.
[snip other interesting stuff]
All I was trying to get at is that the human neurons are not
particularly swift in the speed department.
----
In summary, there are pros and cons with both I2C and
serial communications protocols. We hedged our bets by
designing a module called the PIC876Hub10 that can talk 2400
baud to the slave modules and 400kpbs I2C and 115.2kbps serial
to higher level modules. It can also talk the SPI protocol.
My last comment is that I doubt that any one bus will come
to dominate robot sensor/actuator nets. Similar cases that
you made for I2C can be made for SPI, USB, Firewire, 10MBit
Ethernet 100MBit Ethernet, CAN bus, 1-wire Dallas bus, etc.
What really matters is having somebody take the time, figure
it all out, and get it all working.
My $.02,
-Wayne
|
|
Message has 1 Reply:
 | | Re: Brainstorms
|
| (...) Are you sure? I thought Philips had teeny-tiny microprocessors with I2C at least 10 years ago...before the I2C bus switched speeds from 100kbps to 400kbps. I2C is about 20 years old. (...) Address pins? What address pins? ---...--- Steve Baker (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Brainstorms
|
| (...) <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 (...) (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
|
|
|
|
