Subject: Re: Robolab, byte codes and assembler - msg#00269

Previous Message by Date: click to view message preview

Re: robotics

I found an Adobe PDF describing the 'AI Motor' part in English - there is some great detail there: http://www.besttechnology.co.jp/download/INETPDF/AImanual_english.pdf Seems that this unit is a motor with an integrated position sensor and a torque sensor with a daisy-chained serial bus to allow either a PC or their dedicated micro-controller to set the motor speed and direction as well as to read back the sensors. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjbaker1@xxxxxxxxxxx> WorkEmail: <sjbaker@xxxxxxxx> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- -- Did you check the web site first?: http://www.crynwr.com/lego-robotics

Next Message by Date: click to view message preview

Universal Remote vs Lego remote

I'm very new to the whole robotics thing so forgive me if the answer to my question is obvious. Can a universal remote, the type that "learns" the function of other remotes, be used to "learn" the functions of the Lego remote? and.. If the IR tower can send commands directly to the RCX and Scout, can a universal remote be used to save additional commands? The end result being a more detailed remote, possibly with more complex commands. Possibly a macro of sorts. Has anyone played around with this? Mike -- Did you check the web site first?: http://www.crynwr.com/lego-robotics

Previous Message by Thread: click to view message preview

Re: Robolab, byte codes and assembler

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. -- Did you check the web site first?: http://www.crynwr.com/lego-robotics

Next Message by Thread: click to view message preview

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 on it and rotated it slowly by hand. The sensor works "as bad as usual" with regular firmware. I don't think I made a mistake while patching firmware... I hope you will find the problem ;o) Thanks for your time and energy, Philo -- Did you check the web site first?: http://www.crynwr.com/lego-robotics