[Dprglist] Sample Retrieval vacuum cleaner

[Doug Paradis]

John,
    I am still working through your message, however I have some thoughts
and possible answers.
First a few questions, I know bats have large ears, but in the scheme of
things they are small animals, so their sensors (i.e., ears) are no larger
than 2x4 inches each. They use a high pitch or ultrasonic squeak (emitter).
They also carry their emitter and receivers on their body without  any
non-integral body parts hanging about. With this equipment they can easily
detect insects flying about. The question, is this detection simply
obstacle detection (i.e., I look in the air, I see an obstacle, it moves,
therefore it is food.) or is it target determination (i.e., I look in the
air, I see a moth not a mosquito). What if the moth is on a tree branch.
Can a bat still find the moth?

Do bats move their ears while listening to form a scan of the reflection?

The contest challenge is to find specific objects (samples). The
environment will be a room with lots of stuff and people in it. Could a
sonic system have enough discrimination to identify the target objects? Or
would it only be able to detect obstacles. What object characteristics or
features could it determine (height, width, density, surface curvature,
profile, distance, etc...)?

How would you return to home base? I assume that you will detect the cone
at home base as just an other unique object and drive to it.

Now I have some answers.

If the robot base is holding you back, I will offer use of my robot
"Falcon". You can find a picture of it a
https://www.dprg.org/fall-indoor-competition-results/. It is the white
robot in front of me in the quick trip picture.  It is a club robot base
with a gated scoop in front. I will make provisions to mount a ~5x6.5 inch
deck (or multiple decks) on it for your sensors and electronics.
Communication between your electronics and the base will be via a serial
port (115200 baud). The robot is capable of dead reckoning navigation. We
can work out a interface protocol. My thoughts are your electronics should
communicate these basic commands: turn right, turn left, go straight, stop,
or drive to x,y location. The gate closes when an object trips a sensor
inside the scoop, but you could also command gate position. Currently the
robot has a low mounted ultrasonic sensor, and a pixyCAM-1. I can remove
the pixyCAM and the ultrasonic sensor can be unplugged. The wheel base is
9.75 inches. So your task would be to construct your gear and place it on
the deck. I can laser cut a deck, with mounting holes and mail it to you,
or give to you at next meeting. The deck will be made of Masonite. I will
provide the robot base software. Let me know it this is acceptable.

An alternative robot base is the club's turtle robot. It is based on a
Roomba. It would be much more work but would provide more deck space. I
believe it is a ROS capable robot, but I haven't looked at a while so I
don't know the state of its electronics.

Programming the robot with object locations is a no go. Note that the
contest's objects are available for practice and generating learning sets
at RBNO every Tuesday.

Sharing information from a competitor's robot run I believe is also a no
go. It seems to me that it would be unfair to other competitors.

Note the rules say that the robot must carry all the sensors, but
computations do not need to be done on the robot, you can use an external
computer with some type of radio to communicate the robot. Most folks use
WiFi.
Depending on the object features extracted by the sonic system, I think
that AI could be useful.
Regards,
Doug P.


On Sun, Jan 20, 2019 at 12:46 AM John Swindle <swindle at compuserve.com>
wrote:

> Ron and Doug,
>
> I am interested if I can exploit the localizer, repurposed not as beacons.
> Sound can be used for two unrelated tasks: echolocation and localization.
> Ironically, echoes are a huge source of errors when doing localization, but
> echoes are vital for echolocation. The two can be used together if the
> localizer's echoes are processed as passive sonar. This requires a very
> clean signal because the echoes are subtle. I've spent most of my time
> seeking waveforms that are inherently low-noise and low jitter.
>
> Thanks for noting that sound is used for medical imaging. The speed of
> sound in liquids is much faster than in air, so for reasonable resolution,
> the sound must be much higher frequency, and liquids are coupled better, so
> they conduct those high frequencies. No need to go to high frequencies to
> do imaging in air, and air just won't couple the high frequencies anyway.
> Your note reminds me that sonar in air could be processed with tomography
> software. I looked at that a few years ago and was bewildered by
> tomography. Worth another look.
>
> My first thought of the bat bot was a baseball bat pulverizing the return
> samples, then I realized you meant the animal.
>
> As usual, I am not very interested in making my own motive platform. If I
> could get sonar imaging working, maybe someone would host the gadget on
> their robot. The gadget would be omnidirectional, so it would not be
> pointed at things. But it would be large, about the size of the cat toys
> that are big donut rings with a ball captive in the ring, so about a foot
> in diameter and three inches tall.
>
> Separately,
>
> Doug, what's your opinion of programming the robot with the locations of
> the objects and home base? If that is too much prior knowledge, then how
> about the idea we discussed briefly:
>
> Sharing information between robots. Not swarming. Connected-vehicle kinda
> stuff. Results from a competitor's successful run (or at least success in
> finding stuff even if it isn't retrieved) would feed that competitor's next
> run and other cooperating competitors.
>
> All the talk about AI makes me to look at using it to process the sonar
> instead of continuing to write my own geometry programs.
>
> Best to you all,
> John Swindle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20190120/b4a2f013/attachment.html>