Subject:
|
Re: direct manipulation of bits in RCX registers using NQC
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Tue, 13 Sep 2005 13:53:27 GMT
|
Viewed:
|
5664 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Mathew V. Jones wrote:
> > the standard firmware implements a "virtual machine", and so
> > you don't generally have access to physical registers.
>
> I'm not sure if I get this...
>
> ...OK, so the "bits 0-2 of 'port 6'" part comes from reading
> the "RCX Manual" I found here:
> http://legolab.daimi.au.dk/DigitalControl.dir/RCX/Manual.dir/RCXManual.html
From a brief reading of that manual, it talks about programming the H8 chip
inside the RCX *directly*, not running programs layered on top of the standard
firmware. And if you want to use NQC, you have to work within the limits of the
standard firmware (OK, ignoring Dick Swan's firmware, which I've still not been
able to use - I'm on a Mac as well, and MacNQC doesn't support it I think).
> Apparently, this information is either out of date, or never applied to the
> basic 2.0 firmware in the first place.
The standard firmware shields you from this low level register manipulation
in most cases. Good if you're a programming clutz like me.
> > Why do you need to do this?
>
> ...trying to improve the sensitivity and range of object
> detection, using the difference between active (i.e., LED on)
> and passive (i.e., LED off, corresponding to ambient light
> levels) sensor readings. I'm sure you've heard it all before.
Which doesn't mean I have no interest in the subject, or nothing to learn
from it. I was looking over some of my code that does just this the other day,
to puzzle something else out.
> I need to do physical shielding, but now that
> I've got the scent of bit manipulation, I'm
> barking up a different tree).
I've been using a system that actually works pretty well (easily detects a
wall at a couple of feet anyway). Instead of looking for the light sensor to
just get brighter, try taking a reading from the light sensor, and then execute
a SendMessage and *immediately* take another reading from the light sensor. This
way (if you watch the timing - a SendMessage takes slightly under 50 ms) you
always have a sample of the "ambient" level and a sample of the "reflected"
level to compare. It works much better, and in much wider ranges of light
levels.
And you can improve it well beyond there. Take several samples of the
reflected light levels, and average them... or better yet, take the maximum. And
there are better options than SendMessage as well, that can improve the response
a lot.
> Any additional suggestions about improving light-based
> object detection would also be appreciated.
If you just want "a solution", that can be provided:
http://news.lugnet.com/org/us/lrgoaa/?n=25
But even that's not optimized as far as you can go.
--
Brian Davis
|
|
Message is in Reply To:
13 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
