Pavel Petrovic, ppetrovic @t acm.org, Richard Balogh1, balogh@elf.stuba.sk,
Department of Computer and Information Science
Norwegian University of Science and Technology
Trondheim, Norway
Technical report 1/06.
Printer friendly: PDF
1: Department of Automation and Control, Slovak Technical University, Bratislava
We use the low-cost hardware LEGO Mindstorms RCX robotics platform for simple prototyping in research and student projects. The communication capabilities of the RCX brick are limited to the IR-communication, which requires direct or at least reflected visibility, it is limited to short distances, and it has limited reliability mainly due to the irregularities in IR-light reflections. In addition, multiple modules communicating at the same time result in collisions, and the communication is only half-duplex (it is bi-directional, but only one direction at a time).
In order to overcome at least some of these limitations, we were investigating options for wireless radio-based communication. There are four basic options for setting up such a radio communication link known to us:
The student experiment consisted of an autonomous rescue mobile robot moving in an arena. Its task was to discover victims as detected by a color camera mounted on the robot. The camera is a network-type, i.e. it is running an on-board webserver, and makes the video available to be viewed in a webbrowser, where it is shown by a proprietary ActiveX plugin. The frame-rate of the update is up to 30 frames per second, however, the only way to obtain the frames, according to the producent, is to grab the frames from the webbrowser screen. We have therefore developped a C++ application (and in deed also Java API using JNI), which initializes the communication (i.e. starts the web-browser automatically), and grabs the images from the browser window (even if it is running in the background). This is achieved using the PrintWindow() Windows API, which prints the contents of the window into a buffer provided, we further process the grabbed image using the Intel's OpenCV image processing library. We detect the colored victims using our proprietary algorithm for simple color segmentation of the image. The camera software provides also an option of static image, which can be downloaded from the camera using ftp-protocol, however the update rate of that image is only 1 frame per second. The program that is utilizing the image grabbing from browser window with the sourcecode is available from http://webcvs.robotika.sk/cgi-bin/cvsweb/robotika/detect/releases/detectv3.zip.
More importantly for this article, the camera is designed to be used as a security camera and thus it has a single-bit digital output and a single-bit digital input, for connecting the alarm sirene, and motion detection sensor respectively. These bits can be triggered and determined by logging to the camera using telnet protocol and issuing service commands from the console. Connecting both of these contacts to a single RCX sensor port yields a setup, where the RCX can trigger the digital input of the camera by changing the sensor port configuration between active and passive sensor mode (i.e. whether it is powered or not), and triggering of the camera's digital output can be detected by reading the value from the RCX sensor port. In this way, we have connected the program running on the RCX to the same WIFI network where the network of the robot communicates. See figure 1.
 |  |
 |  |
There is, however, one unpleasant limitation of this setup: the digital input and output are electrically separated from the wireless camera, and the switching on and off is performed using a slow rele, which cannot switch more than a very few times a second.
The data link layer of our communication protocol allows to send three types of packets:
The physical layer of the protocol allows changing the state on the port between 0 and 1. However, keeping the signal high is not recommended for longer time, particularly because the changes on the camera's digital output can be detected only while the signal is low. Therefore our communication protocol consists of sending full impulses (changing the line from low to high and to low back). Thus logical zero is sent as "no-impuls", while logical one is sent as "impuls", which must occur within a designated time interval. The nullit is sent as a single "1" - single impuls that is not immediatelly followed by another impuls. A digit is sent as "11XXXX" where XXXX are the four binary bits of the digit, and byte is sent as "111XXXXXXXX", where XXXXXXXX are the bits of the byte (little-endian).
The Java API for both PC-side (utilizing the implementation of Telnet protocol from Apache CommonsNet), and RCX-side (in LejOS) is available with source code from http://webcvs.robotika.sk/cgi-bin/cvsweb/robotika/lego/d_link_camera/releases/WifiComm_v2.zip.
A higher bandwidth can be achieved using a virtual serial port bluetooth device - BlueSmiRF. The device comes in two versions: simple and advanced differing only whether the handshaking bits RTS and CTS are available. For our purposes, the Tx and Rx pins conveying the serial protocol data signals on TTL level are sufficient. They could be connected to the RCX motor and sensor ports, but since RCX already has a serial port, it is more natural to utilize it (and save the precious input and output ports of RCX). However, the RCX's serial port is permanently connected to the IR transciever device. As discovered by Dave Baum already in 1998, the RCX's [default] serial protocol for sending messages is operating at 2400 baud, with 1 start, 1 stop, and 1 parity bit, and 8 data bits. A '0' is coded as a 417us of 38kHz IR, while the bit '1' is 417us of no IR signal. We have decided to develop a circuit that transforms the data received from the BlueSmiRF into IR signal transmitted further to the RCX IR serial port. At the same time the device should transform the IR signal emited by the RCX's serial port into a TTL level input further into the BlueSmiRF module, which transmits it further over the Bluetooth radio protocol. The device is performing a very similar function as the standard serial IR tower, with the difference that the PC UART operates on the RS232 levels, whereas the BlueSmiRF required the TTL level signals. The schematic is shown on the figure 2. The left part is responsible for modulating the 38kHz signal that represents the active data signal. The right part transforms the battery power to 5V required by the IR detector. The circuit has been first tested on a testing board (see figure 3), before we proceded with a prototype product shown in figure 4.
 |  |
 |  |
Configuration
Before the communication can begin, the BlueSmiRF module needs to be properly configured. Normally, the circuit comes configured as 9600-N-8-1, with no security, and various default settings. The configuration is performed when the module is in a command mode - that is either it is not yet connected, or the data mode is turned off when connected. Even though the manual claims the module can be switched from data to command mode by sending a particular sequence of escape characters, we found out that this sequence must be sent from the side of the embedded device: sending the escape sequence over the radio did not switch the module into command mode, unless already turned to command mode previously from the local link side.
Therefore, we have to have the capability to send the data to the Rx pin of the module from the side of the embedded device (local link). We could either connect it to a programmable microcontroller, or - we can connect it to the parallel port (LPT) of the PC. For this purpose, we designed a specialized utility that allows sending character strings using serial protocol over the pins of the parallel port. The utility (lptserial) is available from http://webcvs.robotika.sk/cgi-bin/cvsweb/robotika/bluesmirf/lptserial/.
The actual configuration protocol is described in the BlueRadios Bluetooth Intelligent Serial Module AT Command Set. In particular, the following configuration commands are recommended:
| Change scan intervals thus decreasing the power consumption from 48mA to 2mA before the module is connected | ATSW21,2560,11,2560,11 |
| Change the name of the module | ATSN,Usario |
| Change service name (virtual serial port service) | ATSSN,UsarioSerial |
| Prevent communication before connected - i.e. after this command, you can reconfigure BlueSmiRF only when it is connected, and you get out of the data mode using the escape sequence. This is important, because the randomly received and translated IR bytes will be ignored, and will not accidentally reconfigure the module. | ATSW25,0,1,1,0 |
| Turn off verbal responses. This is important, because otherwise the BlueSmiRF will be talking to the RCX each time you open or close the port (CONNECT, NO CARRIER strings). After this command, the BlueSmiRF will output only data. | ATSW24,2,1,0,0 |
| Set PIN | ATSP,newpin,default |
| Change communication parameters to RCX default: 2400-odd-1 and store them to flash. | ATSW20,10,1,0,1 |
A few notes:
Software
Once you locate the BlueSmiRF bluetooth device, and successfully pair and connect it, you can start communicating with your RCX. We realized that some software has serious problem talking to the BlueSmiRF using our USB Bluetooth dongle from TrendNet, because the Windows driver automatically detects the connection settings. When the application attempts to change the settings, the driver for the virtual serial port hangs. This behavior will probably differ at different system configurations, but we found out that simply opening the virtual serial port without attempting to change any of its settings works perfectly fine. In other words, the settings that are stored in the BlueSmiRF are binding.
Our goal was to make the PC communicate with Lejos application running on the side of RCX, and since Lejos is particularly weak with its support for IR communication (it supports only the default ROM routines with a very limited buffer size), we first tested the device with the BrickOS system. A C++ API and an example application for communication with BrickOS is here: http://webcvs.robotika.sk/cgi-bin/cvsweb/robotika/lego/ir/bt2rcx/. The API is designed for simple use:
//---------------------------------interface on the PC side
// (use standard LNP communication on RCX side)
//open virtual serial port
HANDLE fd = open_port("COM4");
//send lnp-message
lnp_send(fd, "Hello", 6);
//receive lnp-message if available
if (lnp_receive(fd)) printf("Message: %s\n", packet);
//close port
close_port(fd);
During our tests, the communication worked reliably even with messages of length 128 bytes.
Once satisfied with testing, a Java API for communication with Lejos system has been developped
as well, and it is available from:
http://webcvs.robotika.sk/cgi-bin/cvsweb/robotika/lego/ir/bt2rcx/java/.
Again, the API is designed to be simple to use and understand:
//---------------------the interface is symmetric between PC and RCX
//create communication object (and open port)
SimpleCommPC comm = new SimpleCommPC("COM4", (byte)0, false);
//send packet with 10 random bytes to RCX
byte[] packet = new byte[10];
for (i = 0; i < 10; j++) packet[i] = (byte)((int)(Math.random() * 256));
comm.send(packet, 10);
//receive packet from RCX, if available
byte[] answer = new byte[10];
len = comm.receive(answer);
//close port
comm.close();
Note that the implementation of the IR-communication in Lejos is poor. Therefore, the packets are sent (particularly in the direction PC->RCX) with extra overhead. In addition, it is unlikely to succeed with sending packets of longer length than 5 bytes (direction RCX->PC) due to limited internal buffer size. The current implementation contains an error-correcting protocol with confirmation message. We introduced this features after the communication in the direction RCX->PC was not 100% reliable. For details, please see the source code, in summary - each message RCX->PC is confirmed by a short confirmation message. In addition, all bytes are sent twice (as N, N+1), with filtering out all possible situations that would prevent error recovery - it is thus sufficient that only 3 out of 4 consecutive bytes are received correctly, where the error can either consist of changing the value of single byte, or omitting a byte (this occurs often due to parity checking). The quality of line decreases as the battery power goes down. However, with our implementation, and fresh battery, we measured 100.0% accuracy in both directions.
We have described implementations of two various extensions to the RCX programmable platform that allow the wireless radio communication of RCX with PC or other devices. The communication through the digital ports of D-Link wireless camera is very-low bandwidth and uses WIFI networking, whereas the solution using BlueSmiRF module works on the default serial communication bandwidth of RCX serial port, and provides reliable communication channel, which is not vulnerable to standard optical difficulties, sunlight, etc. inherent with IR-communication.
The LEGO company is planning to introduce their new robotics platform in the second half of this year. The new programmable LEGO brick will communicate using the Bluetooth protocol. This work not only is a precursor of the planned advancements, but even more - due to the generality of the BlueSmiRF module, it is a gateway for efficient communication between the current RCX platform and the NEXT platform, best of its kind known to us per today.
The work on the serial to IR converter can be further utilized for possibly controlling other devices from the PC, such as the WowWee robots, or home appliances.