Ping & SRO4 sensor interference

[Andrew Z]

Hello all,

As you may know, I'm working on a robot for the Tablebot Challenge at Robogames this year. My approach to Stage 2 (find a block and push it off the table) is to use an ultrasonic sensor to sense the block. (Right now I'm using a Ping))) sensor, but my current plan is to use an SRO4 sensor in addition to sense the goal for Stage 3.) 

However, while the Ping works fine in most rooms, in some rooms its readings jump all over the place, going from 100 to 700 mm, even when the robot is sitting still. I've determined that this problem is because of the ultrasonic sensors installed in some rooms that turn on the lights when someone walks in, and turn them off when they walk out. While the Robogames arena probably won't have these sensors, having a robot that only works in some rooms does not seem like good practice. 

Has anyone else encountered this problem? If so, what did you do to fix it?

Thanks!

[KM6VV]

I have been successful at Robogames with IR sensors.

Alan KM6VV

On 2/8/2013 12:33 PM, Andrew Z wrote:
> Hello all,
>
> As you may know, I'm working on a robot for the Tablebot Challenge at
> Robogames this year. My approach to Stage 2 (find a block and push it
> off the table) is to use an ultrasonic sensor to sense the block. (Right
> now I'm using a Ping)))

> <http://www.parallax.com/tabid/768/productid/92/default.aspx> sensor,

> but my current plan is to use an SRO4

> <http://www.amazon.com/Ultrasonic-Module-HC-SR04-Distance-Arduino/dp/B004U8TOE6>

> sensor in addition to sense the goal for Stage 3.)
>
> However, while the Ping works fine in most rooms, in some rooms its
> readings jump all over the place, going from 100 to 700 mm, even when
> the robot is sitting still. I've determined that this problem is because
> of the ultrasonic sensors installed in some rooms that turn on the
> lights when someone walks in, and turn them off when they walk out.
> While the Robogames arena probably won't have these sensors, having a
> robot that only works in some rooms does not seem like good practice.
>
> Has anyone else encountered this problem? If so, what did you do to fix it?
>
> Thanks!
>

> --

[Andrew Z]

Hi Alan,

I've looked at IR sensors, but the ones I saw on Pololu seem to have a minimum range of 4 inches. It seems that a 4 inch "blind spot" for a Tablebot seems rather large. Did this turn out to be a problem for you?

Thanks!

Andrew

[KM6VV]

I used Sharp 2D120X and 2Y0A02 sensors. If the 'bot is moving, you need
a little range anyway.

Floor sensors were the opposite, you need to be able to see close (and
fast).

Alan KM6VV

On 2/8/2013 1:04 PM, Andrew Z wrote:
> Hi Alan,
>
> I've looked at IR sensors, but the ones I saw

> <http://www.pololu.com/catalog/product/136> on Pololu seem to have a

[George Campbell]

Acroname has post on the various Sharp IR sensors

http://www.acroname.com/robotics/info/articles/sharp/sharp.html

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at http://groups.google.com/group/hbrobotics?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[dennis...@verizon.net]

Noisy data... If you keep a filtered version of your readings to provide an
averaged value the spikes will be glaringly obvious and you can throw them
out. If your sampling is unfortunately synchronized to the noise source
this scheme will not work very well. In this case you might try to assess
what the noise source is doing and move into it's dead band. Worst case you
have those pesky people detecting lights and your target is narrow enough
that the readings fluctuate; your robot will spend a fair amount of time
trying to figure out what problem to solve.

Original Message:
-----------------
From: KM6VV KM...@sbcglobal.net
Date: Fri, 08 Feb 2013 12:54:01 -0800
To: hbrob...@googlegroups.com
Subject: Re: [HBRobotics] Ping & SRO4 sensor interference

I have been successful at Robogames with IR sensors.

Alan KM6VV

On 2/8/2013 12:33 PM, Andrew Z wrote:
> Hello all,
>
> As you may know, I'm working on a robot for the Tablebot Challenge at
> Robogames this year. My approach to Stage 2 (find a block and push it
> off the table) is to use an ultrasonic sensor to sense the block. (Right
> now I'm using a Ping)))
> <http://www.parallax.com/tabid/768/productid/92/default.aspx> sensor,
> but my current plan is to use an SRO4
>
<http://www.amazon.com/Ultrasonic-Module-HC-SR04-Distance-Arduino/dp/B004U8T
OE6>
> sensor in addition to sense the goal for Stage 3.)
>
> However, while the Ping works fine in most rooms, in some rooms its
> readings jump all over the place, going from 100 to 700 mm, even when
> the robot is sitting still. I've determined that this problem is because
> of the ultrasonic sensors installed in some rooms that turn on the
> lights when someone walks in, and turn them off when they walk out.
> While the Robogames arena probably won't have these sensors, having a
> robot that only works in some rooms does not seem like good practice.
>
> Has anyone else encountered this problem? If so, what did you do to fix
it?
>
> Thanks!
>
> --

--
You received this message because you are subscribed to the Google Groups
"HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at http://groups.google.com/group/hbrobotics?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web

[Andrew Z]

Hi Dennis,

Unfortunately, my problems are coming from the people-detecting lights. You've had that problem too? What have you done to fix it?

Thanks!

Andrew

[dennis...@verizon.net]

Andrew,

I had a lot of cross talk issues with my sensors and the world that threw
their signals back at them but no direct experience with people sensing
lights.

On the other hand I have a fair amount of experience with noise injected
into a system at inopportune times which is where the averaging and tossing
scheme evolved.

Dennis

Original Message:
-----------------
From: Andrew Z and...@nuevaschool.org
Date: Fri, 08 Feb 2013 15:50:58 -0800 (PST)
To: hbrob...@googlegroups.com, dennis...@verizon.net

Subject: Re: [HBRobotics] Ping & SRO4 sensor interference

Hi Dennis,

Unfortunately, my problems are coming from the people-detecting lights.
You've had that problem too? What have you done to fix it?

Thanks!
Andrew


On Friday, February 8, 2013 3:24:33 PM UTC-8, dennis...@verizon.net wrote:
>
> Noisy data... If you keep a filtered version of your readings to provide
> an
> averaged value the spikes will be glaringly obvious and you can throw
them
> out. If your sampling is unfortunately synchronized to the noise source
> this scheme will not work very well. In this case you might try to assess
> what the noise source is doing and move into it's dead band. Worst case
> you
> have those pesky people detecting lights and your target is narrow enough
> that the readings fluctuate; your robot will spend a fair amount of time
> trying to figure out what problem to solve.
>
> Original Message:
> -----------------

> From: KM6VV KM...@sbcglobal.net <javascript:>

> Date: Fri, 08 Feb 2013 12:54:01 -0800

> To: hbrob...@googlegroups.com <javascript:>

> Subject: Re: [HBRobotics] Ping & SRO4 sensor interference
>
>
> I have been successful at Robogames with IR sensors.
>
> Alan KM6VV
>
> On 2/8/2013 12:33 PM, Andrew Z wrote:
> > Hello all,
> >
> > As you may know, I'm working on a robot for the Tablebot Challenge at
> > Robogames this year. My approach to Stage 2 (find a block and push it
> > off the table) is to use an ultrasonic sensor to sense the block.
(Right
> > now I'm using a Ping)))
> > <http://www.parallax.com/tabid/768/productid/92/default.aspx> sensor,
> > but my current plan is to use an SRO4
> >
>
<http://www.amazon.com/Ultrasonic-Module-HC-SR04-Distance-Arduino/dp/B004U8T

>
>

OE6<http://www.amazon.com/Ultrasonic-Module-HC-SR04-Distance-Arduino/dp/B004

U8TOE6>>
>
> > sensor in addition to sense the goal for Stage 3.)
> >
> > However, while the Ping works fine in most rooms, in some rooms its
> > readings jump all over the place, going from 100 to 700 mm, even when
> > the robot is sitting still. I've determined that this problem is
because
> > of the ultrasonic sensors installed in some rooms that turn on the
> > lights when someone walks in, and turn them off when they walk out.
> > While the Robogames arena probably won't have these sensors, having a
> > robot that only works in some rooms does not seem like good practice.
> >
> > Has anyone else encountered this problem? If so, what did you do to fix
> it?
> >
> > Thanks!
> >
> > --
>
> --
> You received this message because you are subscribed to the Google Groups
> "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to hbrobotics+...@googlegroups.com <javascript:>.

> To post to this group, send email to

hbrob...@googlegroups.com<javascript:>.

>
> Visit this group at http://groups.google.com/group/hbrobotics?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://link.mail2web.com/mail2web
>
>
>

--
You received this message because you are subscribed to the Google Groups
"HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at http://groups.google.com/group/hbrobotics?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




--------------------------------------------------------------------

myhosting.com - Premium Microsoft® Windows® and Linux web and application
hosting - http://link.myhosting.com/myhosting

[George Campbell]

to reduce the chance of synchronization you can wait some small additional random amount of time.

to handle the spurious errors I would keep a moving average of 3 or 4 readings and ignore any readings that are outside an error threshold.  You still want to include the erroneous readings in the moving average to detect when the large value change is real after a few more readings confirm it.

[Andrew Z]

Hi Alan,

I see that the 2D120X has shorter range as compared to the 2Y0A02. Which sensor did you use for which? Did you have problems with interference?

Thanks!

Andrew

[KM6VV]

Hi Andrew,

I put the long range sensor up higher, to look above the object (box)
and be able to see the goal.

http://www.lynxmotion.net/viewtopic.php?f=9&t=7018&p=78367&hilit=table+top#p78367

Alan KM6VV

On 2/9/2013 12:12 PM, Andrew Z wrote:
> Hi Alan,
>

[Osman Eralp]

With Arthur's help, I ran some tests using ultrasonic sensors in Crusher where we usually hold our meetings. I walked around taking readings with a Ping sensor and a SR04 sensor. Both sensors experienced interference. The interference seemed to be coming from the smoke detectors: when I was under one of the smoke detectors, the sensor readings were so erratic as to be useless. In between the smoke detectors, there was a zone of reduced interference. In the zone, downward facing ultrasonic sensors worked well; side facing sensors still encountered some interference.

What I saw was not just noise. The readings were wrong. No amount of filtering the sensor output would help. If one had access to the raw data before it was processed by the Ping or SR04, one might be able to process it differently to filter out the noise. That's not a trivial task.

I have the same unanswered questions as Andrew: Has anyone else encountered this problem? If so, what did you do to fix it?

I have another question of opposite polarity: Has anyone demonstrated a robot in Crusher that used ultrasonic sensors successfully?

[Steven Nelson]

Hunh, that's interesting, I wonder why a smoke detector would effect an ultrasonic sensor?  Smoke detectors usually work using light or nuclear radiation to trigger their sensors. Could there be some other types of sensors in the room as well? Some stuff on smoke detectors... http://home.howstuffworks.com/home-improvement/household-safety/fire/smoke.htm

--

You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at http://groups.google.com/group/hbrobotics?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Inspection time: The period of time required to inspect a recently welded piece of metal using your bare hand.
The hotter the metal the shorter the period of inspection time

[Nathaniel Lewis]

On a side note, I know of a place to get these cheaper -> http://www.wrighthobbies.com/product.php?productid=159.  I know, or at least used to know, the guy who runs this shop.  He at least used to be a very active member of the Chicago Area Robotics Club (Chibots).

[Osman Eralp]

On Tuesday, February 12, 2013 8:08:36 PM UTC-8, Teknoman117 wrote:

On a side note, I know of a place to get these cheaper -> http://www.wrighthobbies.com/product.php?productid=159.  I know, or at least used to know, the guy who runs this shop.  He at least used to be a very active member of the Chicago Area Robotics Club (Chibots).

If cost is your concern, you can't beat the Asian sellers on ebay who sell the SR04 sensors for $2 each:

http://www.ebay.com/itm/5Pcs-Ultrasonic-Module-HC-SR04-Distance-Measuring-Transducer-Sensor-for-Arduino-/140763883586?pt=LH_DefaultDomain_0&hash=item20c62e6842 

[Nathaniel Lewis]

haha wow, still waiting for mine to come in.  Do they actually show similar to performance to the PING))) and the SRF04/05/08 line?  Or are they as cheap as one might think….

Nathaniel Lewis

CTO at E1FTW Games

2nd year Undergraduate, Computer Science and Engineering

Project Manager for the Robotics Society at UC Merced

Undergraduate Lab Technician Intern at MESA Labs

(925) 961 7578

linux.r...@gmail.com

[Andrew Z]

I believe what Osman and I eventually figured out is that the people-detecting lights, the ones that turn on when a person walks in, use Ultrasonic at the same frequency as the Ping and SR04.

[Steven Nelson]

One of the things I've noticed with both of those brands of ultrasonic sensors is the often do not detect soft targets like human legs with loose fitting pants. The sensors can see the humans shoes but not the pant legs also some plastic bags, foam rubber, and other soft sound absorbing materials. On Lynxbot I also use the Sharp infrared sensors as backup for the ultrasonic sensors. Of course they don't always detect things like dark colored or black surfaces. So if the human is wearing Black loose fitting pants the will have a small bot climbing their leg. Probably still need to use a bump switch for the final back up sensor and emergency stop. Especially on a large robot. I kind of see that sensor layering is very important due to the nature of all of the obstacles and other electronic devices that the modern world is made of..  

[Wayne C. Gramlich]

All:

I have a theory that we can using a folding canopy like:


http://www.amazon.com/Green-Foldable-Portable-Carrying-Included/dp/B000XHWW10/ref=sr_1_1

or


http://www.amazon.com/Caravan-Canopy-Cirrus-Instant-White/dp/B0032UY0AQ/ref=pd_sbs_lg_5

to shield our robots from the ultrasonic interference coming from
the smoke detectors/people sensors from the ceiling in the
Crusher conference room at Google.

Does anybody have a folding canopy that can be brought to the
next HBRC club meeting to check out this hypothesis. I doubt
the test will take more than a few minutes.

For those of you who remember the show "Get Smart" back in the 60's
-- the canopy would be used as a "cone of silence".

Regards,

-Wayne

[blackstag]

I can tell you shag carpet does wonders for making ultrasonics not
work well. Why i was testing in a house with shag carpet 4 foot up the
wall maybe to red neck of a story for this list.

[Alex Sy]

The people sensors that cause the porblem are "dual technology" types, which
use both PIR and ultrasonic. Unfortunately, most of the ultrasonic
transducers in the market are 40Khz units, and that is also used by the ping
etc. The people sensor units intentionally try to fill the room with
ultrasonic pulses (it is intentionally not directional) so that it will
reflect off partitions etc, then when any movement occurs, it causes a
doppler shift, that then is received by the sensitive receiver on the unit.
The goal is to detect that there are people in the room even if they are not
line of sight to the sensor. So I doubt the canopy method will work since
your sensor will get triggered by any ultrasonic pulse edge so you get
random ranges.
An approach to deal with this is to have your range finder generate a
"chirp" which is basically a swept frequency ultrasonic pulse, then the
receive tries to correlate that swept freq pulse and calculate the range.
This is probably more complicated than what you wanted to deal with when you
used the ping sensors in the first place.

[KM6VV]

A "modulated" ultrasonic signal would have some rejection to the
unwanted returns.

Alan KM6VV

[Alex Sy]

Actually, on a ping, there is no modulation of the ultrasonic signal, it is
just an approximately 40khz carrier. The reason for the 40khz is because
that is the resonant frequency of the ceramic element. When the echo comes
back, it takes several cycles of 40khz to cause the receive element to
vibrate, the code then looks for the first edge to determine the transit
time. Problem is that a random 40khz signal coming from the people detector
during the receive time will cause it to think that there is a valid but
wrong range.
There is also another approach where you measure both the start and end of
the received ultrasonic signal, then make sure that it is within some
percentage of the transmitted signal in width, before treating it as valid.
This may allow you to discriminate between your own signal and that from the
people detector.

----- Original Message -----
From: "KM6VV" <KM...@sbcglobal.net>
To: <hbrob...@googlegroups.com>
Sent: Tuesday, February 26, 2013 12:50 AM
Subject: Re: [HBRobotics] Re: Ping & SRO4 sensor interference

[Wayne C. Gramlich]

Alex:

On 02/25/2013 11:18 PM, Alex Sy wrote:
> The people sensors that cause the porblem are "dual technology" types, which
> use both PIR and ultrasonic. Unfortunately, most of the ultrasonic
> transducers in the market are 40Khz units, and that is also used by the ping
> etc. The people sensor units intentionally try to fill the room with
> ultrasonic pulses (it is intentionally not directional) so that it will
> reflect off partitions etc, then when any movement occurs, it causes a
> doppler shift, that then is received by the sensitive receiver on the unit.
> The goal is to detect that there are people in the room even if they are not
> line of sight to the sensor. So I doubt the canopy method will work since
> your sensor will get triggered by any ultrasonic pulse edge so you get
> random ranges.
>
> An approach to deal with this is to have your range finder generate a
> "chirp" which is basically a swept frequency ultrasonic pulse, then the
> receive tries to correlate that swept freq pulse and calculate the range.
> This is probably more complicated than what you wanted to deal with when you
> used the ping sensors in the first place.

I would still like to do the experiment. Most ultrasonic sensors
are pretty directional, so I doubt that there is all that much overlap
between the dual technology people sensors. If nobody can volunteer
to bring a canopy, I'll try and bring a sheet and draft some people
to hold up the 4 corners of the sheet.

The issue is that our table top challenge robots typically use a
ultra sonic sensor to find the block and the goal. It would be
really disappointing if people have a perfectly functioning table
top robot that works at home but does not work when presented at
HBRC show and tell.

Regards,

-Wayne

[KM6VV]

Probably too slow for rangers, but ultrasonic and IR systems can be
modulated to reject unwanted signals. More for data transmission,
possibly, I haven't seen it applied in rangers.

The current ultrasonic rangers only transmit a small number of cycles,
possibly too short to be modulated effectively.

Alan KM6VV

[KM6VV]

Wayne,

Were you planning to use an ultrasonic ranger on a table 'bot? Haven't
most of the sensors been IR? I think we've tested them. New meeting room?

Maybe just run some ranger tests first?

Alan KM6VV

[Wayne C. Gramlich]

Alan:

The price on ultrasonic sensors has changed greatly over the years.
Originally it was the Poloroid for $70. Next came the SRF04 from
Gerry Coe for about $30. Along came the Ping! and Maxbotix for
mid-$20's. Now we have the Chinese sensors for $2 each. They
are now cheaper than the IR sensors.

Regards,

-Wayne

[KM6VV]

Hi Wayne,

Well, the SRF08s weren't that cheap when I bought them. I can see why
you're interested in them!

Alan KM6VV

[A J]

Good discussion. If there are multiple

SR-04 sensors on the bot would it be

Possible to set some listen and then

Reject ambient noise?

http://www.omron-ap.com/FAQ/FAQ01259/index.asp

Regards,

Andy Jang

[Bob Smith]

A J wrote:
> Good discussion. If there are multiple
> SR-04 sensors on the bot would it be
> Possible to set some listen and then
> Reject ambient noise?

That seems like a good idea.

While we're redesigning the system how about making
some other changes. Right now each sensor is pinged
in turn so that they don't interfere with each other.
How about pinging them all at exactly the same time
and getting the response on all sensor at once. A
detected echo should be from the closest object to that
sensor. You could get a reading from all sensor much
faster this way.

Also, if you're transmitting on a single transmitter,
how about listening for echos on all receivers? That
way you might detect object off the center line of a
single sensor.

Of course all of the above would require changes to
the code in the sensors in use today.

Bob Smith

[Alex Sy]

The technique to do this involves beam forming and using signal processing
to adjust the phase of each transmitter so that it actualy creates a beam
pointed to a particular direction, then collecting the echos and using
correlation to determine the direction they came from. You can then create
an image. This is similar to a sonogram.
The issues are significant. You need a higher frequency than 40khz to get
enough resolution, the ADC for each channel has to be several megahertz, and
the processing has to handle all of that simultaneously from each of the
sensors. It gets to be quite expensive.

----- Original Message -----
From: "Bob Smith" <bsm...@linuxtoys.org>
To: <hbrob...@googlegroups.com>

Sent: Tuesday, February 26, 2013 9:18 PM
Subject: Re: [HBRobotics] Re: Ping & SRO4 sensor interference

[Alex Sy]

The people sensors have a good way of avoiding the noise of any other source, because they transmit continously, then use their transmit signal as a reference to determine the offset doppler of the received signal.  It is highly likely that the robot's ultrasonic pulse will be at some other frequency that is outside of the narrow passband (about 100 hz) of the people sensor so it is not affected.  However, the "low cost" robot sensor would not have such a filter and therefore will respond erroneously  to signals that could be several hundreds of hertz away.

[Osman Eralp]

On Sunday, February 10, 2013 9:43:05 PM UTC-8, Osman Eralp wrote:

With Arthur's help, I ran some tests using ultrasonic sensors in Crusher where we usually hold our meetings. I walked around taking readings with a Ping sensor and a SR04 sensor. Both sensors experienced interference. The interference seemed to be coming from the smoke detectors: when I was under one of the smoke detectors, the sensor readings were so erratic as to be useless. In between the smoke detectors, there was a zone of reduced interference. In the zone, downward facing ultrasonic sensors worked well; side facing sensors still encountered some interference.

Here is an update on the ultrasonic situation in our Crusher meeting room at Google. After the meeting on Wednesday, a few of us stuck around and ran some more tests. One thing we tried was putting up a cotton sheet to block the interference from the interference-making-devices-of-unknown-purpose mounted on the ceiling. Under the sheet, we still experienced interference. Under a table, we experienced no interference, so it's possible that a more solid structure over a table would block the interference. However, such a structure would be unwieldy. Fortunately, we were able to mark out a zone between the interference-making devices where ultrasonic sensors worked well. The zone was larger than a table, so table bots should work. We will be setting up the show-and-tell table in that zone in future meetings. Floor bots that wander out of the zone might experience ultrasonic interference.

--Osman