Newsgroups: comp.robotics
Path: brunix!sgiblab!darwin.sura.net!news-feed-2.peachnet.edu!concert!sas!mozart.unx.sas.com!sasrer
From: sasrer@unx.sas.com (Rodney Radford)
Subject: Re: a robotics building kit.
Sender: news@unx.sas.com (Noter of Newsworthy Events)
Message-ID: <sasrer.755207682@cinnamon>
Date: Mon, 6 Dec 1993 19:54:42 GMT
References: <1993Dec6.191152.22567@zeus.franklin.edu>
Nntp-Posting-Host: cinnamon.unx.sas.com
Organization: SAS Institute Inc.
Lines: 66

Great idea - in fact it is very similar to an idea that we are working on
in our robotics club - Triangle Amatuer Robotics club.  Our 'cards' are
going to be connected via I2C similar to what you describe, but we decided
to carry it one step more and use the ACCESS.bus software protocol to
talk to each of the various peripheral cards. We can still connect 'dumb' I2C
devices, but it also allows for smarter cards to have more control over the
communication.

Our design consists of 4 wires to each board - two for the I2C signals, and
two for light-duty power (if the board requires alot of power, it should
get it directly from one of the other supply lines).  One of the biggest
problems you will face is capacitive loading on the I2C lines, and noise
(especially if the I2C parts are not isolated from the motor supply lines).

We are beginning our design by first building an LCD panel (for status
info, etc), an A/D and D/A module, simple digital interface, and some
motor control circuits (ranging from simple open-loop PWM to fancier closed
loop systems).  The main controller for the system will be a 386sx33 that
was choosen to allow easy software development on home PCs (plus at only
$100 it is a cheap solution). The software design will be similar to that
discussed in the Circuit Cellar Ink series Firmware Furnace (written by
Ed Nisley who has recently joined our club).

The biggest disadvantage of ACCESS.bus to us is the relatively large amount
of code space overhead required in each peripheral. The source code we have
now for the 8051 style microcontroller requires about 1500 bytes.

I would also recommend you look at some of the 8051 derivative controllers as
many have some I2C hardware builtin.  The advantage is that the controllers 
can have a simple mainloop doing a specific task - with interrupt routines to
control data going in/out of the I2C lines - no need to continually poll them.

BTW - if anyone in the Raleigh, NC area is reading this and would like to
attend a meeting of TAR (Triangle Amatuer Robotics) please let me know. We
meet the first Monday of each month at 7:30pm on NCSU campus (110 Clarke Labs).
We are always looking for new members....!

wallace@zeus.franklin.edu (Steve Wallace) writes:

>  ok...im looking into building a Robotics construction set and making it
>available on the net. I've decided to do this because it was something i
>wish  had been available when i was learning.

> So far i suspect it will be broken up into a series of small I/O stamps.
>Things such as a 8 bit PWM card with encoders (3-6 outputs) and a I/O
>card with 10-18 opticly isolated bidirctional I/O lines also thers a
>possiblilty of a SONAR ranging modual or CCD camera modual.

> Each card is on a I2 C bus thats goes to a interpreter. the interpreter
>program memory is expandable in 16K increments up to 128K . im currently
>working on expanding the language model to handle up to 8 seperate
>processors wich are all linked to a 16k memory modual for I/O remaping

>  Ok so please Email me any thoughts on my idea. sugestions for I/O 
>cards will be appreciated and any Flames are welcome alsowhat languages
>would you like to have implemented..so far i plan to implemant a New 
>language since the interpreter needs to fit in about 2k. all this work 
>has grown from my experiances of designing with microchips 16C5X series
>of microprossers.

--
---
Rodney Radford          || Computer Graphics/Imaging
sasrer@unx.sas.com      || SAS Institute, Inc.
(919) 677-8000 x7703    || Cary, NC  27513

