Subject:
|
Re: direct manipulation of bits in RCX registers using NQC
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Tue, 13 Sep 2005 06:28:15 GMT
|
Viewed:
|
5967 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Brian Davis wrote:
> In lugnet.robotics.rcx.nqc, Matt Jones wrote:
Hi Brian,
Thanks for your response.
> Perhaps - but the standard firmware implements a "virtual machine", and so
> you don't generally have access to physical registers. But...
I'm not sure if I get this, because of C code examples I've seen, which I'll
discuss again below.
> You can configure the input port that the light sensor is connected to as a
> "passive" sensor (so it's unpowered) but read it out as a raw value (or even a
> percent, just like a "real" light sensor):
>
> SetSensorType(IN_1,SENSOR_TYPE_TOUCH);
> SetSensorMode(IN_1,SENSOR_MODE_RAW);
I've tried this already, and as you say, it works, but the sensitivity goes waay
down.
For a bright light shining directly into the sensor, the configuring as atouch
sensor drops sensitivity from about a 50% change in raw value to a 25% change.
So this isn't ideal.
My datalog and code are here if you're interested:
http://www.physiology.wisc.edu/jones/robotics/temp/rawvalues1.jpg
http://www.physiology.wisc.edu/jones/robotics/temp/TestLightParams2.nqc
> Why do you need to do this?
Well, it's a long and sordid story about 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. I started with using the IR
communications signal to do "pinging", while detecting the reflected light with
the LEGO light sensor block. That worked, but not as well as I want. Then I
started barking up the tree of "what if I use the LEDs in the light sensor to
'ping' instead of the IR comm port". Then I discovered that as long as the LED
is on at all, there seems to be a rather high background sensor reading,
probably from "bleedover" of light directly between the LED and the photodiode
(bad light shielding inside the LEGO block - and yes, I know that switching the
LED on and off won't fix this, I need to do physical shielding, but now that
I've got the scent of bit manipulation, I'm barking up a different tree).
> > Apparently, the power for this LED is mapped to
> > bits 0-2 of "port 6" (an RCX register).
>
> Where did you find this? In the 2.0 SDK, there is no "port 6" - the sensor
> information is listed as in "sources" 9 through 13. OK, not that this helps...
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
where it says:
********** Exerpt from "manual" ************
The three RCX input ports are connected to the channels of the A/D converter and
the output lines of I/O port 6 as follows:
Input Port A/D Channel Output Line
1 Analog input pin 2 (AN2) Port 6, bit 2
2 Analog input pin 1 (AN1) Port 6, bit 1
3 Analog input pin 0 (AN0) Port 6, bit 0"
********** Exerpt from "manual" ************
There's also C code examples there that look like this:
********** Exerpt from "manual" ************
The bits of the RCX device registers can be accessed directly by bitmanipulation
in a program written in assembly language or C. We will use C to illustrate e.g.
how a single bit can be cleared or set in a device register.
typedef unsigned char byte;
typedef unsigned short int word;
/* A/D converter */
/* A/D Control/Status Register */
#define ADCSR *((volatile byte *) 0xffe8)
#define ADF ( 1 << 7 ) /* A/D Flag , bit 7 */
#define ADST ( 1 << 5 ) /* A/D Start, bit 5 */
/* A/D Data Register A */
#define ADDRA *((volatile word *) 0xffe0)
ADCSR = 0;
ADCSR |= ADST; /* Start conversion */
while ( ! ( ADCSR & ADF ) ); /* Wait for end of conversion */
ADCSR &= ~ADF; /* Read register and clear ADF */
Port3 = (( ADDRA >> 6 ) & 0x03ff); /* Shift to an integer in [0..1023]*/
********** Exerpt from "manual" ************
Apparently, this information is either out of date, or never applied to the
basic 2.0 firmware in the first place.
Anyway, thanks for your input.
Any additional suggestions about improving light-based object detection would
also be appreciated.
Cheers,
Matt
PS: I'm new to all this, as you can clearly see. For everyone's general
amusement, see here for some of my bot attempts so far:
http://www.physiology.wisc.edu/jones/robotics/
|
|
Message has 2 Replies:
Message is in Reply To:
13 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
