 | | | | | |
This should be an FAQ at this point, but
I'm having trouble tracking down an answer
in the LUGNET archives.
I'd like my 'bot to measure ambient light
levels, and make light/gray/dark decisions
based on those levels.
For instance, Dave Baum's line follower 'bot
code defines gray and dark thusly:
#define CUTOFF 55
#define STOP 48
I'd like to avoid hard-coding these numbers.
Has any one done this?
Thanks,
-Tim
| | | | | | | | | | | | | | | | |
| |
|
I haven't done that yet. But if you're doing a line follower, I would suggest
the following:
1. First, build the line follower in such a way that it can rotate in place and
make the light sensor sweep out a circle on the ground as it rotates.
2. Mesaure how long it takes to rotate in a full circle.
3. Make your program start by rotating a little more than one full circle (to
account for battery voltage and motor variations). While it's doing this first
full circle, watch the light sensor and keep track of the highest and lowest
light readings you get.
4. If your robot was started on a line, it will sweep across the line once or
twice during this initial rotation, and the high and low readings will differ
by a significant amount. Split the difference between highest and lowest and
store this in a variable. This will be your "cutoff". Continue rotating until
you hit the line again and start tracking.
5. If the robot wasn't started on a line, the high and low readings will be
fairly close. Subtract a little from the low reading and use this as your
"cutoff". Stop rotating and move forward or search randomly until you find a
line.
In lugnet.robotics.rcx, Tim Rueger writes:
> This should be an FAQ at this point, but
> I'm having trouble tracking down an answer
> in the LUGNET archives.
>
> I'd like my 'bot to measure ambient light
> levels, and make light/gray/dark decisions
> based on those levels.
>
> For instance, Dave Baum's line follower 'bot
> code defines gray and dark thusly:
>
> #define CUTOFF 55
> #define STOP 48
>
> I'd like to avoid hard-coding these numbers.
> Has any one done this?
>
> Thanks,
> -Tim
| | | | | | | | | | | | | | | | |
Tim Rueger <rueger@io.com> wrote:
> I'd like my 'bot to measure ambient light levels, and make light/gray/dark
> decisions based on those levels. • [snip]
> I'd like to avoid hard-coding these numbers. Has any one done this?
Yes -- check out my RoboTag program at
http://www.mattdm.org/mindstorms/robotag.shtml
In RoboTag, the sensor is pointing at the ground, which is probably
grey/brown/white, with black border lines. My program reads the light level
at start, and assumes that it isn't on a line. This works well enough,
assuming the operator knows this. (If you wanted to make it smarter, you
certainly could.)
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | | | | | | | | | | | | |
| |
|
Matthew's program takes one reading at initialization time to
determine a baseline value. Any reading that falls 7 units
below this is assumed to be a dark line.
I take a somewhat more conservative approach, taking 10
readings over one second and averaging them to get
a baseline value. This is done once at initialization.
I then detect a dark line by testing for a
reading that is 3 below the baseline. Here's the code I've
been using to calculate an average baseline value:
-----
#define NUMBER_OF_SAMPLES 10
int i;
int runningTotal;
int averageLight;
inline calibrateLightSensor {
// Take an average light reading.
i = 0;
runningTotal = 0;
while (i < NUMBER_OF_SAMPLES) {
runningTotal += LIGHT_SENSOR;
Sleep(10);
i += 1;
}
averageLight = runningTotal / NUMBER_OF_SAMPLES;
}
-----
Then I look for the black line with code like this:
if (LIGHT_SENSOR < averageLight - 3) {
It works well. I really like getting a baseline light value
at runtime, for two reasons:
1. You might want to run your robot at different times
of day and have it work right. Hardcoded values will
probably fail you here.
2. Different light sensors produce different readings
for the same amount of light. Doing a runtime calibration
increases the chances that your program can work on
someone else's robot.
There's really only one drawback: you have to assume that
your robot is over a white part of the driving surface
when the program runs. If it's over a black line, your
calibration will be all screwed up.
Jonathan
Matthew Miller wrote:
>
> Tim Rueger <rueger@io.com> wrote:
> > I'd like my 'bot to measure ambient light levels, and make light/gray/dark
> > decisions based on those levels. • [snip]
> > I'd like to avoid hard-coding these numbers. Has any one done this?
>
> Yes -- check out my RoboTag program at
> http://www.mattdm.org/mindstorms/robotag.shtml
>
> In RoboTag, the sensor is pointing at the ground, which is probably
> grey/brown/white, with black border lines. My program reads the light level
> at start, and assumes that it isn't on a line. This works well enough,
> assuming the operator knows this. (If you wanted to make it smarter, you
> certainly could.)
>
> --
> Matthew Miller ---> mattdm@mattdm.org
> Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | | | | | | | | | | | | | |
| |
|
Jonathan Knudsen <jonathan@oreilly.com> wrote:
> Matthew's program takes one reading at initialization time to
> determine a baseline value. Any reading that falls 7 units
> below this is assumed to be a dark line.
> I take a somewhat more conservative approach, taking 10
Wow. I feel I should point out that experimentally my method works 100% of
the time. :)
On the other hand, mine is a special-case application: the light sensor is
used to read color values from a surface, which presumably will have very
little variation. If you're looking to get ambient light level in a room,
for example, the more complicated code is probably justified.
> 1. You might want to run your robot at different times of day and have it
> work right. Hardcoded values will probably fail you here.
> 2. Different light sensors produce different readings for the same amount
> of light. Doing a runtime calibration increases the chances that your
> program can work on someone else's robot.
3. You sometimes run your robots on nice white paper, and sometimes you have
brown packing paper. :)
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | | | | | | | | | | | | | |
Jonathan Knudsen <jonathan@oreilly.com> wrote:
> 2. Different light sensors produce different readings for the same amount
> of light. Doing a runtime calibration increases the chances that your
> program can work on someone else's robot.
This is my inspiration for adding on-the-fly init code, btw. RoboTag uses
two seperate robots, and it turns out that my friend -- the source of the
second mindstorms kit -- has a light sensor which reads about 10 "darker"
than mine.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Jonathan Knudsen writes:
> [...] I take a somewhat more conservative approach, taking 10
> readings over one second and averaging them to get
> a baseline value. This is done once at initialization.
> I then detect a dark line by testing for a
> reading that is 3 below the baseline.
> [...]
>
> There's really only one drawback: you have to assume that
> your robot is over a white part of the driving surface
> when the program runs. If it's over a black line, your
> calibration will be all screwed up.
That's why I suggested a solution that works in all cases. It's not much harder
than your solution either. http://www.lugnet.com/robotics/rcx/?n=38
- Robert Munafo
| | | | | | | | | | | | | | | | |
Robert Munafo <munafo@gcctech.com> wrote:
> That's why I suggested a solution that works in all cases. It's not much
> harder than your solution either. http://www.lugnet.com/robotics/rcx/?n=38
That doesn't work in the case where you don't want your bot to start out by
going in a circle.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Matthew Miller writes:
> That doesn't work in the case where you don't want your bot to start out by
> going in a circle.
Huh? You mean, your robot doesn't work unless you point it in a certain
direction before starting the program? That doesn't sound too robust.
Okay, let's change the algorithm:
(this is for a line tracker that follows "dark" lines and relies on its
orientation at startup)
1. Check the light level.
2. Start moving forwards. Take some light readings.
3. As soon as the reading has changed a "significant" amount (a constant that
depends on whether you're reading in raw mode or light-sensor mode) look and
see what direction it has changed in.
4. If it went up (brighter) a significant amount, that means you were on a line
and just went off. Split the difference between the lowest and highest readings
you've seen so far and use this as the cutoff from now on. Also, turn to locate
the line again and continue.
5. If it went down (darker) a significant amount, that means you weren't on a
line but just found it. Split the difference to get the cutoff value. Continue
moving forward because you're on the line.
6. From here on you do your standard line following algorithm.
How's that? That will adapt to the ambient light level and differences in
surface darkness and doesn't do any initial turning.
- Robert Munafo
| | | | | | | | | | | | | | | | | |
| |
|
Robert Munafo <munafo@gcctech.com> wrote:
> Huh? You mean, your robot doesn't work unless you point it in a certain
> direction before starting the program? That doesn't sound too robust.
Partly, I can think of cases where that might be ugly. But more importantly,
I often want to set up a scenario so that two robots will bump into each
other in a certain place. (For making movies, showing off to friends, etc.)
Can't do that as easily if the robot doesn't go in the direction its
pointed.
> (this is for a line tracker that follows "dark" lines and relies on its
> orientation at startup)
That's part of the disagreement - there's a lot of other cases where one
might want to calibrate the sensor. My program, for example, stays in a
light area and "bounces" when it hits a dark line "wall".
> 2. Start moving forwards. Take some light readings.
> 3. As soon as the reading has changed a "significant" amount (a constant that
> depends on whether you're reading in raw mode or light-sensor mode) look and
> see what direction it has changed in. • [snip]
> How's that? That will adapt to the ambient light level and differences in
> surface darkness and doesn't do any initial turning.
Yes, much better. :)
Might get confused if someone picks the robot up before it hits a line, but
people shouldn't be doing that anyway. :)
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
| | | | | | |
