To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 14782
14781  |  14783
Subject: 
Re: Shutting off illumination LED on Light Sensor for LIDAR
Newsgroups: 
lugnet.robotics
Date: 
Wed, 28 Mar 2001 21:17:07 GMT
Original-From: 
Andy Gombos <gombos_2000@yahooIHATESPAM.com>
Viewed: 
1984 times
  
This sounds very cool.  If you want to do the mapping at the bottom, you will have
to use alternitive firmware anyway (right?), and they have a passivate command that
turns off the light.  It passivates the sensor, but I don't think standard firmware
has anything like this.

Andy

Chris 'Xenon' Hanson wrote:

>    Has anyone successfully found a way (short of paint, or cutting
> internal wiring) of shutting off the red 'supply light' LED on the
> Lego light sensor?
> 
>    The supply LED is great for active-detection situations, like
> line-following, when you need to read the reflectance of an object
> at close proximity, and the sensor itself might cast a shadow onto
> the target, blocking ambient light.
> 
>    I wish to use the light sensor in a purely passive mode, detecting
> available ambient and direct light from other room sources. It seems
> capable of doing this even with the light on, but I feel I am probably
> getting less sensitivity because the close proximity of the LED to the
> photodiode (I think that's what they're using) will cause some bleed
> over, gain, and loss of low-light sensitivity.
> 
>    I've considered buying another sensor and either painting over the
> supply LED, or opening it up and cutting it's wires or something.
> 
>    Alternately, if I can figure out what the photodiode part is, and
> how it's wired, I could just build my own passive-only sensor that
> would be level-compatible with the Lego part.
> 
>    Obviously, if I can figure out a way to disable the supply LED via
> software, that would be best, so I can share my development with
> others who do not have custom hardware.
> 
>    I have noticed that configuring the input port the light sensor is
> connected to as the wrong type of sensor, say a switch, causes the
> Light Sensor's LED to dim in intensity. Perhaps this can be used,
> but I think it impairs the ability to actually read the light sensor
> value. ;(
> 
>    (I have also tried stacking a few 1x2 technic blocks with the hole in
> them in front of the light sensor to block the emitter, and give the
> sensor "tunnel vision" as it were, but I still feel there's some
> bleed.)
> 
>    So here's what I'm using it for right now:
> 
>    I have mounted both the Light Sensor (with 'tunnel vision' blocks)
> and the Lego Light (from Ultimate Accessory) aimed forward on the
> front of my bot.
> 
>    Using NQC, I ensure the light is off, and take a reading from the
> light sensor to record ambient light level in that direction. Then,
> without moving the bot, I turn on the light and take another light
> reading. The difference in the two light levels is basically a LIDAR
> distance estimate to the nearest obstacle.
> 
>    The LIDAR ranging technique is quite accurate, and can detect out
> to a distance of a little over 1m (limited by the light intensity of
> the lego light, and the sensitivity of the light sensor). I am also
> considering using a super high-intensity custom LED in place of the
> lego light to increase detection range.
> 
>    I forget the exact number of discrete range steps I get, I think it's
> about 10, giving it a nominal ranging resolution of about 10cm. The step
> interval seems non-linear, which would make sense given the spherical
> dispersion of light in an expanding sphere.
> 
>    I need to do more precise testing and calibration, but having a more
> sensitive sensor (one not overrun by its own light source) would help.
> 
>    The LIDAR is good at detecting almost any obstacle, and because it
> has both an ambient and an illuminated reading, it is equally good at
> detecting surfaces of all colors. It will even detect a (glossy) glass
> plate placed in front of it. It is excellent for forward collision
> prevention without contact.
> 
>    Possible avenues of exploration:
> 
>      Using the RCX IR emitter as the illumination source. Don't know
> exactly how to just jam it 'on' like a light connected to an output
> port, and don't know it's comparative power. This would give me one
> additional output port free if I didn't need the Lego light, a big
> bonus. This would make the design more accessible to those who don't
> have the Lego Light part from Ultimate Accessory. Also, the annoying
> visible strobing of the Lego light would be eliminated, making it
> more of a (visibly) passive, 'stealthy' sensor. (This is what the
> Caterpillar One bot at http://www.rcx.ic24.net/catone.htm does, though
> the example code is very convoluted). This would be helped by turning
> off the light sensor's own light supply LED.
> 
>      Using the lego light sensor's supply light, if I can figure out how
> to toggle it on and off under software control. This would also gain
> me an extra output port, but the sensor's LED doesn't seem that powerful,
> and might impair the sensor range. This too would eliminate an accessory
> part and make the design more widely-accessible.
> 
>      Using a custom-built high-intensity visible light or infrared LED.
> Increased detection range, possibly using 'stealthy' non-visible light.
> 
>      Mounting the emitter/sensor package on stepped 1D or 2D rotation
> axes to detect obstacles all around the bot for navigation planning,
> or for contact-free 3D scanning(!). One could log both the ambient-light
> level, and the calculated LIDAR level to assemble (on a host computer)
> a raster image and depth map of the robot's environment. Without really
> tricky mechanical or electrical design, this would consume all of the
> inputs and outputs of a stock RCX, leaving it unable to move about,
> but with very clever design, one could make an autonomous robot rover
> that could navigate about, image interesting locations, and send
> (one-way) traffic back to a telemetry computer via serial IR with
> location info and a snapshot image/3D model of the environs. Almost as
> good as Sojourner on Mars.
> 
>    Much of the inspiration for this comes from the Caterpillar One ('inverse
> RADAR' IR-based LIDAR design) Pipe Scanner, Arm Scanner and Remote Probe
> from:
> 
> http://www.rcx.ic24.net/designs.htm
> 
>    and the Probe from:
> 
> http://web.one.net.au/~bwilliamson/lego/
> 
>    Plus, I've always wanted to build a LIDAR (LIght Detection And Ranging,
> the light form of RADAR) unit.
> 
>    Comments?
> 
> Chris - Xenon
> --
>   Chris Hanson | Xenon@3DNature.com | I've got friends in low latitudes!
>          New WCS 5 Demo Version!     http://www.3DNature.com/demo/
>   "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
> 



Message has 1 Reply:
  Re: Shutting off illumination LED on Light Sensor for LIDAR
 
(...) Maybe. I think RCX2 with NQC has some crude arrays, I haven't looked into them yet, but I might be able to use them to do simple mapping on the RCX. Or something even cruder if I don't have arrays. (...) Ahh. Hmm. I wonder what it actually (...) (26 years ago, 28-Mar-01, to lugnet.robotics)

Message is in Reply To:
  Shutting off illumination LED on Light Sensor for LIDAR
 
Has anyone successfully found a way (short of paint, or cutting internal wiring) of shutting off the red 'supply light' LED on the Lego light sensor? The supply LED is great for active-detection situations, like line-following, when you need to (...) (26 years ago, 28-Mar-01, to lugnet.robotics)

15 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
    

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR