LEGO Lift Project

Members
Publications
Scientific Days
 
CO-OPN Tools Software
Download
Documentation
Examples
Screenshots
History

LEFO Lift: The software part

I- The Idea:

LGL LEGO LIFT
Overview
Hardware
Software
Video
Credits

We wanted a java package to control a legoMindstorm construction from the pc.

It's true that some package to send opcode (hexadecimal code of the rcx firmware instruction) or a java firmware for the rcx tower already exists,
but we wanted a higher level package giving some method that can be understood by anybody, without having to study the serial protocol and the rcx opcode; we also wanted to make some big program that wouldn't be stored in the small rcx tower memory but directly executed on the computer.

The package delivers some methods to control the motor:

startMotor, stopMotor, flipMotor, etc...

or control the rcx tower:

isAlive, playSound, etc...

but it's also able to get the sensor values, so it provides a simple events structure that notices any listener when a sensor has been triggered.

 

II- The problem and some solutions given by the package:

You might have noticed it, but the event model is not sequencial and needs a thread to check each sensor at a quite rapid time interval.
But then, what if a checking thread sends some command to the serial port and wants to wait for the result and another checking thread (we have 3 sensors) or a user command (start motor, etc..) comes along and replaces the first command without waiting for the answer?

YES, there is a big problem, all the commands have to be sent through the serial port and have to be sent sequentially, so we have to control the thread outputs!!

The chosen solution is a pool where commands are pushed and wait to be sent when the port is not busy: this queue also implements a simple priority sorting as the user commands have to be executed immediatly, unlike the sensor checking commands that are sent every n seconds and can wait a bit...

The data flow will look something like that (click to enlarge) :

 

III- Where Object oriented becomes hard to describe:

Now I'll try to describe how the package is divided in objects. I'll make some categories:

  1. The low level objects (the user should not need to interfere directly with these objects) :

    The rcx port is there to parse the hexadecimal opcode to the rcx tower, formatting it correctly. Since this object is coming from another package, we use a wrapper so it gets the correct methods: this is the role of the extended port; the Command Queue sends there the pooled commands.

  2. Interfaces and other extendable objects (only users that know what they are doing and need extended functions should need these objects) :

    The only thing that can be put in the Command Queue (using the send() method ) are the RCXCommands that contain the opcode to be sent, the parameters and the length of answer. This object also contains the answer given by the rcx tower to this command.
    It can be used in two ways:
       - directly by creating a new instance and configuring it to contain the good opcode,
       - by extending it and creating new objects containing some more methods for special commands.
    Now we have to send this command to the Queue, and all the objects that will do that need to implement the CommandSender interface that provides methods to notify the user that an answer has been received.

  3. High level objects (these are the objects a simple user will use)

    The package provides some useful objects to program a simple behavior for a Lego Mindstorm kit. First you have the RCXControl containing the 3 RCXmotors and the 3 RCXSensors of the rcx kit, so you should only create an instance of RCXControl and use the rcx object contained in it, and you won't have any problem with instancing more than one object for the same motor or sensor; it also provides some more functions like playing sounds or other simple commands of the RCX Tower.
    If you will be using the RCXSensor you'll have to instantiate some SensorListener to be notified of any change of the sensor.

 

EPFL | DI | LGL
Last modified 14/09/01 , Pierre Andrews.