To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 18653
18652  |  18654
Subject: 
Re: Brainstorms
Newsgroups: 
lugnet.robotics
Date: 
Sun, 11 Aug 2002 20:21:48 GMT
Original-From: 
Steve Baker <sjbaker1@#StopSpam#airmail.net>
Reply-To: 
sjbaker1@airmail.net+AntiSpam+
Viewed: 
818 times
  
Xanthra47 wrote:

That said, I'd like for BrainStorms to be backward compatible with Technic,
Mindstorms, and Spybotics.  Most people aren't going to embrace new tech
unless the new stuff can "leverage their legacy platforms."  (Yes, I've been
in meetings with IBM consultants all week)

So I imagine the need for a brainstorm brick that has a standard Lego wire
connection on the top and a little I2C chip inside that would interface with
existing motors and sensors.  This would certainly be needed because nobody
wants to butcher their Mindstorms stuff - and we don't want to have to make
Lego compatible motors.

The ugly thing though is that a brick that could work with both sensors and
motors would be hard to do - so you probably need two of them - one for motors
and one for sensors.

As for compatibility the other way (ie making brainstorms stuff work with RCX),
I honestly wouldn't bother.  The RCX is the thing we are trying to improve on
and any effort to interface back to it is going to be messy.

So how do we use I2C and still interoperate with Mindstorms, etc. ?  We need
a IAB (interface adapter brick) that converts the IR communications to I2C
signals.

I think that's a standard I2C part.  I2C is used in things like TV sets so IR
comms are a frequently needed part.

Whether it's going to be easy to implement iRDA - I don't know - I'd hope so.

I envision having several types of IABs (Interface Adapter Bricks) :
1.  An IR to I2C IAB
        Yes.

2.  A VLL to I2C IAB
        Maybe.

3.  A motor IAB
        For sure.

3.  A passive Sensor IAB
4.  An active Sensor IAB
        Maybe those can be the same thing?
        But for *new* sensors that we might come up with,
        I'd expect the I2C to be built right into the sensor.

5.  A serial EEPROM IAB
        Yes.

6.  A USB to I2C IAB
        Dunno how hard that is - but if we do it then we can use
        it to connect the IR brick to a PC...so we only need one
        IR brick type.

7.  An RC servo IAB
         Yes.

8.  A pneumatic valve IAB
        Dunno - isn't it easier to use an RC servo for this?

I'd add:

   9.  A microprocessor.
  10.  A RAM expansion.
  11.  A battery pack with sensing logic for short cicuits, overloads, overheating,
       etc.  This should also have temperature and voltage sensors readable via I2C
       (that's a single I2C chip!)
  12.  Depending on how the power is transmitted - if it's in the same cable
       bundle as the I2C - then there needs to be an I2C-to-I2C connector that
       DOESN'T transmit power across it.  You need this to safely add multiple
       battery packs.
  13.  Some way to make noises - there are sound chips for I2C - but we'd also need
       a teeny-tiny speaker or something.

John B. and others mentioned the need to identify nodes on a distributed
network and I've got an idea about how to do that...

Isn't that already a part of the I2C specification?

: We design every I2C
capable module or IAB with a connector that allows one to attach a NIB (Node
ID Brick) to it.  The NIB could have an eeprom in it to store it's NID (Node
ID) or even have a bunch of dip switches on it so one could change it's NID
as needed.  Either way, changing the NID of an I2C node would be as simple
as swapping NIBs.
The guys with the 3-axis CNC did a nice job of engraving text for the name
tags at Brickfest, and I think that'd be a professional way to mark NIBs for
quick visual identification. IE simply engrave the NID on the side of the
NIB.

But that makes all of these dinky little 2x4 stud devices *MUCH* larger and more
complex.  Do we really need this?

I'd like most 'bricks' to be single I2C devices with a simple connector for power
and I2C - plus whatever is their function.

For interconnections between modules, I'd suggest we stay with the 9V plates
and leads that LEGO(R) makes now for most things.  I know they're not the
cheapest, but they're easy to use and easy to mark using different color
tiles.  People have already found creative ways of making homebrew
conenctors that are compatible with them so price might no be an issue
anyway.  I think we can send I2C signals through them with no problems and
we're already accustomed to using them for either power or data.   Custom
rotary connectors with slip rings would be a godsend, though !   I'm working
on an adapter to convert LEGO(R) wires to RC battery pack connectors.

I'm not sure that gives us the connection density we need.  We need:

    Power
    Ground
    I2C SDA
    I2C SCL

...but I2C is a bus, so you need:

   SDA ------+----------------+---------------+----------------
   SCL ------|--+-------------|--+------------|--+-------------
             |  |             |  |            |  |
             |  |             |  |            |  |
            BRICK 1          BRICK 2         BRICK 3

Now - do we have cables that T off connections for each brick:

   SDA ------+---------
   SCL ------|--+------
             |  |
             X  X
             |  |
            BRICK 1

(The 'X' is a connector pin.)

Or do we have bricks with two extra connections:

   SDA ------+     +------
   SCL ------|--+  |  +---
             |  |  |  |
             X  X  X  X
             |  |  |  |
             +-----+  |
             |  |     |
             |  +-----+
             |  |
            BRICK 1

....so that there is an "In" and an "Out" connection and the cables
are daisy-chained and are small and modular.

    The discussion so far has centered on electronics and communications
methods, but I think BrainStorms should extend LEGO(R) in the mechanical
sense as well.

I think it would be wise to make that a separate discussion.

The electronics update does not rely on the mechanical change - and vice/versa.

You stand a better chance of getting one to happen if you don't try to fight
both battles at the same time.

----------------------------- 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
 
Steve, Thanks for the quick feed back : ) Please take a look below ... & LMKWYT. -JSM Steve Baker <lego-robotics@crynwr.com> wrote in message news:3D56C75C.403000...ail.net... (...) I was thinking that it could be used to hook up to joysticks, (...) (22 years ago, 11-Aug-02, to lugnet.robotics)

Message is in Reply To:
  Re: Brainstorms
 
OK, I've been watching this thread for a few days (I am LUCNY's "Expert Lurker" after all !) and refining some ideas that I've had for a while in hopes that I can contibute to this dicussion in a useful way. Please keep in mind that I'm a Mechanical (...) (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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR