To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 167
166  |  168
Subject: 
Re: legOS Network Protocol
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Tue, 20 Apr 1999 19:37:08 GMT
Viewed: 
1375 times
  
Mike Moran:
The interface is specifically datagram only. Dunno about packet reassembly;
I doubt it as the philosophy is minimalism. The main advantage I see in it
is the ability to change the degree of checking it does on your behalf to
ensure packets arrive. Btw, it may help to know that it was originally
designed to allow things like remote debugging of hardware devices ie lots
of short commands with the occasional memory dump.

Yes this will be a datagram only protocol for the time being.  The LNP will
allow us to do things like debugging and remote control.  I have also
invisioned something like a "shell" running on the legOS that you could
either "telnet" in to or use a GUI interface to (ie: NQC Explorer).

On a separate note, what are peoples thoughts on the low-level wireline
protocol? I ask because I want to know how it would be effected by, in a
given
room, some robots talking via the legoOS native protocol, some using the • lego
VM protocol, and some just using the IR as a sensor for proximity detection?
I
would expect the IR-as-proximity-sensor traffic to be particularly bad since
it
may be on all the time, deliberately trying to flood the region with light.
Maybe I'm bieng stupid, would this be a problem?


In a room where peple are flooding (IR Proximity-Sesor) or transmitting RCX
protocol there will be a lose of transmition reliability.  Just as with any
other physical netowrking device.  If someone is not playing the game
correctly it ain't gunna work.  The solution to this is don't play with them!
The other is to get them to agree to a stratagy of collosion avoidance.
Don't transmit if you are recieving.  If you are blocked on recieving and it
comes clear, wait some random time then try to transmit.  Very crude
collision avoidance algorithm, but I doubt that the RCX VM can even impilment
it.  So your best bet is to use this protocal to talk to legos withing your
own group that are also using LNP to perform a task.

And finally.... Can legOS be set up in "simulation mode" ie running on a PC
as
if it was on the RCX? This would make doing the networking code a lot easier
as
all the stuff above the hardware layer could be designed and tested
separately.
A simple (controllable and repeatable) simulation of the network including
latency and connectivity would make *everything* a lot easier. Even if it's
not
possible I can still probably set up a self-contained box around my impl.


There really is not simulation code out there.  If you could find a hitache-
vm you could probably do it.  good luck....

-Jake



Message has 1 Reply:
  Re: legOS Network Protocol
 
(...) Assuming packets without large internal gaps, we could employ a timeout to wait for a packet transmission of unknown protocol type to end. At 2400 bps with 8E1 (LEGO, isn't it?), one data byte has 11 bits, so a space of 1.5*11/2400 s should be (...) (26 years ago, 20-Apr-99, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: legOS Network Protocol
 
(...) The interface is specifically datagram only. Dunno about packet reassembly; I doubt it as the philosophy is minimalism. The main advantage I see in it is the ability to change the degree of checking it does on your behalf to ensure packets (...) (26 years ago, 20-Apr-99, to lugnet.robotics.rcx.legos)

13 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