(click on the images for a bigger version)
this page is under slow construction
Last update: Mon Jan 23 13:55:46 CET 2012
The automatic testing of a lego ball sorter was shown at the Open Huis of the University of Twente, September 17, 2011.
(click on the images for a bigger version)
The ball sorter sorts white balls to the left, and black balls to the right.
To test whether it really works, the ball sorter is extended with two 'feeders' that allow us to feed the sorter with a white or black ball at the press of a button on a NXT, or via remote control on the computer to which the NXT for testing is connected via USB. Moreover, two light barriers detect passing balls that have been sorted. Not only do they make a sound when a ball is detected, but, via the USB they also make this available to computer for testing.
This allows us to run our model-based testing tool JTorX on the testing computer, and let it automatically test the ball sorter by feeding it with balls of which the color is known, and checking whether the sorted ball passes the right light barrier.
We have a work-in-progress LDRAW model of the sorter with test environment (not yet finished)
note: this model uses parts from Unofficial LDraw parts for NXT.
self-contained model constructed using MPDWizard.
LDView movie from the ldraw model.
Look elsewhere for more details of the light barrier.
Also the ball feeding mechanism is taken from elsewhere:
we found it as the ball stream splitter mechanism of a fast ball sorter.
The ball sorter consists of the following elements:
The NXT runs lejos 0.8.5, which allows the use of a lejos Java program to control the NXT. The java program reads the light value when it is started, and remembers it as a baseline value. It then contiously senses the light. When it senses a different light value than the baseline, it assumes that a ball is present. It then waits a bit, for the ball to be 'stable' in front of the sensor (to avoid misreadings while the ball is still in motion moving towards the sensor). It then takes areading to determine how to sort: lower or equal to a preset value means black marble, higher means white marble.
Pressing the (orange) square button on the NXT makes it reset the baseline value to the current light value. Pressing the LEFT and RIGHT buttons changes the preset value at the border between black and white.
The NXT is connected via a USB cable with the test computer on which JTorX is run. (We can also use bluetooth instead of USB to provide this connection, but we believe that not using bluetooth conserves energy.) The NXT runs lejos 0.8.5, which allows the use of a lejos Java program to control the NXT. The Java program uses the lejos USB connection support to provide the connection between the Java program that runs inside the NXT and a companion lejos Java program that runs on the test computer.
runs three threads:
Ad 1: The observer thread maintains a text string that contains letters ``L'' and ``R'' for each ball that is detected. It allows the other threads access to this text string.
Ad 2: The command interpreter thread expects one of the following commands: doStim(MarbleColor), getObs(), reset().
Note: pressing the triangular LEFT and RIGHT buttons on the NXT also invoke the doStim() command to allow one white resp. black marble to pass.
runs only a single thread.
In this thread, the program first tries to connect over USB with the NXT. Once that connection is established, it performs a main loop in which it does the following:
The commands and responses that the program receives from and sends to JTorX are in the form of the (textual) messages that we use on the torx-adapter protocol. The program can interact with JTorX in two ways: via the standard input and standard output of the program, or via a TCP connection; the user can choose between the two when the program is started.
When the program is started with a single a single command line option: the TCP port number on which the program must listen for connections, once connection over USB with the NXT has been established, the program starts a TCP listener on the given port. Then it will, until the program is ended wait until a TCP connection is established, communicate over that connection until the connection is closed, and then start waiting for the next connection to be established, etc. This has the advantage that the connection over USB with the NXT has only to be established once (when the program is started), and for each test run a separate TCP connection is created, while the USB connection to the NXT remains established. This is good because it may take some time to establish the USB connection with the NXT; creation of the TCP connection is almost instantaneous.
When the program is started without any command line option, the program communicates over standard input and standard output. When the standard input is closed, the program stops (exits).
Typically, during a demo we use the TCP connection approach. However, because JTorX has no built-in functionality (yet) to communicate over TCP using the torx-adapter protocol, but only for communication over standard input and -output, we use a separate program called tcp to translate between communication on standard input and -output and communication over TCP. The program tcp is given a single command line argument: the port number on which to connect.
