Subject:
|
Re: RCX Replacement Firmware - Performance Testing Results
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 11 Nov 2004 09:11:44 GMT
|
Viewed:
|
1063 times
|
| |
|
|
This message summarizes performance testing of the replacement firmware
compared to the Lego standard firmware. Several different NQC programs
were downloaded from the web and their performance measured. Results
were normalized so that Lego firmware had a value of 1X.
The following table summarizes the results. Overall, the performance is
close to the claim of 10X and 100X faster.
Program Lego 10X 100X Tweaked
Light Rover 1X 7.9X 58X 86X
Peeves PID 1X 8.0X 50X 87X
Peeves PID 185X
Lepomux 1X 9.4X 93X 41X
Remote Car 1X 7.6X 79X 139X
Average 1X 8.2X 88X 108X
All four programs were NQC programs downloaded from the web; each
contained 100 to 1000 lines of user code. The four columns of data
represent real time performance for four different scenarios.
The first column is the performance of the standard Lego firmware.
The next two columns contain the performance of the 10X and 100X
firmware versions when downloaded by existed Bricx IDE and compiled by
existing NQC. No source code changes.
The tweaked column contains results after only a few lines of changes in
each program to better utilize replacement firmware capabilities. The
changes include:
* Programs were simply recompiled to use new firmware opcodes. These
new opcodes pass compile time information to the interpreter to
take advantage of rather than it re-calculating at runtime. For
example:
* Separate opcode for A += 5 (constant parameter) than for A+= B
(variable parameter).
* Avoid the value check on every assignment opcode to see whether
it is one of the three special counter variables which, when
changed, may trigger an event.
Recompilation was with a new compiler.
* The Lepomux program sends messages to an I/O expander using changes
in a motor output. Delay statements had to be inserted because it
was running too fast for the hardware.
* One line was inserted into the "Remote Car" program to use the new
"wait for message" opcode. In the new firmware, this takes a task
out of the "ready to run" list until a message arrives preventing
it from being given time slices. "Wait for message" is a simple
"#define" in NQC header file.
* Variables in the Peeves program were redefined as 32-bit integers to
eliminate a time consuming subroutine. Boosts performance from 87X
to 185X.
The variations in performance boost are due to different opcode mixes
among the programs. The biggest performance gain is in the arithmetic
opcodes; intrinsic opcodes, like motor control, only have about half the
speedup factor.
Program Descriptions:
====================
A brief description of the four NQC programs follows.
Light Rover - Robot uses a light sensor to detect and avoid collisions.
Peeves PID - "Peeves" is a dead reckoning (using rotation counter)
robot. It needs 16-bit precision on the result of "A*B/C" and uses a
subroutine to perform this specialized calculation. Measurements on this
subroutine were performed.
Lepomux Signaling: Lepomux is a motor/sensor expander that sends serial
messages out a motor port. The NQC program updates the motor direction
and power so that message bits are "clocked" out on the motor PWM
waveforms.
Remote Car: This was a large NQC program from a senior's thesis at CMU.
The program tries to have two Mindstorms based "cars" cooperatively
driving the same route. Multi-byte messages were built up from standard
8 bit messages. Program has two tasks; one to receive messages and one
to interpret and drive cars. Timing was performed on the second task.
|
|
Message has 1 Reply:
3 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
