Optical Sensor Manual/Function list?
 

Hello,

I am fairly new the the Pbasic program but somewhat familiar with the langauge itself. I'm wondering if there are any manuals on the sensor programming, just a list of possible functions, variables, actions etc. I've browsed through the 350 some page manual and couldn't find anything on it.

Any clues?

Thank you in advance!

I haven't come across any manuals.

But, you just hook up the light sensors to the rc digital inputs, and check whether the input is 1 or 0, one corresponds to the signal being sent back, ours is 0 for some reason.

Well basically with that you can do an if statement and do something based on that input. There's a knob thing on the back of it to change the sensor threshold.

I'm using reference to last year's sensors, because we DIDN'T receive this years sensors yet...

I can see the light!

Okay, just a digital output, that's easy enough to work with.

Thanks for the info, proves i need to do some more research on the programming. :ahh:

optical sensor
 

:confused:
i am still a little confused. there are four wires on last year's optical sensor. one for power, one for ground, but what do the last two do?

Re: optical sensor
 

The other two are the sensor outputs...keep in mind that they are exclusive, so whenever one is on, the other is off...basically, one of them is on when the sensor sees something, and the other is on when it doesn't see anything...

This falls under the category of "search before you post".

I answered this question yesterday

ahhhhh. and thanks for including the link. missed that one.:p

Hmmmm
 

I was wondering about how a digital signal could be used to create a sort of "rating" on the strength of the optical sensor's reading. I was thinking that a BYTE variable could be used to store the eight previous readings from the sensor in its bits. Each loop would push the bits back one and get rid of the oldest reading. Would he sum of the eight bits be a rating, from one to eight, of how "strong" the sensor's reading is?

I haven't had a chance to test how accurate these things are, and I was figuring that a robot could start to do stupid things if it reacted to an extraneous reading of "1" from the sensor when there really was no reflective tape at all in its line of sight.

well, everytime you check lets say the light sensor is on...for all 8 bits.
It tells you its been there for a long time, or however long your cycles for each bit are.

Combining the bits and using that integer wouldnt really help, example input

assuming your doing right to left bit logic

all 8 bits are 1...signal 255(254 rounded down automatically in debug at least), then lets say you shift over one bit, 254(no signal 1 bit), no signal for 2 bits consecutively, 252...248...240...224....192....128....0....
I guess that would work, lets show going up input from no lights to ful lights
1...3....7...15.....31.....63.....127....255(254 rounded)

so lets say you get 3 in a row, and then 5 consecutive no signals

128+64+32+0+0+0+0+0
224... you get 224 for a run with no signal

if you have any questions about this let me know, this is just some bit logic, might help understand it

1...2...4..8.16.32.64.128.256.512.1024.2048.4096

goes right to left
each 1 in binary counts as first num and moves up
to find sum its (2^n)-1 = 256-1 = 255, its 254 on the default code because two 255's consecutively is a reset

- Ryan

Errr
 

It sounds to me like you want to measure the intensity of the light returned? If so, read ahead, otherwise, skip this post.

Quite frankly, this is <i>impossible</i>.

Why?
Because, the light sensor is a switch. It has two valid outputs: on or off. In essence, this means that it is a digital sensor, representing a binary 1 or 0: on or off.

In order to measure the intensity of the light, the sensor would have to output some value that fits into a range; say 0 to 255. That would qualify it as an analog sensor.

Hence, whenever you have something that is either on or off, it is labeled as a digital signal/sensor.

Glancing above it looks like you're trying to keep some sort of record of the last 255 states of the light sensor... I dont see how this could assist much. The resulting byte will not be an intensity measure.

To sum it all up, you can not measure the intensity of the light (no way reliably).

This can also be seen by the little schematic on the side of the light sensor (LAST YEAR BECAUSE WE HAVENT GOTTEN THIS YEAR'S GRR).

It details four connections: two inputs (V+, V-), and two outputs.

The two outputs are in a switch circuit... one is on the other is off, or vice versa.

Although some sort of variable resistor <b>may</b> be used in the circuitry of the sensor, <b>no</b> variable resistor is detailed in the schematic.

Bleh, all this rambling has gotten me off topic... it's a digital sensor, on or off, no way to measure intensity.... only to measure the intensity at which the switch flips (which reminds me there must be a variable component in there because of the wheel on the back....).

Time to explore the other threads. Hope this helps clear things up.

you could sum the values of the bits...
--------------------code-------------------
sensorPower = sensorReadings.bit0 + sensorReading.bit1 + ... + sensorReading.bit8

This would yeild a value between 1 and 8 that would increase and decrease in a linear fashion.

Technically, that doesn't really measure the "strength" it measures the duration. The sensor will give off a constant ON signal if it is directed in the right place and the robot doesn't move. The summation might be problematic when your moving, say you move, you have a raw count, it could be 11111000. Unless you count the individual bits and their chronological order, this information would be useless. You could tell when your getting closer and farther away, but it doesn't specify a direction. Without chronological order or doing each bit separate, it seems useless to count the bits.

There's a miniature dial you can turn to change the sensitivity of the optical sensor. Theoretically, if you had multiple optical sensors directed towards the same area, you could determine the intensity of the light which you're viewing with a very crude resolution. The kit comes with three optical sensors, so you can have three different intensities of light to measure, in theory.

Keep in mind that I have not tested this at all, it's just a thought that's floating around in my head, and this seemed like the best place to share it.

<edit>

But alas, this is not a photosensor. It is measuring whether or not it can see (for lack of a better term, at the moment) the reflection of its own emitted light.

This post is entirely irrelevant, and should be disregarded by anyone interested in programming for the optical sensor.

</edit>

Hmm
 

You're right, that should work...

Your idea could be used to measure intensity/distance... roughly anyways...

But, I dont think it would be very practical/accurate with only 3 sensors.. also need to consider that you might be using sensors for line following.. oh well i guess that's what the $200 for electronics is for... an array of light sensors :-)

Props on the very creative idea.

You aren't limited to the 3 optical sensors in the kit. First, you can use an unlimited amount of the banner optical sensors, per the list formerly known as the additional hardware list. You also have the $200 from digikey or Future. I'm sure you can find an optical sensor that will give you an analog signal based on the intensity.

The only reason I can think of for wanting an iffy intensity signal is to determine distance to the target.

This is more reliably done by triangulation, either using two sensors, at least one of which can be turned relative to the other, or one taking two readings of the same thing at different points along a baseline. (Aren't Physics fun ? this is about How the 'Eye' "Sees = locates" an Object (in space).)

Once you have two different signals, you can look up in a table, or grind out a computation in PBASIC (using the numeric co-processor on board the Stamp :yikes: for greater accuracy.)

To do triangulation, aren't you going to need trigonometry? I suppose you could do it with lots of IFs that simulated a sin or cosine function, but I thought that PBASIC lacked trig support. Please correct me if I'm wrong.

Trig Support
 

Yes, there is trig support

ABS - Absolute Value
COS - Cosine
SIN - Sine
DCD - set bit

weee here we go
The Basic Stamp SIN operator breaks the circle down into 0 to 255 units instead of 0 to 359 degrees. Some textbooks call this unit a binary radian or brad. Each brad is equivalent to 1.406 degrees. And instead of a unit circle, which results in fractional sine values between 0 and 1. BASIC Stamp SIN is based on a 127-unit circle. Results are given in two's complement form in order to accommodate negative values. So, at the origin, SIN is 0. At 45 degrees (32 brads), sine is 90. At 90 degrees (64 brads), sine is 127. At 180 degrees (128 brads), sine is 0. At 270 degrees (192 brads), sine is -127.

To convert brads to degrees, multiply by 180 then divide by 128. To convert degrees to brads, multiply by 128, then divide by 180.


I hope this explains it, any questions?

Re: Errr
 

Actually, it is possible if you hook up a position encoded motor shaft to that little sensitivity adjustment doo-hicky on the back and using a successive approximation feedback loop to resolve each of the bits :).

The algorithm would work like this: First you would set the doo-hicky to the 50% point using the motor. Then you would read the binary output of the sensor. This output, a one or a zero, is the most significant bit. If the bit is a one, you know that the value is between 50% and 100%, otherwise it's between 0% and 50%. For the sake of this explanation, assume the bit was a one. Now we know we can exclude the lower 50% of the possible values. So we now set the doo-hicky to 75% and read the sensor to see if the level is between 50% and 75% (a zero) or 75% and 100% (a one). This bit is the second to MSB. Now assume we got a zero which means the value is between 50% and 75%. So now we set the doo-hickey to 62.5%... Each time through the loop you get one more bits-worth of resolution.

At the heart of most analog to digital converters is a voltage comparator that's making a binary decision just like the optical sensor does. This is how successive approximation analog to digital converters work.

-Kevin

Ever heard of Rube Goldberg?
 

Rather than using three separate sensors looking at the same thing with varying gains, you could definately put a little TOO much effort into this thought.
Take a small motor. Very small. Mount a flat-head screw diver bit to it. Program it to constantly, or in some sort of pattern, adjust the gain on a single sensor, preferably with the robot stationary. That should theoretically give you the strength of the reflection, wouldn't it? Would be a LOT of fun to engineer and program, don't you think? Although, the sort of pattern used by the screw driver bit might be useful for a whole robot that lost its way. Just a late evening thought.

Ol' Rube came to mind many time while I wrote that missive :D. No, I don't expect anyone to implement the above, my point was that it wasn't impossible to do. I also wanted to tie it in with the mechanism by which some analog to digital converters do their thing.

Actually, the binary search that I described is faster (in general) than the algorithm that you've described. It only needs one time through the loop to resolve each bit. The other method requires, assuming an equal distribution of data, an average (2^n)/2 or 2^(n-1) times through the loop where n is the number of bits to resolve.

-Kevin

even easier. why not just use a photoresistor hooked to one of the analog inputs?

Yeah, this is what the sane person would do. Which approach is more fun though? :)