To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.robolabOpen lugnet.robotics.rcx.robolab in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / ROBOLAB / 261
260  |  262
Subject: 
Re: Robolab, byte codes and assembler
Newsgroups: 
lugnet.robotics, lugnet.robotics.rcx.robolab
Date: 
Sat, 29 Nov 2003 10:31:58 GMT
Reply-To: 
Dick Swan <dickswa@sbcglobal.NOSPAMnet>
Viewed: 
3895 times
  
Following up from my earlier post, I have completed a firmware
patch for the rotation sensors. This post contains the patch with
installation instructions followed by a technical description.

A long post but hopefully more than made up by the value of the
patch. I welcome feedback on your experience on whether you
experience improved rotation sensor performance.

Installation Instructions:
=========================

The instructions tell how to eaasily modify Lego's firmware download
file so that you can subsequently download on your RCX. {Sorry if
you find instructions a little verbose but I'm targeting user at all
skill levels).

1. Find the firmware download file (firm0328.lgo) on your computer.
   There may be multiple copies if you use Lego's SDK. The version
   used by the RIS software on my computer is in folder.
   "C:\Program Files\LEGO MINDSTORMS\RIS 2.0\script\Firmware".

2. Make a copy of firmware file so that you have an unpatched
   original.

3. To install the patch, you'll be replacing three groups of lines
   in the original firmware file.

4. Find the line beginning with 'S1138010...' and replace with
S11380106DF46DF56DF61B877901F0007903D600D8

   THe format of the data on this line is:
   'S1'   indicates that this is a record containing a four byte
          address followed by a bunch of data bytes.
   '13'   indicates that there are 13 hex (19 decimal) bytes in
          this line
   '8010' is the hex address of the first data byte
   ...    a bunch of data bytes
   'D8'   checksum for this line.


5. Find the line beginning with 'S11383D0...' and replace with
S11383D0086E96105E00F0100B870CEE47045A00EE

6. Find the block of lines beginning with 'S113D600...' to
   'S113D6E0...' and replace with
S113D6000000000000000000000000000000000016
S113D6106DF26DF16DF00D606F7100086E1A00010E
S113D620AAE00000470C6DF10D065E0014C06D7198
S113D6304004550C19666D706D716D7254705470A0
S113D6406DF66DF56DF46DF30C8E0D140CED18552F
S113D65079020002195209226F26FFE06FC6000208
S113D6600C6E1866AEB0440CAE70440418EE400E56
S113D670FE01400AAEF04404FE024002FE030CE642
S113D6806E5EEF32100E100E086E18666E68F0B003
S113D69077781E006F41000409016FC100046E6EAB
S113D6A0F0D06EDEEF326D736D746D756D765470FF
S113D6B00000FF00FF000001010000FF00FF000068
S113D6C00000FF02FF000001010000FF02FF000054
S113D6D0000402030001050300060203000107031E
S113D6E0000402030001050300060203000107030E

7. Save the file. The Lego Mindstorms software looks for the
   filename 'firm0328.lgo' so you have to overwrite Lego's
   original file. Some programs (NQC, BricxCC) allow you to
   specify the file name so that you could use a different name.

8. Download the firmware. You now have (hopefully) dramatically
   improved rotation counter performance with no dropped counts.


Replacement Rotation Counter Algorithm
======================================
The patch completely replaces the ROM firmware handler for rotation
sensors. Regular ROM handler is used for other types of sensors.

The rotation counter has 16 counts per revolution. Internally there
are four cycles of four quadrants per revolution. This is explained
in more detail in several historical posts. Going clockwise, the
quadrants are 0, 1, 3, 2, 0, ...

The replacement rotation counter implements a two stage state
matchine. There are eight states: 4 possible "quadrants", each with
two states (stable, ambiguous). A table lookup on the current state
and current position determines the next state. A second similar
table lookup determines the change (+2, +1, 0, -1, -2) in rotation
value.

Some transitions are amibiguous. Quadrant 3 is raw value > 959.
Quadrant 1 is raw value 447-703. Quadrant 2 is 704-958. Erroreous
counts occur when in quad 3 and moving CCW (CounterClockWise) to
quad 1 but reading shows up as quad 2. An algorithm, like that used
by ROM firmware, that ignored these transients would +1 to the
counter. The state machine implementation treats the 3->2 as
ambiguous and "waits" to see what the next changed quadrant is; if 0,
then CW movement and add +2 to counter; if 1, then CCW movement and
add -1.

Feedback on patch performance is desired. I don't normally use the
standard Lego firmware or Windows GUI. I have tested the algorithm
pretty extensively in my firmware environment. However, in porting to
Lego's firware with this patch, I only did cursory testing to
ensure that the rotation sensors were working and that the firmware
didn't appear broken.


Rotation Counter Performance:
=============================
I've been using this algorithm for over a year. My original testing
including something like a 5**5 downgearing so that I had one
revolution (16 rotation counts) every 15 minutes and sensors scanned
every 1 msec. I ran this overnight without any errored counts.

More recently, I have been stressing the algorithm at the high end
as I develop a very fast dead reaconing robot. I run A-to-D interrupts
every 0.5 milliseconds and get reliable operation at over 1,300 counts
per second. I repetitively get 0.1 inch lateral deviation at the end
of
a five foot straight line run using a PID motor speed algorith and
using a slow enough speed to avoid skidding,

My nornal software runs the actual algorithm at interrupt level. I
wasn't able to do this in the patch; that seemed far too complicated
to try to figure out. I also dropped out code that I used to count
"debounced" glitches and error conditions (e.g. rotation speed too
fast so that moves two quadrants between consecutive readings).


Lego Software is Slow!
======================
Not really related to rotation counter, but just some general
observations.

I hadn't used the Lego Windows GUI software since I got my RCX many
years ago. Maybe my system is configured wrong, but the performance
of their GUI is dismal on my P4 1.7 GHz system. Opening pop-up
windows, opening files from their "vault" was taking seconds.

Downloading was taking "forever". Both for firmware and user programs.
I'd forgotton how slow normal transmission was vs the fast (quad
speed) downloading.

Is this performance normal? If so, I'm sure end users must find this
a "turn-off".


Patching "Technology" Description
=================================
Technical details for anyone interested in exactly how the patch
is implemented.

The actual patch is stored in RAM memory locations D600-D6E0 and
is contained in step 6 above. Subsequently, after download, this
is relocated to address range F000-F0E0. Fortunately this is currently
a block of unused RAM in the RCX.

Step 5 modifies the range of 'standard' relocated data. The firmware
programs are stored in RAM locations 8000-D515 and F100-FB7F. In the
'firm0328' file the upper block of programs is stored in in D700-
E167 and subsequently relocated to high memory after download. Step
5 modifies the relocatiion starting from/to locations from D700/F100
to D600/F000.

Step 4 patches the call tothe ROM "read single sensor program" to call
the patch instead at entry point F010. This routine looks at the type
of sensor; if not rotation then call standard ROM routine otherwise
replace with the rotation sensor algorithm in the patch.

The patch itself was really easy to port. I spent the most time
figuring out how to exactly modify the "firm0328" file.



Message has 5 Replies:
  Re: Robolab, byte codes and assembler
 
(...) Wow! This is a truly wonderful gift to the group. I know how hard it can be to patch raw binary like that. Many thanks for your efforts. I'm off to try it **now** ! ---...--- Steve Baker ---...--- HomeEmail: <sjbaker1@airmail.net> WorkEmail: (...) (21 years ago, 29-Nov-03, to lugnet.robotics)
  Patched firmware to improve rotation sensor, was Re: Robolab, byte codes and assembler
 
Hello Dick, Looks great, but it doesn't seem to work well here: - counts up 2 by 2, but counts down correctly one by one - loses count, especially when counting up. My tests were done with a brand new, unmodified rotation sensor. I mounted a wheel (...) (21 years ago, 29-Nov-03, to lugnet.robotics, lugnet.robotics.rcx.robolab)
  Re: Robolab, byte codes and assembler
 
(...) Wow, that's far more than I expected! And thanks for the detailed explanation. I may have to look at it tomorrow - my daughter's birthday is today. <snip> (21 years ago, 29-Nov-03, to lugnet.robotics, lugnet.robotics.rcx.robolab)
  Re: Robolab, byte codes and assembler
 
Could someone explain to me technically why this sort of of problem with the rotation sensor occurs? I know how quadrature shaft encoders are _supposed_ to work, and I can't see why this sort of thing should happen in the first place. >> Mark (21 years ago, 30-Nov-03, to lugnet.robotics, lugnet.robotics.rcx.robolab)
  Lego :Robolab 2.5.1 patch download
 
Hello, I purchased Robolab 2.5 from pitsco lego-dacta quite some time ago. I'm looking for the patch to upgrade to version 2.5.1, I can find the patch for 2.5.2 and 2.5.3 but not 2.5.1 or 2.5.4. Could anyone help me with this? I'm having some (...) (19 years ago, 13-Jul-05, to lugnet.robotics)

17 Messages in This Thread:








Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR