Re: IR detector system, biasing of photo diode

On 28-10-2024 13:01, Don Y wrote:

On 10/28/2024 3:17 AM, Klaus Vestergaard Kragelund wrote:

A IR transmitter on the docking station transmits a beam, and 2 IR detectors on the robot detects the beam and lets the robot navigate towards the target. The working distance is a couple of meters.

>
Can the robot ALWAYS see the docking station?  What happens if an
obstacle (wall?) comes between the two?

>
Yes, we have RTK GPS to position it within a cm at a location right in front of the docking, 2 meters away.

>
Then why can't you move to the GPS location of the dock with the
same degree of accuracy?

>
The docking station is typically in a shed, or close to a building where the GPS signal disappears.

 Ah, OK.
 

Can either device (robot/dock) ever slip out of the shared plane?

>
No, should be locked

>
"Outdoors" (from below).  Presumably on pavement/concrete (not a "lawn")
that wouldn't have dips and bumps?

>
It's moving on grass, and can have bumps etc, so for IR the lope needs to be perhaps 20degrees to avoid loss of signal

 And, presumably, they are short (time and space) transients?  *Faster*
than the response time of the robots controls?
>

Yes, the inner loop must be a lot faster than the control time of the robot, or it will oscillate ;-)

I have become particularly fond of using cameras to interface with
the real world.  Of course, it requires a bit more horsepower but
seems to be able to overcome all of the issues that have crept up...

>
That's also a solution we have been working on. The Worx Vision uses that
>
https://eu.worx.com/da-dk/landroid/vision-technology/
>
That is for a future version. Cameras can also be blinded, lenses needs to be cleaned etc

>
Yes, but a camera can be "queried" to verify that it is functioning
correctly:  "What do you see?  Is it THIS?"
>
I test my cameras by storing previously viewed scenes to verify they
are still "reasonably" intact.  Ideally, I would move something into
the field of view but that requires additional capabilities.
>
You, however, could move the robot (assuming IT has the eyes) and
verify that the scene changes accordingly.

>
Could be done. The guys in charge are worried with change of environment, so what happens when it snows heavily, fog or other surroundings changing effects.

 You extract salient "features" from the scene and use them.
The robot doesn't need to be concerned about whether the ground is
green, brown or white.  Or, if the shed is in shade, blanketed
with snow, etc.
 E.g., I use them to "watch" the garage door rails (which have a specific
shape) to see if any objects have come between the camera and the rails.
(The rails define the plane that the garage door will occupy as
it closes)  Of course, everything around the rails is highly variable
as garages are notorious for clutter and dynamism.
 Another camera "watches" the mailbox by the road.  In addition to
the surroundings changing, there can be pedestrian and vehicular
traffic passing at any time.  In our case, it is illegal to
drive while using a phone so folks often pull over to answer
phone calls -- our mailbox is in a shaded area that seems to be
highly desirable to such motorists-in-need.  But, *their*
vehicles don't look like "mail trucks" so no chance of thinking that
*they* are delivering our mail...
 As I said before, it is a really great "sensor"!  The downside is
that you need resources to use it (your optical approach is likely
possible with far less resources -- think of how robot vaccuum cleaners
operate wrt their charging docks)
 

Correct, all though high resolutionn cameraes are very cheap nowadays. And they have a Linux maching running the application SW, so adding a camera does not add much extra cost, just a camera interface IC.