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@AIRMAILnospam.NET>
Reply-To: 
SJBAKER1@stopspammersAIRMAIL.NET
Viewed: 
2144 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, (...) (24 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 (...) (24 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
    

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