Unreliable HC-SR04 with Explorer HAT Pro

Support
1

I’ve started to use the Explorer Pro HAT with an HC-SR04 ultrasonic sensor to build a Zumo-based robot and am getting strange results with the distance tests. If the distance is less than ~40 cm then the combination of HAT + sensor seems to get stuck, never returning a result (the “== 0” while loop below never exits). If greater than ~40cm then the result returned for, say, 50cm varies from 14cm to 80cm. Yet, the resolution is supposed to be down to the nearest mm. The sensor is also rated to ~400 cm yet I get results ranging from ~4cm to ~180cm for a wall just shy of 2m away.
The object is at right-angles to the sensor, hence unlikely to be an artefact of bouncing.

Have you had success with the sensor with the board?

I am wondering if this is a bug in the Explorer HAT code, or possibly I’m not understanding something.

Here’s my code that does not work:

import explorerhat as eh
import time

# ensure the output is off
eh.output.one.off()
time.sleep(0.5)

signaloff = time.time()
signalon = signaloff

def objdist():
  eh.output.one.on()
  time.sleep(0.00001)
  eh.output.one.off()

  while eh.input.one.read() == 0:
    pass
  start = time.time()

  while eh.input.one.read() == 1:
    pass
  stop = time.time()

  return (stop - start) * 17000

print "start"
print objdist()
print "stop"

If I try something simpler it seems to work sort-of ok, although weirdly returning a 1 when it ought to be a 0 and vice versa. I’ve tried modifying the two while statements above swapping the 1 and 0 around but to no avail.

The following works confirming that when there’s an object in front of the sensor we see a result, but obviously won’t give me a distance back, just a 1 or 0:

import explorerhat as eh
import time

eh.output.one.off()
time.sleep(0.5)

while True:
  eh.output.one.on()
  time.sleep(0.00001)
  eh.output.one.off()
  print eh.input.one.read()
  print eh.input.one.read()
  print "****"
  time.sleep(1)

My sensor is wired up as per the photo (sorry for the URL, new users can’t upload to your forum). Although a little tricky to see, hence to help the sensor is wired as follows:

VCC to 5V (blue wire)
Trig to Output 1 (yellow wire)
Echo to Input 1 (green wire)
GND to GND (brown wire)

I’m using a Raspberry Pi A+.

Any thoughts would be most appreciated.

1 Like
2

The problem is quite likely to be a timing problem- I suspect the Explorer HAT code is fine, but there’s just too much of it getting in the way of what is a very, very time sensitive measurement.

You will probably have to use RPi.GPIO directly if you want to get a more accurate reading- I also suspect some of the polling code in the library ( used to read the analog inputs and button states ) will be slowing down your readings and making them very unreliable, so using the two together might prove tricky.

I’ll have a look into expanding the Explorer HAT python library with options to turn off/slow down the analog/touch polling which might help.

3

Cheers, sounds good.

Are there any gotchas one needs to be aware of when using RPi.GPIO directly with the Explorer HAT Pro?

If you’re able to improve the response time with the HAT for ultrasonic readings that’d be great. Feel free to send me a message if you’d like me to test the code (seeing as I’ve a willing robot handy).

4

Just thought: the Explorer Pro has those tasty looking analog ports available. Would they be capable of playing nicely with one of these https://www.pololu.com/product/136, the Sharp GP2Y0A21YK0F Analog Distance Sensor instead? It uses IR instead of ultrasound, hence only works 10-80cm but I don’t need greater than that, and can live with 10cm at the lower end. Or, https://www.pololu.com/product/2464 which does 4-30cm which would be equally good for the opposite reason.

5

I haven’t tried an analog one, but there’s no reason why it shouldn’t work. The supply voltage range is fine. It’s a shame it only outputs something like 0v to 3.3v, since that’s throwing resolution away but that’s not really a problem.

If it’s not a naff sensor it would probably be a better choice for Explorer HAT Pro users, since it’s not so ridiculously time sensitive and you could use 4 at a time.

6

Success :)

The Sharp GP2Y0A41SK0F works really really well with the Explorer HAT. After a bit of research at http://jeremyblythe.blogspot.co.uk/2012/09/raspberry-pi-distance-measuring-sensor.html and http://www.yoctopuce.com/EN/article/an-usb-optical-telemeter I’ve got it working within 10% accuracy, which for me is good enough (the difference between a robot being 5cm or 5.5cm away from a wall works for me). Playing around with the maths a bit may get this to be even more accurate. Here’s the code:

import explorerhat
import time

# with help from: http://www.yoctopuce.com/EN/article/an-usb-optical-telemeter
# and an idea from http://jeremyblythe.blogspot.co.uk/2012/09/raspberry-pi-distance-measuring-sensor.html

while True:
  v_readings = []
  # read the voltage 10 times so that we can get a decent average
  for i in range (0,10):
    v_readings.append(explorerhat.analog.four.read())

  av_voltage = sum(v_readings)/10.0

  if av_voltage <= 0:
    av_voltage = 0.001

  distanceInCm = 12 / av_voltage

  print("Distance: %3.2f cm   (%3.2f V) " % (distanceInCm,av_voltage))
  time.sleep(0.25)

Sampling more frequently that every quarter second is doable. There’s no timing issue unlike the HC-SR04. I got my GP2Y0A41SK0F from eBay for a few squid.

As an added bonus the black colour of the GP2Y0A41SK0F now makes Zumo George look fierce (in a Goliath sort of way), where-as before the HC-SR04 made him look like WALL-E.

7

Sorry for the thread necromancy but I’m wondering if anyone got any further with this as I to am building an Explorer Hat Pro powered Zumo bot and want to use an SR04 to stop it bumping in to things. Any pointers would be appreciated.

TIA

  • Neil.
8

Hi Neil

I stopped working with the HC-SR04 on Zumo + Explorer HAT Pro and moved to the Sharp GP2Y0A41SK0F which is very reliable. Plus, as an analogue device it gives me:

a) something to plug into the analogue pins (freeing up the digital)
b) experience of reading and interpreting an analogue voltage signal.

I like the Sharp over the HC-SR04 as no time-accurate readings are needed, which is always going to be a little iffy on a non-realtime device like the Pi. I go into using the Sharp in a fair bit of detail at http://rasptut.co.uk/files/zumo-george-part2.php . Whichever sensor you go with hopefully my (only two so far… more to come) posts on using the Zumo with the Pi will help. NB: the A+ is about 1.5mm too big on each side and I’m thinking of swapping to the Zero. Who would have thought the A+ is “too big” ;)

I do recall that Pimoroni were going to look at improving the timings to try to get things working. Although they did suggest to bypass the Explorer code and use RPi.GPIO direct may help. Sorry I can’t be more help on the HC-SR04.

1 Like
9

Thanks for the prompt and informative reply, it’s really appreciated.

I’m using the SR04 simply because I have a box of them from previous workshops. But from the looks of it, I should accept that an analogue sensor is the way to go long term. Something to shop for in the new year perhaps.

I am currently using the Pro with a Pi2, which as you say, is a little large. Plan is to look a using the Zero with an Explorer pHat, though the lack of 3.3 might make the analogue sensor a no go.

So for now I think my demo will just be robot motors run unless obstacle is detected, regardless of distance, with buttons to start and stop the sequence.

  • Neil.
10

I just checked Zumo George and he’s got his Sharp IR sensor wired up to 5V with no problem. Works a treat. I’ve a Explorer pHAT on order so will wire it all up and let you know how it goes.

11

Oooh, that’s good news! Zero powered robotics gets one step closer. Thanks for doing this, it’s really appreciated.

  • Neil.
12

[quote=“neilcford, post:9, topic:641, full:true”]
I am currently using the Pro with a Pi2, which as you say, is a little large. Plan is to look a using the Zero with an Explorer pHat, though the lack of 3.3 might make the analogue sensor a no go.[/quote]

Note that if you need 3.3V you can use a ‘stackable’ header on the pHAT, exposing the GPIO for additional purposes as well.

Incidentally, here’s the pinout so you can easily see what you’ve got to play with without risk to overlap the pExplorer’s claimed pins:

1 Like
13

I have used the HC-SR04 on the explorerhat, and addressing them via GPIO it worked perfectly. So just using it as 5v instead of 3.3v and resistors!

So feel free to try/use this cheap sensor!

1 Like
14

Thanks for letting us know. I kept with the IR sensor in the end as it provided just what I needed on Zumo George, eg: http://rasptut.co.uk/files/george-visits-digimakers-whiskers.php . Good to know that both IR and HC-SR04 are definite possibilities for the Explorer Pro HAT.

15

It does however need a good power supply. would not run off a cheap phone recharging battery for my bot…

16

I’ve had the Sharp IR sensor working both with USB power (1A supply) and via 9V battery using a UBEC (from Dawn Robotics. You can now get them from Mod My Pi).

17

Yeah the USB runs my pi, hat, and motors fine. But seemed to need more for ultrasonic sensor, which is odd. I’ll give it a fresh charge and see.

Likewise I have a ubek but trying to decide what to plug into it… might go for some RC batteries as these give loads of size choices to fit inside my Zumo! Or maybe get lipo zero and lipo battery. Or… Or… Bigger chassis than Zumo!

18

If you shave out the AA-shaped plastic inside the battery housing you can just… just mind you (it’ll bulge a little) fit a 9V in there. A flatter lipo would be far easier.

19

Hi I am also struggling to get the HC-SR04 working on the explorer phat. Did you leave the sensor plugged into the input / output pins and then reference those pins as GPIO?

20

This is my code: http://pastebin.com/HRubx53n
Note - i am no pro, but it did do the job in test…

Just reconnected and it works - using:
Output 1 to Trig
Input 1 to Echo

and for reference this might be handy:

Image added if it helps:

IMG_20170126_215918.jpg2419×3225 2.46 MB