Subject:
|
Just Killed Another IR Tower
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 11 May 2001 19:01:51 GMT
|
Original-From:
|
Greg Frazier <GREGORY.FRAZIER@SAIC.spamcakeCOM>
|
Viewed:
|
802 times
|
| |
|
|
Hello -
I received two replacement IR towers in the mail last night and have
already killed one of them and am experiencing WEIRD behavior from the
other. So, I'm going to try to describe what I'm doing and see if you
all can provide some advice.
We have been developing a demonstration of an enterprise security
infrastructure. The robot is to be a physical manifestation of a
service. That is, when we run the demo and securely acquire a handle to
a service and then invoke methods against that service, the audience
gets to see the robot move. Ta-dah!
The robot is based on Baum's line-following tracked robot. It operates
on a grid that has been painted onto a plywood base. It has a single
light detector facing down to follow the lines (which are black) and to
detect intersections of the grid (which are blue). It also has two
light detectors facing forward and two IR micro-flashlights facing
forward. For the demonstration, cubes are placed on a couple of the
intersections, blocking them. A client application directs the robot to
move around the grid and then maps the blocked and unblocked
intersections.
The robot is programmed in nqc and the robot proxy and client are
written in Java. I developed a set of Java classes to support
communicating with the robot via messages (opcode 0xF7). The robot
understands seven commands: go fwd, go reverse, go left, go right, send
status and clear status. The robot receives a message, dispatches the
message to the task that moves the robot (if appropriate), and sends a
message back. The point to notice here is that the return message
follows close on the heals of the command received.
The package that I developed in Java for communicating with the robot is
based on the class that Sun wrote for JavaOne a couple of years ago.
Relevant features of this package:
The package handles all aspects of the Lego protocol. To send a
[one-byte] message, one invokes sendMessage(byte). To receive messages
from the robot, one provides an object that implements the
MessageListener interface and passes it to addListener(). The actual
interface with the serial port is handled by the Java comm [serial port
communications] package. There was some curious behavior that my system
consistantly exhibited which I have not seen described anywhere else in
the literature. When a message was sent out the serial port, the port
immediately received the same message. I assumed at the time that that
was simply a matter of the IR receiver detecting the IR transmissions -
i.e. the tower's receiver was NOT being turned off while the tower was
transmitting, so it naturally received the data that was being
transmitted. In response to this behavior, I created a dynamic filter.
Every time data was written to the serial port, it was also appended to
the filter. As data was read from the serial port, it was compared to
this filter. Data matching the filter was discarded. If the filter was
of non-zero length and data was received that did not match the filter,
then a FilterException was thrown. In other words, a FilterException
was thrown whenever the initial data received was not the same as the
data just transmitted.
The initial work on this project occurred last summer, concluding around
November. At that time, everything worked. FilterExceptions were never
seen (i.e. I *always* received the message transmitted). To the best of
my knowledge, no messages were dropped. It is possible that garbage was
occasionally being received, as it would be ignored by the thread that
was parsing packets in the buffer, but this was never noticed and to the
best of my knowledge never interfered with the robot's operation.
As has previously been discussed in this forum, I have since then
destroyed two IR towers - my own and the one being used for these
demonstrations here at work. I am fairly certain that I destroyed them
by plugging them into my new laptop - a Dell Latitude CPXJ (I'd
previously reported that it was a Dell Dimension) running Win2k.
Whether it is the hardware or the O/S that killed the towers is an open
question.
So, I received the two new IR towers in the mail last night and have
been testing them out today. For the first couple of hours, the work
was being done on a Dell Latitude CPXJ running WinNT. I believe that
I've killed that IR tower - more on that in a minute. The behavior of
the IR tower was immediately different from the behavior experience last
fall. First, in a call-and-response scenario (e.g. the IR tower sends a
message and the brick [immediately] responds), the tower fails to
receive either its own transmission or the brick's response. Instead,
the tower receives a stream of garbage. However, on subsequent
transmissions, *if* they are done within a few seconds of the first, the
tower both receives its own transmission and the brick's response. And
receptions only work if the brick's response is delayed about .15
seconds. This is behavior that was not seen before - previously, there
was no garbage ever received, and the brick could respond immediately
upon receiving a msg. Note that these tests are being performed in the
same office that much of the work was done last summer and fall, and the
blinds have been dropped - so the background IR should be comparable.
After performing tests for a couple of hours trying to figure out
exactly what was going on, I discovered that the IR Tower was beginning
to flake out. I could no longer transmit to the brick in near mode, and
even in far mode I was sometimes failing to download programs. I
switched to the other IR Tower, saw that it worked, and immediately
ceased to use that workstation. I *believe* that that workstation was
used in demonstrations last fall, but I do not know how many. I've now
got my only functioning tower plugged into an older laptop running
WinNT, and am rewriting my comm code to handle lossy/noisy comms. Urf!
Anyway, wanted to lay that out for you all to comment on.
-- Greg Frazier
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
