Lego Crane
Project
Robert Adie
Stephen King
David Loudon
Class ESE3H
Session 1999/2000
Department of Computing Science,
University of Glasgow,
Lilybank Gardens,
Glasgow, G12 8QQ.
3.3.4 Java Runtime Environment
4.2.2 Communications (PCßàRCX)
5 Implementation
and Integration
7.2.2 Installation of
Application
9.1 Acronyms and Abbreviations
1 Introduction
This document is the dissertation for the Electronic and Software Engineering Third Year Team Project. It documents the design, construction and testing of the project deliverable.
The project objective was to firstly evaluate the Lego Mindstorms Robotics Invention System (pictured) and then deliver a product to demonstrate it’s potential for educational purposes.
Figure 1 - Lego Mindstorms Robotics Invention System
The evaluation documentation was titled “Evaluation Report and Project Plan”. This can be viewed on the project website[1].
The main objective of the deliverable product was to provide an impressive demonstration of the capabilities of the Lego Mindstorms Kit. Additional aims for the product were that it be visually striking and demonstrate a wide range of scientific principles for use in departmental open days.
The deliverable item decided upon for the demonstration was a robotic crane. It was to be built from Lego and was to be controlled remotely. It’s specification follows.
2 Specification
2.1 Hardware Specification
The crane will be based upon a tower crane structure, having a tower base with a rotating arm. The necessary control for these tasks will be split between a number of RCX bricks and the host PC.
As in Figure 2 - Crane Overview, the crane’s jib was to be able to move with three degrees of freedom: horizontally along the gantry; vertically from the gantry’s front-end; and rotating about the axis of the tower. It was felt that this was a suitable level of functionality to result in an impressive demonstration.
The crane was to incorporate sensors that would allow the accurate determination of the position of the jib in three dimensions. It’s ability to know where it is will add to the requirement of an impressive demonstration, but will also allow the demonstration of various sensors, thereby demonstrating simple sensor use.
The structure was to be free standing, strong and stable. The tower was to be at least 2 feet high, thereby giving a presence in the room, making the demonstration impressive.
To allow the remote user to view the crane’s motion, the use of a web-cam was specified, to allow visual feedback whilst controlling the crane.
Gantry Base Tower Jib
2.2 Software Specification
The software used should allow the crane to be controlled over the Internet, allowing it to be controlled from anywhere with Internet Access.
2.2.1 Crane Control
The crane was to be controlled by a number of RCX bricks. These bricks would receive communication from a PC, allowing the crane to be controlled from it. They would also allow requests for the crane’s position, which they would return.
2.2.2 Server Application
The PC communicating with the crane’s RCX bricks was to also act as a server for the client application, interpreting client commands and passing them on to the relevant RCX. It was also to return data to the client, e.g. position information.
2.2.3 Client Application
The remote application was to allow control from anywhere on the Internet, be easy to use, and look impressive. It was to allow both manual and position control of the crane. It should also allow retrieval and display of the current position of the crane.
3 Overall Design
3.1 Overview
The Lego Crane Project (LCP) resulted in the production of a web controlled tower crane built using Lego Technic.
The Lego Crane is directly controlled by a number of RCX programmable controller bricks which are in turn controlled by a Server PC. The server provides a video feed via a webcam and allows remote client software to control the crane. The client software allows the user to control the crane by sending commands such as UP, DOWN etc or by entering a position to which the crane will move. The client software is written in Java, as is the webcam client, thus any platform with a web browser and recent version of the Java runtime is capable of acting as a client.
The overall system can be broken down into a number of parts:
- Hardware
- Lego Tower Crane
- IR Transmitter Tower
- Server PC
- Webcam
- Client PC
- Software
- Web Server
- Webcam Server
- Crane Server including RCX communications subsystem
- Java Runtime environment
- Web Browser
- Client Application
3.2 Hardware
3.2.1 Tower Crane
The crane itself is built using Lego Technic. It is controlled by a number of RCX programmable controller units. Drive is provided by 9V DC motors with touch and rotation sensors used to provide positional feedback.
3.2.2 Transmitter Tower
The IR transmitter is connected to the server PC and allows two way infra-red communication between the server and the RCX bricks in the crane.
3.2.3 Server PC
A PC is required to run the software. This is used to run the Apache Web Server, Web Cam server and the Crane Server. The PC must be running Windows 95/98 or Windows NT 4.0 or later. As the Crane Server software is written in Java, this machine must have the Java Runtime Environment (JRE) or Java Developers Kit (JDK) installed.
3.2.4 Webcam
The webcam is used to transmit pictures of the crane in operation to the client machine. It connects via the parallel port.
3.2.5 Client Machine
The client machine requires a Java Compatible web browser, as the Video is fed from the webcam via a Java Applet. The client must also have JRE1.2 or above or JDK1.2 or above installed. This is because the client application is written in Java and uses RMI and SWING which need recent versions of Java. Aside from these requirements, the client can be any type of machine from a UNIX workstation to an advanced PDA.
3.3 Software
3.3.1 Web Server
The freeware web server Apache is used to provide the web page containing the video applet. This applet could be hosted on another web server i.e. not necessarily on the crane server machine. The web server is therefore not strictly necessary, although would be required for further developments.
3.3.2 Webcam Server
A server program was required to capture video from the webcam and stream it across the internet link in real time. Finding such a piece of software proved problematic. Eventually “TrueTech Webcam” was chosen, as it was freeware and provided a Java applet to allow clients to view the video feed.
3.3.3 Crane Server
The crane server software forms a significant part of the project. It communicates with the RCX bricks using the infra red tower, while receiving commands from the client application via the internet link.
3.3.4 Java Runtime Environment
As stated above, the client and server machines both require the JRE (or JDK) to be present, as the server and client software is all written in Java.
3.3.5 Web Browser
The client machine requires a java compatible web browser to allow the video feed to be accessed.
3.3.6 Client Application
The client application provides an interface for the remote user which allows control of the crane. It consists of three main tabbed panes. The first allows immediate manual control of the crane e.g. Clockwise, Anticlockwise etc. The second allows a position to be entered, which the crane will then move to. This pane also allows the user to query the position of the crane. The third pane allows access to a bank of preset automated functions, such as the ability for the crane to go “home” (i.e. go to 0,0,0).
4 Detailed Design
4.1 Hardware Design
4.1.1 Physical Lego Design
4.1.1.1 Tower
The tower is built using a modular structure. Each module is approximately 10cm tall and is very strong. It exhibits strength and stiffness in all directions and proved a very reliable design.
Figure 3 - Tower Cell CAD Model
Although this modular design meant the tower could easily be expanded and modified it does have some drawbacks. The primary one is the number of pieces required for each module. It needs eight 16 long beams, eight 8 long beams, eight 6 long beams and 32 black locking pegs (among others). It therefore placed a heavy demand on our resources and as a result we were not able to build the tower as high as we may have liked.
The tower sections sit on top of one another and are then locked in place by four vertical beams – one on each side – and black locking pegs.
Wiring the system presented some interesting problems – how to get power and signals from the moving turntable to the stationary base housing the RCXs. Various complicated solutions were considered including using brushes and metal rods embedded in axles, but they were discounted.
Eventually, it was decided that the cables would simply be dropped through the hole in the turntable down the shaft of the tower. While this worked, it led to the cables becoming twisted. It was hoped to incorporate into software a mechanism whereby the crane could only rotate so many times in the one direction before having to go the other way, thus untwisting the cable. Given the time available, this was not possible, so in operation the crane had to be monitored to ensure that the cables were not twisted too tightly. The picture below shows a section of the tower with the cables running down the shaft being twisted.
Figure 4 - Tower Section showing twisted wires
4.1.1.2 Base
The base builds onto the lowest modular tower unit and extends outwards in all four directions. It is designed such that an RCX brick will fit between the protrusions on each side. By using four RCX bricks, a very stable and strong base was produced, partly due to the weight of the batteries they contained. The resulting base is also aesthetically pleasing. Note : Only three RCXs are actually used by the system.
Figure 5 - Base with 4 RCX bricks and lower section of tower
Figure 6 - Close up of base showing 2 RCXs and connection to tower
4.1.1.3 Turntable
Allowing the arm to rotate proved very difficult and this section was redesigned from scratch several times. The final design is based around a standard lego Technic turntable.
This is driven from an eight-tooth gear on a vertical shaft. This shaft connects via a forty-tooth gear to a worm gear on a second shaft inside the body of the tower. The second shaft is connected directly to the motor. This second shaft is also connected directly to a Rotation Sensor, allowing measurement of angular position.
Figure 7
- Inside of Turntable Drive Unit (from below)
Figure 8 - Turntable illustrating smooth bricks
4.1.1.4 Horizontal Drive
Again, horizontal movement proved very problematic. Various designs were looked at using pulleys and moving carriages.
Figure 9 - Top view of Gantry
In the end, a simple “telescopic” design was settled upon. The vertical drive unit is fixed onto the end of a long arm. The top of this arm is covered in teeth which are driven from a series of cogs above the arm. The arm thus slides in and out of the body, extending or retracting the vertical drive unit.
Figure 10 - Underside view of gantry
Touch sensors are fixed at each end of the arm assembly to detect the arm reaching either of its maximum extents. A rotation sensor is driven directly from the motor providing the horizontal movement.
Figure 11 - End view of gantry
4.1.1.5 Vertical Drive and Jib
The vertical movement of the jib is provided by a thread wound around a drum. The drum is driven by the geared down output of a third motor. Rotation of the drum results in vertical movement.
Figure 12 - Rear view of vertical drive unit
Fitting an “end switch” to the vertical movement system looked to be very difficult, if not impossible. In the end a reed switch was fixed to the crane arm just below the drum. A small bar magnet was then fixed onto the Jib. This allowed the uppermost position of the jib to be detected, as the reed switch was tripped when the jib was raised to the top.
Figure 13 - Front view of vertical drive unit
It was planned to use an electromagnet as the jib to allow automated operation of the crane and sequences of commands to be carried out. In the end this proved too difficult and a simple mechanical hook was used. This was a standard lego Technic part taken from the Monster crane Truck Kit.
4.1.2 Electrical Design
The electronics of the crane are relatively simple. They consist of the three operational RCXs, three rotation sensors, three 9V DC motors, several touch switches and a reed switch.
The reed switch provides a simple on/off response, so was ideal for use with the RCX and can be read in exactly the same way as a touch sensor.
Battery life proved to be a problem while operating the crane for long periods. NiCd rechargeable batteries were used and had a very short useful life between charges. NiMH could be a better solution in the long term.
4.1.3 PC Hardware
The server PC requires no special hardware. It must however have a parallel printer port for the webcam. It will also require some sort of network connection.
While an analogue modem would provide more than enough bandwidth to operate the crane, the video feed would refresh very slowly over such a link. A high speed link such as ADSL or a LAN is desirable.
4.2 Software Design
4.2.1 Embedded Code
The RCX software was implemented in Not Quite C. Each RCX needed a different program as they each had different parts of the crane to operate. There is however a great deal of commonality in structure between the different programs, so this will first be discussed before going into the separate code details.
4.2.1.1 General NQC Program Design
Each RCX has the same main message loop:
while (true)
{
ClearMessage();
until (Message() != 0);
if (Message() == ID_CODE) {
ClearMessage();
until (Message() != 0);
if (Message() == COMMAND_CODE) {
//do something
}
.
.
.
if (Message() == COMMAND_CODE) {
//do something
}
}
else {
//This command does not
require a brick ID, all RCXs should respond.
if (Message() == EMERGENCY STOP CODE)
Off(OUT_C);
}
}
}
Each RCX brick was given a unique identification byte (ID_CODE above). Once an identification byte is sent, the program on the RCX to which it refers will check the next byte sent. If the byte is one of the command codes, the relevant operation is carried out. If not, no action is taken, and the program returns to the identification check loop. Commands are either immediately acted upon or a concurrent task is started, enabling control to return to the top of the loop to receive the next message.
The emergency stop code does not require an identification code as all RCXs should respond to the command, by stopping all movement of the crane.
Figure 14 - Message Received Flowchart
4.2.1.2 Code Allocation
It was decided that all commands sent from the PC should be negative (see notes). The byte codes chosen were:
Horizontal movement RCX (Dougal) Identification Code : FF
Arm retract F1
Arm extend F2
Arm halt F3
Get arm position F4
Set arm position F5
Get maximum arm position F6
Vertical movement RCX (Jack) Identification Code : FE
Jib lower F1
Jib raise F2
Jib halt F3
Get jib position F4
Set jib position F5
Get maximum jib position F6
Rotational movement RCX (Ted) Identification Code : FD
Rotate arm clockwise F1
Rotate arm anticlockwise F2
Halt rotation F3
Get rotational position F4
Set rotational position F5
Get maximum rotational position F6
4.2.1.3 Detail of NQC Programs
4.2.1.3.1 Horizontal movement RCX (Dougal)
The end_check task is responsible for both stopping the arm from moving beyond its maximum and minimum extents, and maintaining calibration of the horizontal position sensor. When either end switch is pressed, it moves the arm in the opposite direction until it is no longer touching the switch. The rotation sensor is reset if the arm was retracting when the switch was pressed, which indicates the arm is at the zero position. This ensures that the arm is calibrated regularly, compensating for gear slippage and sensor inaccuracy.
The arm_extend, arm_retract and arm_halt functions set the motor to the correct state.
The arm_get_position function, sends
the current horizontal position of the arm to the PC. It returns the current
value of the rotation sensor divided by a calibrating factor, which reduces the
value to a number which is less than 126 (see Section 4.2.2).
The arm_goto_position function moves the crane arm to the horizontal position specified by the PC. It gets the position sent and corrects it by subtracting one (see Section 4.2.2). If the position is not between the maximum and minimum allowable values default values are chosen. The motor is then sent the correct direction and the concurrent task stop_at_position started, which stops the motor when the arm is in the correct position.
The arm_get_max_position function sends the corrected maximum position value (see Section 4.2.2).
4.2.1.3.2 Rotational movement RCX (Ted)
The zero_crossing_check task is responsible for maintaining calibration of the rotational position sensor. When the arm touches the rotational zero switch, the rotation sensor is reset. This ensures that the arm is calibrated regularly, compensating for gear slippage and sensor inaccuracy. The zero switch is set to the raw sensor mode, as the arm only lightly touches the switch and does not activate the switch in touch sensor mode.
The convert_position task converts the rotation sensor reading to a calibrated rotational position.
The arm_rotate_clockwise, arm_rotate_anticlockwise and rotation_halt functions set the motor to the correct state.
The rot_get_position function, sends
the current rotational position of the arm to the PC. The position value is
corrected as above.
The rot_goto_position function moves the crane arm to the horizontal position specified by the PC.
The rot_get_max_position function sends the corrected maximum position value (see notes).
4.2.1.3.3 Vertical movement RCX (Jack)
The zero_check task is responsible for both stopping the jib from moving above its maximum height and maintaining calibration of the vertical position sensor. When the reed switch is activated, the jib is moved down until the switch is deactivated, and stopped. Also, the rotation sensor is reset to maintain calibration..
The ground_check task is responsible for stopping the jib from going beyond its lowest allowable height. When the jib is at its lowest position, it is moved up until it is no longer at its lowest and stopped.
The jib_lower, jib_raise and jib_halt functions set the motor to the correct state.
The jib_get_position function, sends
the current vertical position of the jib to the PC. The position value is
corrected as above.
The jib_goto_position function moves the crane jib to the vertical position specified by the PC. Operates same as above.
The jib_get_max_position function sends the corrected maximum position value (see notes).
4.2.2 Communications (PCßàRCX)
The lower level Java communications code is based on the Sun Microsystems Java Tanks Demonstration code but had to be substantially altered to make it work for the purposes of this project.
It was found that the IR tower picks up the messages it sends as well as those it receives. To resolve this problem, it was decided that all messages sent from the PC would be negative and all messages sent from the RCXs would be positive.
Also, SendMessage(0) results in no message being sent. To enable messages of zero value to be sent, it was decided that 1 would be added to messages sent and 1 subtracted from each message received (except command bytes).
It was decided to make messages one byte long. This was adequate for the number of commands which were to be sent from the PC (128 possible distinct command codes). It did however restrict the number of position values that could be sent to and from the RCX to 127. This was sufficient accuracy for the purposes of the demonstration.
The RCX infrared port operates with the following parameters
Baud rate 2400
Data bits 8
Stop bits 1
Parity Odd
The RCX expects infrared messages of the following form. All messages are prefaced with a three byte header (55, FF, 00). Each data byte is followed by its two's complement. The message is followed by a simple checksum, and the two's complement of that checksum. The checksum is computed by doing an 8-bit accumulation of all the data bytes.
55 FF 00 D1 ~D1 D2 ~D2 …. Dn ~Dn CS ~CS
The data to be sent is prefixed with F7, which is the opcode to send a message to the RCX, which simulates the communication with another RCX.
IRProtocol:
This class handles the low level sending and receiving of messages via the infrared tower. It makes use of the Java communications API to give low-level control of the serial port.
In the IRProtocol constructor, the serial port is opened and configured correctly for communications with the RCX (see notes).
In the serial port event handler, if the activating event is DATA_AVAILABLE, all data on the input buffer is sent to the message buffer (see below).
The addMessageListener method provides the client with the capability of receiving messages from the message buffer.
The send method takes in an array of data bytes to be sent and adds the wrapper bytes that the Lego firmware expects (see notes).
MessageBuffer:
This class was converted from the Sun Microsystems Java Tanks Demonstration with
the unnecessary parts of the code removed. Messages received over the IR interface will
sometimes be broken up into multiple chunks. This class relieves the client of
the burden of buffering and later assembling messages. Message chunks are
appended to the buffer using the append() method. The buffer uses the 5516
FF16 0016 message header as a frame sync to recognize
message boundaries. Clients will be notified only upon reception of complete
messages.
MessageListener:
The interface which a receiver of buffered messages must implement.
Brick:
This class provides a layer of functionality on top of the IRProtocol class. It implements the MessageListener interface in order to receive messages from the message buffer.
The sendMessage method sends one byte of data to the RCX.
The setMode method sets the mode for the next message received so that information is stored in the correct variable.
The getAnswer method returns the information requested.
Controller:
The Controller
class provides high level abstraction of the low level communications layers to
give the client specific commands relating to crane operation.
The emergencyStop method instructs the crane to stop all movement.
The rotationalCalibrate calibrates the rotational position sensor. This method should be called on start up of the system as the position value will initially be undetermined. It turns the crane in one direction until it touches the zero switch and then stops.
The other methods are self-explanatory and abstract the move, stop, set and read commands.
armExtend()
armRetract()
armStop()
getArmPosition()
setArmPosition(int pos)
getArmMax()
jibRaise()
jibLower()
jibStop()
getJibPosition()
setJibPosition(int pos)
getJibMax()
rotClockwise()
rotAntiClockwise()
rotStop()
getRotPosition()
setRotPosition(int pos)
getRotMax()
4.2.3 Server
4.2.3.1 Software Architecture – Introduction
Figure 15 - Communications Architecture Diagram
The actual crane control software is split into 2 discrete parts – a client and a server. The server program runs on the PC physically connected to the Infrared Transceiver which communicates with the RCX bricks on the crane.
The client program simply acts as the interface to the end user and must pass their commands on to the server which then executes them. This presented the team with a major design issue – how to handle the communications between the client and server.
As both the client and server were to be written in Java and were to be connected via an internet link, it seemed logical to use the Java networking API to create a sockets based protocol. This would have however involved a great deal of work and could have resulted in an unreliable proprietary protocol.
While studying the Java networking documentation it became clear that there was an alternative method – RMI or Remote Method Invocation. This basically allows methods of an object on one machine to be called by a method on another machine.
4.2.3.2 Java Remote Method Invocation
RMI is based around the idea that functionality can be separated from implementation. In Java, this is used frequently in the form of an interface which provides a specification for an objects methods and public data structures. The interface could be located on a remote machine, with the implementation on another.
The problem is that no details of the implementation would be present on the remote machine, with no link to the other.
RMI provides this by creating a proxy in the form of a “stub” file. The stub intercepts calls to the interface and passes them via RMI to the remote object. The remote methods are then executed on the remote machine and any return values are passed back to the client via RMI through the stub. Figure 16 - RMI Architecture illustrates this process[2].
On the server machine, an RMI registry server is run. This allows objects to be bound to the registry and made available to remote clients.
4.2.4 Client
The Client’s Application is mostly just an interface. However, some processing is carried out in it. Crane’s position values for rotation are rescaled to a sensible degree value between 0 and 360. User input is corrected so that values over 360° for rotation are mapped back down to 360 degrees (i.e. 370° becomes 10° ) , before then being scaled into a value that the RCX bricks will comprehend.
Mostly, however, the Crane Client Application is a User Interface. To make this interface pleasant to work with, it was decided best to use a compiler with a Rapid Application Development Interface. The compiler used was JBuilder 3.0 Foundation (available as shareware). The reason for using this environment was that it allowed the arbitrary positioning (with mouse pointing) of Components onto the screen.
The original plan, and alternative to doing this, was to use the Java LayoutManager classes, such as GridLayout and BorderLayout. These classes allow components to be sectioned off, and thus arranged easily onto the screen. However, to get an interface which somewhat resembled what the user could do, this method would have involved a hierarchy of nested LayoutManager instances. It would also have been quite difficult to arrange the components to give a feel for what they do.
Instead, using JBuilder 3.0 Foundation, it was possible to position
Buttons, Labels, and Panels, etc in any arbitrary chosen order. This is
achieved by setting the Layout to null, then setting Bounds of a particular
object, which can be done with a Rectangle()…
leftButton.setBounds( new Rectangle(54, 212, 41, 27) );
As is mentioned in the SDK[3] documentation, the Rectangles parameters are
Rectangle (int x, int y, int width, int height);
This constructs a new Rectangle whose top-left corner is specified as (x, y) and whose width
and height are specified by the arguments of the same name, where x and y are
relative to the top left corner of the Component which it is placed on. In this
way it is possible to specify components positioning directly from a text
editor, however using the GUI is far easier, and quicker, and gives the
advantage of being able to see the look of the User Interface without having to
first compile and run it.
Figure 17 – Applet: Attempt at laying Buttons out in form of Crane
Much time was spent experimenting to find a reasonable look to the application, so that the buttons’ purpose was obvious. The idea of laying the buttons out in the form of a crane came up as a solution to the manual control interface.
This was attempted (Figure 17), but did not prove very successful. Although the buttons would then have been labelled, the feel did not have enough impact to pose an impressive demonstration. But an idea that did stick from this design was that of movement-lock buttons. These are buttons that do exactly the same as their non-toggling counterparts, but only send one command per click.
With the normal push buttons, a command is sent to engage in that direction when the button is clicked, and when the mouse button is released, another command is sent – to stop movement in that direction. The toggle-buttons could be clicked to allow movement to continue in that direction (and other buttons to be operated) until they were clicked again, at which point the command to stop in that direction would be sent.
This was an easy way of implementing semi-automatic control, without the need for further functional development at either the Crane RCX brick stage, or the RMI Server stage.
Figure 18 - Final Swing Applet: Manual Control
The manual-control layout was decided upon, using the Java Swing Library. This library allows applications/applets to have the same look on all operating systems, as well as providing a TabbedPane, used to hide options until they are requested. This TabbedPanel is shown in the picture (Figure 18), where the manual-control option has been selected. This was the final design, and although it does not prove very intuitive, the Java Swing library provides Tool-Tip features for most components, and these are used in the application. This means that new users need only hover over a button for a moment to find its purpose.
The darkened buttons are three of the toggle buttons, which are at the moment signifying (clockwise from left) “keep turning clockwise”, “keep retracting the gantry” and “keep lowering the jib”. The smaller buttons are the purely manual control buttons. These give mouse control over each of the degrees of freedom. With these buttons, only when the mouse is pressed will movement occur.
The three tabs at the bottom allow switching between the three control modes: manual, positional and automatic. The red button in the middle of the screen is the emergency stop button, which is a push button which invokes the special CraneSever emergency_Stop() function.
When the panel is switched to Position Control, the application looks like Figure 19. In this mode the three position values from the crane are output on the right labels. In the textboxes on the left, the requested positions can be entered. When return is pressed after entering values into these textboxes, the crane is told to move to that position. The “refresh” button at the top of the screen requests position values from the crane, and displays them in the appropriate labels.
When the application is just started (as in Figure 19), the “present” text labels read “???”. This is to signify that no values have been received from the crane yet.
Figure 19 - Final Swing Applet: Position Control
The Scrollbars in the Position Control mode of the application were never connected to ActionListeners, and so these are merely Scrollbars which do nothing. In the fully developed version these Scrollbars would request that the crane move to a certain position.
When Automatic Control is selected (as in Figure 20), a selection of Buttons allows the engaging of certain automatic sequences. Due to the lack of time left for development, only one of these buttons was implemented. This “Return to Home Position” Button, the crane returns to its origin.
Figure 20 - Final Swing Applet - Automatic Control
Due to the way in which this application was developed using JBuilder 3.0, most of the application is actually in the class mainFrame. The class that runs this Frame is called CraneApplicationSwing, and merely manages the construction of mainFrame, and centres it on the screen.
Unfortunately, although it is a very powerful package, Java Swing does not understand the logical links between buttons. This meant that throughout the mainFrame class it was necessary to employ continuity-tricks. For example, if the emergency stop button is depressed, then the toggle buttons must have setSelected(false) run on them, to make sure that they pop-up from the grey pressed position.
The listing of the mainFrame.java source file can be found in the Appendix. The components used in the application are listed between lines 42 and 92. This is a lot of components, and is all merely things such as Buttons and Labels. Between lines 164 and 577 these components are initialised by JBuilder’s jbinit() function.
When a component is added in JBuilder’s RAD environment, it is defined as a base component, such as a JButton, Button, or Label. Then its initialisation is automatically placed in the jbinit(). This is an inefficient procedure, as it means code such as upButton.setLayout(null) is repeated for all components. If the source were to be entirely programmed by hand, some data-structure of all components could be incremented through, setting their Layout.
These inefficiencies in the source could have been rectified once the RAD development was over with, but the time constraints that occurred towards the end of the implementation phase meant that this “tidying” of the mainFrame.java code was never accomplished. However, to make the code readable, the ActionEvent definitions, and definitions of the crane-calling functions are all placed outside this jbinit() function, and can be found from lines 587 onward.
These problems are why the jbinit() function is so long – as JBuilder creates these lines itself. It is also the reason why the compilation of mainFrame spawns 22 mainFrame$xx.class files. These house the anonymous inner classes which were the easiest way of adding ActionListeners to these components, after their initialisation had been written by JBuilder.
5 Implementation and Integration
5.1 Implementation Plan
The construction of the Lego crane will be done in several stages. Firstly, the tower and base will be built, ensuring it is a strong and stable structure. The rotational drive unit and crane arm will then be constructed and attached to the tower. The vertical drive unit and jib can then be constructed and added to the arm.
The following sections of the software can be implemented at the same time, as the interfaces between the sections were defined in the design.
· The client software
· The RMI and server software
· The communications and RCX software
The sections should be integrated early in their development to identify any problems with the interfaces. This can be achieved by implementing only the manual control operations of the crane at first and ensuring that all sections interface correctly. The position control operations of the crane can then be implemented and the final system tested. Also, this ensures that from early on in the development of the system, there is a working system that implements a subset of the operations, should time run out before the full system is completed.
5.2 Implementation Problems
As the construction of the crane proceeded, it became clear that there were insufficient Lego pieces for the completion of the structure. This delayed the completion of the crane by several days, while waiting for parts to be delivered.
As the different components of the crane were added to existing structure, deficiencies often appeared in previous work. This led to rebuilding, strengthening and in more serious cases complete redesign of sections of the crane. In the end, not a single part of the crane structure is of the original design.
The arm had to be redesigned as it was not strong enough, bending at the end. The base then had to be redesigned to handle the increased weight of the arm. The rotational drive unit underwent several redesigns as the original design could not move the weight of the arm.
The software implementation and integration went as planned with no major problems.
5.3 Testing Strategies
The client software can be tested, with simple code stubs displaying text in place of the RMI method invocations.
The RMI code can be tested with a driver program and stubs.
The low-level communications and NQC code can be tested with motors and sensors attached to the RCX, to provide instant feedback
Each code module was tested thoroughly to ensure that it operated as expected.
The following test sheet was used to test the final system. The set of operations chosen provided a reasonable sample of possible inputs. If the operation produced the correct result a tick was placed next to the line.
Test Schedule for Lego Tower Crane
Power on bricks
Start program 1
Start CraneServer
System should return to 0 0 0 -(refresh)
Rotate to 120 -(refresh)
Extend to 40 -(refresh)
Lower to 40 -(refresh)
Rotate to 240 -(refresh)
EMERGENCY STOP -(refresh)
Rotate to 240
Extend to full extent -(refresh)
lower to lowest point -(refresh)
Go to home -(refresh)
EMERGENCY STOP -(refresh)
Go to home -(refresh)
Rotate to 180 -(refresh)
The testing strategy uncovered some minor bugs in the system, which were fixed in time for the product demonstration.
6 Status Report
6.1 Client Application
The Client end application is called CraneApplicationSwing. Originally, the team had specified an applet to allow control of the crane. This was not achieved, but would be possible with minor changes to the top-level software.
An Application was constructed, which was to be used initially, and then upgraded to an Applet. This upgrade did not occur, due to the constraints of time. The user interface was, however, operational. As an application, it could not be inserted into web pages, but this meant that it satisfied the condition of being able to run on any remote machine with Internet Access, in that the remote machine no longer needed to house a web browser. [Although, it is necessary for the computer to have JRE1.2.X or later.]
However, for the visual feedback needed to demonstrate that the crane is working, it is necessary for the remote computer to house a Web browser, used to view the feed from the digital video camera. This is because the video viewer we used was an Applet!
Since the client application only attempts to connect to the Crane Server at start-up, if the error “I'm sorry, but an error occurred while starting this application” or “Sorry…Could not connect to Crane Server” occurs, then the application must be restarted after the user has fixed the problem (which is either that the Crane Server is not running, or that the user is not on-line). This application-restart would not be necessary if a pop-up box was spawned, allowing the user to correct the error, before retrying to connect to the crane.
Another deficiency with the client application is that the buttons are not set out very intuitively. It was found to be very difficult to arrange them so that their functionality was obvious, but this could be aided by graphics. What prevented the use of graphics in the application was only the time constraints involved. In a previous Applet version of the system, which was being tested before the RMI package was fully understood, the Button class was overridden to draw an image on its surface. This could be employed in a future version of the Swing application, or a Swing Applet. The trouble here, though, is that the picture would have to make the meaning of each Button obvious.
An alternative to placing pictures on the Buttons would be to simply place images of the crane on the panel the Buttons were on. This could, perhaps, be a plan view and side view of the crane. Then the Buttons could be placed around it at appropriate locations, showing intuitively what they each do. For example, the jib-raising button could be placed just below the outer end of the gantry on the side view.
For future development it should be on easy job to simply make mainFrame an Applet, as opposed to a Frame. This mainApplet could then be run from inside a web browser. Only time constraints prevented the team from developing the Applet version of the client’s user interface.
There is a small problem with the client software as it stands. At the moment, if multiple people log on to the Crane Server, and send commands to the crane, all the commands will be acted upon. This may not be a problem in itself, as this may be the user’s expected outcome. However, it does mean that the state of the buttons in each user’s application is no longer in continuity with what the crane is doing. To rectify this, the Server could be updated to only allow one instance of CraneServerImpl, so that only one user can give commands at a time. Alternatively, the application should be able to request what the crane is doing – something which is not possible with the current system. This information could then be used to update each users application. The most efficient way of achieving this may be for the crane to send out a message to all users when it receives a command, thus always letting all the User Interfaces know what the crane is doing.
The jbinit() function should be made far smaller. At the moment it spawns some 22 anonymous inner classes (which appear as mainFrame$xx.class files when mainFrame is compiled). This is very inefficient, as most of these classes have very similar features, and generalised classes could be used to improve the amount of disk space used by the program. Thus generic MouseListener classes should be created to reduce the disk space used.
Another idea that was never implemented was the introduction of a 3D map into the system. This would have allowed the crane to dodge obstacles in its path as it followed the control of its users. It would also have led to the possibility of placing objects in it’s environment which it “knew about”. This would allow it to pick objects up, move them around, drop them again and still know where they were. This would certainly have made an impressive demonstration, but would have taken much more time than we had to complete the project.
One of the main features of the demonstration that was not implemented, was the use of an electromagnet as the crane’s jib. This would have allowed the crane to move (metallic) objects about without the need for human assistance, and would have integrated well with the use of a 3D map. Time was not the only reason that an electromagnet was not used. The main reason was that we could not find a suitable electromagnet. The team constructed various preliminary models, some of which could pick up paper clips, but none we’re strong enough or sturdy enough to put on the crane. Safety was also an issue here, as the preliminary electromagnets drew a high current, and often generated a substantial heat.
The third panel in the application allows for Automatic control of the crane. Only one automatic feature was developed in our system (the “Return Home” capability), however other command sequences need only be dropped into the mainFram.java code to carry out pre-defined tasks. This could take the form of a small sequence to send the crane to specific coordinates, or a sequence of instructions to show the crane’s mobility.
6.2 RCX Server
When the Crane is calibrating, it may be advisable to introduce some randomness to its direction of turning to zero degrees. At the moment the RCX software always turns it clockwise, which tends to make the wires in the tower get twisted together. A better development would be to keep a count of rotations that have been executed. If a maximum number was exceeded, it could unwind itself, or even unwind itself each time it was shutdown.
The COM port used for communication with the crane was hard wired due to time pressure. This could be rectified in later development, allowing the IR transmitter on the crane-controlling PC to be plugged into any available COM port, and the appropriate port set as the one used for communication with the RCX bricks.
Also this COM Port is left open all the time that that the crane is available for communication. This is not necessary, and wastes the 9V battery power source that the IR tower uses. In future development, a COM-port close function could be implemented, which along with saving this battery, would prevent IR interference with any other IR sources in the vicinity.
Communications with the Bricks could be improved by queuing messages, such that messages do not interfere with each other, and such that all commands sent to the bricks are properly dealt with, and in the correct order they were given.
With minor modifications to the communications code, the accuracy of the position control software could be improved. By increasing the message length from one byte to multiple byte messages, more accurate degree-conversions, and more accurate positioning of jib and gantry could be achieved.
6.3 Lego Construction
The team’s use of a reed-switch to detect the jib’s height was very successful. The team therefore suggest that the same technology should be used to detect the 0°-passing of the gantry as it rotates. This is due to the fact that the present Touch Sensor is inadequate for the task, being hard to situate, and being far too clumsy to detect the gantry’s passing satisfactorily.
7 User Guide
7.1 Server
In it’s current implementation, the server system is situated on the computer “Boreray” in F101, Lillybank Gardens, University of Glasgow. This is the development server. If it was desired to use this system elsewhere, a version could be produced to do this relatively easily. An install routine could be created to automatically set up the system. This would be required, as the setup is relatively complex, with a web server, camera server, RMI server and the crane server to be installed. Various web addresses within the web page would also need to be altered.
At present, the address of the server is hard coded into both the client and server software. Therefore the server cannot be run on another machine without recompiling the client and server software.
To start up the server, execute the following steps:
- Boot the PC to the windows desktop
- Ensure that the webcam is connected to the parallel port and that the power lead is connected inline with the keyboard lead. Ensure that an Infra Red tower is connected to COM1 and has a good battery in it. Place the base of the crane within 3 feet of and at the same level as the IR tower. Turn on each of the four RCXs in turn. Check that they have program 1 selected and press run on each (the green button). This assumes the RCXs have the latest version of the NQC code on them.
- Run the apache web server by double clicking the “Start Apache” shortcut on the desktop.
- Start the web cam server by clicking the “Webcam” shortcut on the desktop.
- Start the crane server by double clicking the “ESE3 Crane Server” shortcut on the desktop. This should open two DOS windows. The first should be empty, but with RMIREGISTRY in the title bar. This is the RMI registry, which is used to make the crane’s services available to remote users. A second DOS window should open with the crane server program. Various diagnostic messages will be output to this window. On startup, the jib should raise, the arm retract and the gantry rotate to zero. Once it has reached zero position, the server will be ready to accept remote clients.
While the system is running, various diagnostic messages may be printed to the DOS window. These are simply to aid in diagnostics of the system and occur during normal operation.
7.2 Client Application
7.2.1 System Requirements
Minimum Internet Connection of 56k Baud Modem to allow video feed.
Java.Swing and Java.RMI support. These are both in the Java 2 SDK (1.2), and are available free from Sun Microsystems’ website[4], however it is not necessary to have the SDK, and all that is needed is the Java 1.2.2 Runtime Environment.
7.2.2 Installation of Application
The zip file containing the compiled class files must be downloaded from the crane website. This can be unzipped into any directory on your class-path.
7.2.3 Running the Application
Simply go to the directory where the *.class files are installed, and type
java CraneApplicationSwing.
This initiates the application. If the error “I'm sorry, but an error occurred while starting this application... The crane could not be contacted.” appears at the command prompt (followed by a java stack trace), then you have not been able to connect to the crane (see Errors below).
7.2.4 Errors
If either of these errors are printed to the screen, the application will need to be restarted. To prevent them from occurring again, you should check that you are connected to the Internet. If the error still persists it is due to the fact that the Crane Server is not running at that time…
“I'm sorry, but an error occurred while starting this application...” or
“Sorry.., Could not connect to Crane Server.”
8 Project Logs
8.1 Team Log
This log details the major events and milestones of the project. A more detailed log is available at the project website : http://www.dcs.gla.ac.uk/legolab/TeamB99/team2home.htm
|
Date |
Event |
|
1/11/99 |
Began to examine Lego Mindstorms software and hardware |
|
3/11/99 |
Experimented with simple models from the “constructopedia” and the simple built in programming language. |
|
10/11/99 |
Allocated initial areas of investigation to team members |
|
19/11/99 |
Discussed initial project ideas with supervisors |
|
25/11/99 |
Decided on building a crane |
|
30/11/99 |
Simple prototype crane built – only vertical and horizontal motion |
|
2/12/99-3/12/99 |
Developed control program for the crane using Visual Basic. Demonstrated the crane and control program to Chris Taylor of the Smith Group and various members of staff. |
|
5/12/99- 15/1/00 |
Investigated the different subject areas e.g. languages for the RCX, hardware limitations. Began writing evaluation report |
|
17/1/00 |
Finished evaluation report and submitted. |
|
21/1/00 |
Gave presentation to supervisors on the results of the investigation |
|
26/1/00 |
Gave presentation to members of staff and other interested parties on the capabilities and potential of Lego Mindstorms |
|
28/1/00 |
Continued with development of the basic crane structure. Lack of parts is extremely restrictive. Modular tower cell designed. |
|
04/02/00 |
Got several new Lego kits, so building of the crane continued. |
|
11/02/00 |
Rotation is now functional, as is horizontal movement |
|
14/02/00 |
Crane is now operational in all three directions. Work on the software can really get under way now. |
|
16/02/00 |
Software architecture designed. Crane arm was rebuilt to make it stronger. Simple visual basic program developed to send immediate mode commands to test the crane. |
|
17/02/00 |
Major parts ordered from Lego arrived. Added three more modules to the tower. |
|
19/02/00 |
Began major modifications to the turntable unit, base and arm. |
|
21/02/00 |
Demonstrated simple Mindstorms robots (from the constructopedia) at the Computing Science Applicant Day. |
|
22/02/00 |
Finished redesign and build of the arm. Redesigned the turntable drive unit using a worm gear. Connected arm to turntable and threaded cables down through the shaft. Began experimenting with message passing between Java applications using the Java networking API |
|
04/03/00 |
Got the IR communications between the PC (Java) and RCX (NQC) up and running. |
|
10/03/00 |
Decided to use RMI instead of sockets. |
|
11/03/00 |
Redesigned the base again. Took several attempts to get a viable design. Ended up with the final design based around four RCXs. Controller class developed to provide access to the IR communications layer for the server program. Server program and simple client developed. Ran the server on one PC and the client on another. It was then possible to control a simple buggy (using just 1 RCX) from the client machine. Hooked up the whole system using three RCXs and attempted remote control – worked perfectly. Set up webcam using Microsoft Netmeeting and were able to view and control the crane from a remote location. |
|
13/03/00 |
Redesigned the rotation mechanism (again). Produced a much more reliable and smooth mechanism. Automatic positioning code (client and server side) developed. |
|
14/03/00 |
Improved the accuracy of the positioning system. Added the emergency stop button to interrupt the system while in transit. Attempted to add automatic position feedback to the client. Encountered lots of problems. Reverted to manual position retrieval. Set up web cam server and web server. Created a web page to host the video feed applet and (eventually) the control application. Began conversion of the control application into an applet. |
|
15/03/00 |
Demonstrated the current system to the project supervisors. |
|
21/03/00 |
Demonstrated the completed system at a department open day. Attracted a lot of attention. |
8.2 Individual Logs
8.2.1 Robert Adie
|
Date |
Item |
|
1/11/99 |
Installed Lego Mindstorms software and began experimenting with it. |
|
3/11/99 |
Built simple lego robots from the constructopedia. |
|
5/11/99-20/11/99 |
Continued experimenting with Mindstorms and researched the subject on the web. |
|
25/11/99 |
Experimented building tower sections for the crane body. |
|
26/11/99 |
Researched lego cranes on the web |
|
30/11/99 |
Designed and built the prototype crane |
|
2/12/99 |
Developed the crane control application along with Stephen and Dave |
|
3/12/99 |
Demonstrated the prototype crane to Chris Taylor (Smith Group) |
|
4/12/99- 17/1/00 |
Continued research and experimentation. Wrote various sections of the evaluation report:
|
|
21/1/00 |
Prepared (partially) and took part in presentation of results to the project supervisors. |
|
25/1/00 |
Installed Red Hat Linux on spare PC. Installed legOS and attempted to compile simple program. |
|
26/1/00 |
Gave presentation to interested parties. Looked into turntable designs. |
|
27/1/00 |
Experimented with simple electromagnet. Cut up iron nail and bent into horseshoe. Wrapped with approx 100 turns of enamel coated wire. Was able to pick up a paperclip, but not much more. |
|
16/02/00 |
Rebuilt crane arm to make it stronger. Designed software / communications architecture |
|
17/02/00 |
Built another 3 modules for the body of the crane |
|
19/02/00 |
Modified turntable, base and arm |
|
22/02/00 |
Finished rebuilding arm and tested it. Experimented with Java sockets programming |
|
10/03/00 |
Experimented with RMI for communications between Java programs. |
|
11/03/00 |
Redesigned base. Wrote server program to take remote commands and pass them onto the Controller class. Tested the system and set up a web cam. Tested controlling the crane over the webcam. |
|
12/03/00 |
Evaluated web cam server software. Modified RMI server to pass position values back to client. Experimented using Applets and RMI – encountered various security issues. |
|
13/03/00 |
Redesigned turntable power train. |
|
14/03/00 |
Evaluated various web servers to host the video feed applet and web page. Finally settled on Apache and installed it. Set up web site with video applet. Experimented with Java applets downloaded from the web server using RMI. Designed simple WAP page – able to access it from a windows based WAP browser, but not from a WAP mobile phone. Possibly problems with Orange? |
|
15/03/00 |
Demonstrated the final system to the project supervisors. |
|
17/03/00- 03/05/00 |
Wrote this final report and prepared the project presentation. |
8.2.2 David Loudon
|
Date |
Item |
|
1/11/99 |
Began experimenting with Lego Mindstorms. |
|
3/11/99- 7/11/99 |
Constructed simple Lego robots from the Constructopedia and ran sample programs. |
|
8/11/99-9/11/99 |
Familiarised myself with Visual Basic and wrote simple programs to control the RCX from the PC. |
|
10/11/99- 24/11/99 |
Researched, using the web, the available software for running programs on the RCX and controlling the RCX from a PC. |
|
2/12/99 |
Developed the crane control application along with Stephen and Rob |
|
3/12/99 |
Demonstrated the prototype crane to Chris Taylor (Smith Group) |
|
4/12/99- 17/1/00 |
Continued research and experimented with the various software available. Wrote various sections of the evaluation report:
|
|
21/1/00 |
Prepared and took part in presentation of results to the project supervisors. |
|
24/1/00 |
Experimented with various tower sections, testing for strength and stability. |
|
25/1/00 |
Started to learn how to use legOS. |
|
27/1/00 |
Tried to set up communications between RCX running legOS and the PC. |
|
16/02/00 |
Designed software / communications architecture |
|
17/02/00 |
Abandoned the use of legOS in favour of NQC as the communications between the RCX and the PC were going to take months to write. |
|
19/02/00 |
Modified rotational drive unit. |
|
25/02/00- 10/03/00 |
Experimentation with Java communications on the PC talking to the running RCX program. |
|
10/03/00- 14/03/00 |
Wrote NQC code for the three RCXs and the Java communications code which runs on the server. |
|
14/03/00 |
Integrated my code with the rest of the system and tested final system |
|
15/03/00 |
Demonstrated the final system to the project supervisors. |
|
17/03/00- 03/05/00 |
Wrote sections of this final report and prepared the project presentation. |
8.2.3 Stephen King
|
Date |
Item |
|
1/11/1999 |
First meeting. At this point we planned when meetings would take place, and started to think about what would make for a good demonstration of the Lego Mindstorms kit. Over the next few weeks we acquainted ourselves with the Mindstorms kit, and made many of the models which are documented in the Mindstorms’ Constructopedia[5] |
|
3/11/1999 |
Installed and loaded the Robotics Invention System CD. Unfortunately it did not yet work on our computer. |
|
4/11/1999 |
To install software on the RCX Bricks we used the other teams computer and the RIS CD. |
|
8/11/1999 |
Experimented with Visual BASIC. Programmed a simple graphical program, which did not talk with the RCX. |
|
10/11/1999 |
Decided on who should be doing what. I was to research the educational potential vis-à-vis it’s use in practical labs, the computer concepts it could demonstrate, how it could be used to enthuse schoolchildren at Open Day demonstrations, and how it could get important engineering concepts across. David and I were to research the sensor capabilities, and discover how easy/cheap it would be to custom-build sensors for the RCX Bricks. |
|
19/11/1999 |
Met with Supervisors, and explained that our project ideas so far were to
|
|
25/11/1999 |
Officially decided to build a crane. It was to be able to pick things up (our idea was a grabber arm), and be controlled by hand, then controlled by computer, then possibly eventually learn to control its self. |
|
1/12/1999 |
Began programming Visual BASIC application to control Crane. This allowed manual control. |
|
3/12/1999 |
First Crane Demonstration – To Chris Taylor of Smith Group. Showed the crane being controlled by my Visual BASIC program. |
|
8/1/2000 |
Researching Mindstorms to this date I have found it could be used to show Artificial Intelligence, Host-Target debugging, networking, as well Analogue/Digital conversion and machine code programming. |
|
17/1/2000 |
Handed in Evaluation Report. My contributions were…
|
|
21/1/2000 |
Did PowerPoint Demonstration, showing my research into the sensor capabilities of Mindstorms, and their operation. |
|
24/1/2000 |
Built motor-Rotation sensor gearing combination for
turntable of crane. Spent next few days getting operational turntable, etc. I noticed that when the crane turns it’s wire gets wound
up, and observed that if we program it so that it will only rotate so far in
each direction it would not tangle. Also observed the need for a touch sensor
to calibrate the rotational coordinate. |
|
26/1/2000 |
Had idea of using an electromagnet as the crane’s jib, thus allowing it to pick things up easily. Experimented with gantry designs. Built a gantry which secured to Robert’s turntable. It housed a rig which was held up by string, and pulled along the gantry. Set up touch sensors at each end of gantry to detect rig’s presence. Also designed rig, to allow the electromagnet to be raised and lowered. Found that string could not keep the rig up well enough to always make contact with Touch Sensors. Also, tightening the string meant the gantry would no longer move along it. Also the gantry was not very sturdy – Had the idea of holding up the gantry with string tied to a pivot point above the tower – but this was too complicated. |
|
10/2/2000-on |
Decided that the touch sensors that detected the jib hitting either end of the gantry could be wired together to the same RCX input, as knowing what direction the jib is travelling, we can easily deduce which switch is actually being hit. |
|
|
Read NQC documentation, and wrote a basic NQC program to control rotation of the crane. Found that NQC allows easy multitasking capabilities. |
|
|
Started developing the crane application in Applet form. I used LayoutManagers to give it an appropriate look and feel. Created many separate Applets which used hierarchies of instances of LayoutManagers, to allow a reasonable UI. The team did not think that these Applets had the right feel, and so it was decided to use a RAD to develop further. I researched into how to play a movie in an applet (to allow a Web-cam), but could only find out how to paint a still image to its surface. |
|
|
Got a shareware copy of JBuilder 3.0 Foundation. This allowed the creation of Java Swing Applets, and had a Rapid Application Development environment, which meant that Components could be placed anywhere. Unfortunately, we now found that there were issues we did not understand about the use of the Java RMI in Applets, and could not get Applets to use RMI. At this point I made the decision to make an Application, although I did believe that once the application was complete it could be easily converted to an Applet |
|
15/03/2000 |
Demonstrated the final system to the project supervisors. I demonstrated the Application, which worked. |
|
17/03/2000- 03/05/2000 |
Wrote this final report and prepared the project presentation. |
9 Abbreviations and Glossary
9.1 Acronyms and Abbreviations
CAD: Computer Aided Design
CVS: Concurrent Version System.
ESETP1: Electronic and Software Engineering Team Project
HTTP: Hyper Text Transfer Protocols
IR: Infrared
ISP: Internet Service Provider
Lego: Company that builds and sells the Mindstorms kit.
legOS: LEGO Operating System
LCD: Liquid Crystal Display
JVM: Java Virtual Machine
KVM: K Virtual Machine
NQC: Not Quite C
RIS: Robotics Invention System
RCS: Revision Control System
RCX: Robotic Command Explorer
RMI: Remote Method Invocation
TCP/IP: Transmission control protocol/Internet Protocol
Tx/Rx: Transmitter/Receiver
10 Appendices