Code Away

Read this if you value your privacy. It’s a good walk through even if you are not an expert with computers.

Since I wrote about my stint with Lego Mindstorms and blocked Java I/O calls in my last post, I thought I might as well go ahead and note some more of the gotchas I encountered while working with Mindstorms kit.

Although the Mindstorms RCX has pretty good capability, the programming interface bundled alongwith it is for kids. For any program spanning more than two cases of flow control, we need a real programming language.

The two languages I used were NQC (having almost C syntax, and named Not Quite C) and LeJOS (Le Java OS), based on Java 1.2.

NQC has inbuilt support for functions as well as multithreaded modules, but quite frankly the threading was not upto the mark. With two threads competing with each other for execution time, sometimes there would be several seconds where one of the threads waited for execution. LeJOS, on the other hand, worked beautifully with multithreading.

NQC also has a rather limited memory available for processing in comparison to LeJOS, which is quite surprising considering Java VM of LeJOS occupied around half of the memory. Yet, I was able to form large data structures in LeJOS while arrays of as small as 30 integers started giving trouble in NQC.

LeJOS has its set of troubles as well. The VM installation is actually a one time thing, but with the amount of testing you perform on the bot, batteries get changed, RCX units change and thus you find yourself running LeJOS installation a dozen times, which is quite a miserable thing to waste one’s time on. In addition to that, we have the great blocked I/O problem for Infrared Sensor which we discussed in our last post.

Limited memory and processing capacity puts stringent limits on nested methods, garbage collection and size of data structures. As I discussed earlier, a workaround to blocked I/O calls involved creating two separate threads. In my case, I had to keep both threads running infinitely. Having the child thread exit after receiving the data and having the parent thread spawn a new child when necessary worked for a while, but then the program would hang, presumably because there were too many threads getting created and the garbage collection may not have been able to cope up.

All in all, its fun working on the RCX, as long as the program is tuned to minimum resource usage, which goes for any micro platform. If you have experienced any more glitches or gotchas, please feel free to post comments!

Some time ago, I happened to work with Lego Mindstorms. Rather than learn yet another programming notation for Mindstorms, I preferred to use LeJOS.

However, LeJOS was based on Java 1.2, which had blocked I/O calls. This means that an I/O write was not completed until a corresponding I/O read was executed at the receiver. Similarly, an I/O read was not executed till someone wrote to the buffer.

How is this different from unblocked I/O? In the latter scenario, we poll the buffer status like this:

while(true) {
  sbuf = inputStream.read(byteArr);
  if (sbuf != null) {
    //code to process byteArr
  }
  //other processing to be done
}

In case of blocked I/O, the program waits for inputStream.read to get executed, till a point that the input buffer actually contains some data. Of course, this makes the check sbuf != null worthless, but more important is the fact that the “Other processing” we’d like to do never gets done until the input buffer is populated. Why is this important? Because in most cases we want to process a lot more than a single data stream. For example, in my LeJOS program, I was handling inputs from touch sensors, a light sensor and an Infrared sensor.

(A bit about my LeJOS program: I was trying a basic car driving program which could understand walls with touch sensors, car driving in front using light sensor and vehicle coming head-on using infrared sensor.  Although my Infrared sensor could be accessed using the usual I/O calls, it meant blocking up all the processing till someone actually sent me a signal.)

The easy way out of blocked I/O is multi-threading. The parent class polls the buffer data held in the child class (where both classes are threads and run independently). If there is valid data, we read and respawn the child class. Else we continue (in an infinite loop) with other processing and return later to check data. The child class is the one which stays blocked, but that thread is dedicated to receiving data only. Our program execution continues safely.

For those interested, LeJOS code for basic car driving (with inputs from sensors) with Lego Mindstorms RCX kit is available here.