Date: 01-06-2012 – 03-06-2012
Duration of activity: 8 hours
Group members participating: Thomas
Goal
- Design communication software
architecture
- Test communication architecture
Plan
Use the weekend to
understand how the NXTs communicate and build an asynchronous software platform
that we build the rest of the robot software upon.
The idea is to
develop an asynchronous software platform that software layers above could use
to communicate with other NXTs and a laptop as shown on the sketch below.
We want the software layers above to have a simple interface to communicate
with.
Results
We have
identified the need for three different programs (using [1] and [2]), one for each of the following
network devices:
All network
devices share the following low level architecture:
The layers on
top of the communication layer will only communicate with the
CommunicationController. The CommunicationController lets other objects subscribe
to incoming messages from the network and lets them send messages to other NXTs
in the network. It contains an instance of the IncomingCommunication-class that
has a dedicated thread that listens for incoming messages and an instance of
the OutgoingCommunication-class that takes care of sending messages. The
OutgoingCommunication-class has a queue where outgoing messages are stored
until its dedicated thread flushes them to the network. The object uses the
notify/wait pattern to avoid busy wait.
PC:
The role of the
PC is to observe the behavior of the robots through the network. The program
running on the PC is quite simple. It connects to the PC-NXT through an
USB-cable and prints all network messages to the console. It only consists of
the following few lines:
public static void main(String[] args) throws Exception {
//Create USB connection to NXT
NXTComm nxtComm =
NXTCommFactory.createNXTComm(NXTCommFactory.USB);
NXTInfo[] inf = nxtComm.search(null);
nxtComm.open(inf[0]);
DataOutputStream out = new
DataOutputStream(nxtComm.getOutputStream());
DataInputStream in = new
DataInputStream(nxtComm.getInputStream());
CommunicationController cntrl = new
CommunicationController(in, out);
PC_Main main_obj = new PC_Main();
cntrl.subscribeToIncomingMessages(main_obj);
while(true) {
Thread.sleep(10000);
}
}
@Override
public void notify(Message msg) {
System.out.println("IN: " + msg);
}
Robots:
The robots only
contain the simple communication architecture shown in the previous UML
diagram. It is up to the higher software layers not build yet to take advantage
of these features.
PC-NXT:
The role of the
PC-NXT is to broadcast every received message to the whole network. That is the
network topology is a star topology with the PC-NXT in the center. Every node sends
its messages to the PC-NXT after which it broadcasts the messages to everyone
else. It is also the responsibility of the PC-NXT to initiate connections to
the PC and all the robots.
The PC-NXT
software’s UML diagram looks like the following:
It is basically
the same diagram as previously shown except for the class MessageEchoer. It
contains a queue that collects incoming messages from the network and a dedicated
thread that empties the queue and forwards the messages to each communication
controller.
Problems encountered:
To our surprise
the NXTs and PC communication became very slow when we implemented dedicated
threads taking care of the input and output streams. It was so extreme that it
looked like we had overlooked a deadlock in our program. After looking though
the code of our program again and again and implementing queues and wait/notify
patterns, the problem had disappeared from the NXTs, but was still occurring on
the PC. After debugging we discovered that the PC could not flush its output
stream and was hanging forever. It then hit us that on the PC with multiple
cores the input stream was probably busy waiting on incoming messages and
thereby rejecting any access to the underlying stream code to the output
stream.
The problem now was
that read methods on the input stream were blocking and the stream’s available-method
always returned zero for some reason. How could we know in advance if the
read-method would block forever or receive a message waiting to be received? We
considered making each NXT send out a message before trying to receive a
message. This would guarantee that a message would eventually show up in the
input stream. This solution has some draw backs though. What would happen if
the message got lost as does occur with BlueTooth communication. We would risk creating
another deadlock. Instead we decided that the PC-NXT should send out pings
every short interval as the NXTs do not have the same deadlock that the PC with
multiple cores has. This solved the problem and the communication was working
well in the rest of our tests.
Conclusion:
After considering and trying different communication solutions we finally came up with a good asynchronoussolution that we can build the rest of the robot software upon.
Download:
Our solution can be downloaded through the following link:
http://daimi.au.dk/~sylvest1/NXT-Communication.zip
References:
[1], leJOS Tutorial: Communications,
http://lejos.sourceforge.net/nxt/nxj/tutorial/Communications/Communications.htm
[2], Lab 5,
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/PCcarController.java &
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/BTcontrolledCar.java
