Project - Communication Solution

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:

• PC
• Robots
• PC-NXT

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