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 / 237
236  |  238
Subject: 
Robolab, byte codes and assembler
Newsgroups: 
lugnet.robotics.rcx.robolab
Date: 
Wed, 26 Nov 2003 19:22:01 GMT
Viewed: 
8991 times
  
Having investigated rotations sensors thoroughly, I conclude they have some
serious design flaws.  Most notably, some samples taken during voltage
transitions can be impossible to differentiate from samples at entirely
different rotational positions.  The result is occasional dropped counts.  Most
of my testing was running directly off the shaft of a motor running at the
lowest power level.  I found wide variations in the frequency of drops, anywhere
from one drop in 2 rotations to one drop in 50 rotations.

One reasonable workaround would be to average two or more samples, which would
usually (but not always) prevent the dropped counts, at the expense of reducing
the maximum motor speed the rotation sensor can handle.  I understand some of
the alternative firmwares available have made a correction like this.

My son's school is involved in a competition which requires the use of Robolab
(or RCX code, but that's a joke), so I tried to code this using a "generic
sensor adapter", which appears to successfully produce raw values proportional
to the voltages read from the sensor.  The attempt pretty much worked, but the
sampling seems to be so slow that it's unusable at reasonable motor speeds.

So, is there a way in Robolab to write a sub vi-like routine, and specify the
actual byte code instructions, just for that time-critical part of the program,
to be called by a regular Robolab program?  Sort of like writing an assembler
subroutine in Basic or C?  Or, is there another "competition-legal" way to get
more reliability from the rotation sensor?



Message has 4 Replies:
  Re: Robolab, byte codes and assembler
 
(...) Don't run it too quickly or too slowly. (URL) Um, that's all I know, besides using BrickOS which has code to make it more accurate. You mentioned that already. Actually, now that I think about it, BrickOS might be able to run assembly language (...) (21 years ago, 26-Nov-03, to lugnet.robotics.rcx.robolab, FTX)
  Re: Robolab, byte codes and assembler
 
(...) Robolab can access LASM code (Lego Assembler) which may allow you to write instructions that fit your needs. The LASM documentation is part of the Mindstorms 2.0 SDK available from (URL) not an assembler programmer so I have no idea if this (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
  Re: Robolab, byte codes and assembler
 
Hello Don, Did you had a look to my analysis of this problem ((URL) But unfortunately I don't think that my modification is "competition-legal"... I agree that sampling can occur at the wrong time, but this should not occur more often at low (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)
  Re: Robolab, byte codes and assembler
 
"Don Stauffer" <BrainChild@Skyler.com> wrote in message news:Hoz4Gp.1zto@lugnet.com... (...) <<SNIP>> (...) The rotation sensor bad counts cannot be fixed at the byte-code level. The problem is "native" to implementation in the underlying firmware (...) (21 years ago, 27-Nov-03, to lugnet.robotics.rcx.robolab)

24 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