| |
In lugnet.robotics, Kekoa Proudfoot writes:
> Dave Baum <dbaum@spambgoneenteract.com> wrote:
> > I just haven't found a non-intrusive method for keeping the tower alive.
> > I hate transmitting garbage every few seconds and possibly trampling
> > incoming data.
>
> It seems to me that, given the current hardware, the choices are: send junk
> or let the tower go dead. My thinking is that if you send junk and trample
> something, so be it; the tower would have gone dead anyways, forcing you to
> lose whatever it was you wanted to receive if you hadn't kept the tower
> alive in the first place.
>
> Obviously new hardware (or a hardware hack) would be preferred, but short
> of these, what other choices are there?
I have given this some thought in the past, although I haven't had the
(significant!) time that it would take to try this out. I think the best hope
for any kind of two-way communication protocol between the PC and one or more
RCXes is to use a token-passing protocol. The PC would be the "master", and
would periodically send out token messages. This would keep the tower alive
and provide a rough clock to synchronize all other communication. All data
communication would be limited to only occur between the regularly-paced
tokens so that no data would get trampled.
When it receives a token, an RCX would have an opportunity to send a response
packet. The response could be directed (addressed) to the host PC or to
another RCX, or even broadcast to all listeners. Each RCX in IR range would
have a unique ID number (assigned manually if necessary) that would assign it
a time slot relative to the token. So when the token is received, RCX #1
would have a short time window (measured in units of "time required to
transmit N bytes of data @ 2400 baud?) during which to begin transmitting its
response. If the time period passes without any IR noise, then RCX #2 has a
chance to send a packet. This process continues until either (1) one of the
RCXes decides to send a packet, or (2) the total time window available (must
be less than 3 seconds!) passes without any packet being sent. At this point,
the PC sends the next token, and the process repeats.
If you're worried about the fact that RCX #1 will have a higher communication
priority than the others, a rotating priority scheme could be employed where
the token actually specifies which RCX may use the slot, or better still,
specifies which RCX gets first crack at using the slot. Also note that if a
slot is used for a packet, the next token can be transmitted immediately (no
need to wait for the end of 3 seconds!) so that the total number of packets
per unit time is not artificially limited if there are a lot of small packets
being sent around. In fact, if the total number of RCXes is known to be
fairly low, then tokens can be generated more frequently, as long as all known
RCXes have their own time slot in which to start transmitting a response
before the next token is sent. In other words, the PC might know after 1/2
second if none of the RCXes has a packet to send, so it could repeat an un-
answered token after 1/2 second. But if it starts seeing a packet, it waits
until the end of the packet (again, must be less than 3 seconds total) before
sending the next token. Techniques like these would maximize the effective
bandwidth and minimize the latency of this protocol.
Outgoing data packets from the PC could be preceded by a different token which
would indicate that the host is claiming the time slot. Alternatively, the PC
could be assigned its own unique ID number, and would follow the same rules as
an RCX for claiming a communication timeslot. But even when the PC is
transmitting, the total time slot must still be kept below 3 seconds in case
multiple PCs are participating and need to transmit their own tokens
periodically.
My point is that as long as all of the PCs that are involved get a chance to
send at least one byte every three seconds, it should be possible to use the
remaining air time for any "station" (PC or RCX) to talk. If messages must be
sent that would exceed the 3-second window, they must simply be broken up into
multiple packets and re-assembled on the other end before being processed.
This protocol would require that the total packet transmission time plus the
address-specific initial slot delay always be less than 3 seconds, or else the
tower will die before the whole packet had been received. But it should be
possible to support two-way communication between a PC and a handful of
RCXes. This scheme could be further modified to allow multiple PCs to
participate, but each PC would have to be able to send a token during every
three-second "frame" to keep them all alive. The total time window of 3
seconds is about the length of 720 data bytes at 2400 baud, (3 seconds * 2400
bits per sec / 10 bits per byte) which gives you a rough idea of the
theoretical maximum packet length. But depending on how many unique RCX and
PC IDs you want to support, you effectively shorten the available time window
by some small amount. Still, it should be easily possible to support a dozen
or more "talkers" with a generous maximum packet size of 128 bytes. (Larger
packet sizes start to get inefficient when there are communication errors
anyway, since an entire packet must be re-transmited if even a single byte of
it is rejected.)
Other enhancements would allow for any station to disable the protocol for a
short time period. For example, if an RCX needed to use its IR port to
perform a radar ping, it would send a "shut up for N seconds" request to the
host wrapped in a normal data packet. The host, in response, would send out a
special "everybody shut up for N seconds" token, during which time the RCX
that made the request would be allowed to transmit IR garbage to do its ping.
After the allotted time, everybody empties the cruft out of their receive
buffer and starts listening for packets again. The requested quiet interval
could even be longer than 3 seconds, since the PC will know when to start
sending tokens again even if its tower dies.
I can think of a few other sneaky ways to tweak this protocol in order to
support even more PCs and/or RCXes than might seem possible at first blush.
But if you could support, say, 4 PCs and 16 RCXes all talking to each other,
then you'd be off to a really good start!
Of course, this protocol would probably be completely incompatible with the
communication protocol built into the standard firmware. (You might be able
to get something like this to fly using the standard firmware, but the timing
would probably be MUCH more sloppy, which would severely limit the number of
RCXes that could participate and/or decrease the effective bandwidth of the
channel.)
There are a lot of possible variations on this scheme that I think could be
made to work. However, they all involve some pretty tight timing, and some
very creative solutions for problems like error detection or detecting the
presence of a second PC that comes online after the protocol has already been
started.
Unfortunately, I haven't had nearly enough time to put into this project, so I
have no code to share at this point. But it should be possible, and if anyone
would like to try to work on this, I'd be happy to share some more ideas.
|
|
Message is in Reply To:
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
