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 / 26204
26203  |  26205
Subject: 
Re: thoughts on gbc module reliability
Newsgroups: 
lugnet.robotics
Date: 
Thu, 6 Jul 2006 00:52:58 GMT
Viewed: 
5325 times
  
In lugnet.robotics, Rafe Donahue wrote:

So then there are shunts needed to allow some balls to go
to slow-land and some to return to fast-land, right?  Is
this where the train comes in?

   In *principle*, this is one reason to have the possibility of "splitter"
modules - you could take a 1 bps stream, and subdivide it into two streams with
lower rates (0.5 and 0.5 bps, or even things like 0.75 & 0.25 bps, are easy to
do mechanically). *BUT*, to do this you also need at least one module that can
recombine, and BOTH modules need to satisfy the minimum standard of 1 bps and
the specified input/output locations (with the possibility of others that can be
easily switched on or off). This isn't easy, but it is possible (I've modules
that satisfy both these constraints). But even these "odd" modules Follow The
Standard, so they can always be used in a normal way.
   As to using the train to fix a lot of this, keep in mind that the train as a
whole *also* has to adhere to the standard - that is, 1 bps minimum throughput
over time. It turns out, that can actually be a pretty strict constraint,
because the train has to stop, wait for a dump and reset, move, locate the next
station, wait for a loading, etc. This ends up influencing the size of the cars
as well as the number of the cars, and the number of stations that can be
serviced. Steve Hassenplug & I went through many rounds to try to get the twined
GBC trains functioning for the last BF.

I'm thinking this adds a certain level of complexity to the whole
organization process.

   Yes. For BF '05, the idea was four segments, some for reliable modules, and
some for less reliable or fault-prone ones. That way when a sector went down, by
a simple mechanical change at the loading/unloading stations, the entire sector
could be cut from the loop for repairs. It was a simple ingenous system, with a
huge amount of credit going to a train sensor idea that Steve had. And we both
worked very very hard at it. And still, it never did quite live up to our
standards. Stations had issues, multiple sectors sometimes failed at once, and
even then the train almost did not have the excess capacity needed at times. I'm
still not sure of a perfect solution.

The whole rate-limiting step theory seems to me to indicate
that unless every module follows the standard, we are going
to have a mess on our hands.

   Yes. Follow the standard. Follow the standard. Repeat after me... :-) Or if
you really feel you "have" to break it, make an assembly of modules such that
the complex as a whole follows the standard (essentially what Rafe did with his
"supermodule").

I learned my lesson: simple, simple, simple) either late Saturday

   Yeah, but always reach for the sky. After all, innovation is the fun part
:-). So while simple may always be reliable, there's something to be said for
complexity when it can make things interesting.

--
Brian Davis



Message has 2 Replies:
  Re: thoughts on gbc module reliability
 
(...) The idea of combining a number of small subunits, each of which work as desired (high reliability and throughput), can create complexity *with* reliability. That's the idea I will be unveiling in August. Bring an extra pair of socks for when (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
  Re: thoughts on gbc module reliability
 
(...) Plus, one of the train motors died, which required Steve to go to the LEGO store and buy the 4512 Cargo Train as a replacement. I also think the track was dirty and stopped conducting well, since by the end of the weekend the volunteers were (...) (18 years ago, 6-Jul-06, to lugnet.robotics)

Message is in Reply To:
  Re: thoughts on gbc module reliability
 
(...) So then there are shunts needed to allow some balls to go to slow-land and some to return to fast-land, right? Is this where the train comes in? I'm thinking this adds a certain level of complexity to the whole organization process. Of course, (...) (18 years ago, 5-Jul-06, to lugnet.robotics)

43 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