Ultrasonic Sensor and 8mA

General Discussion
1

Hello,

The operating current is 8mA for the Grove Ultrasonic Sensor…

The BBB, per pin, can supply about 4mA. Is one to believe that this sensor will no work for three pins on the BBB, e.g. 3.3v, GND, GPIO (being the 4mA reference here)?

I was just going to attach things and see what happens but…

  1. I am trying to make sure I do no break things.
  2. This is not a HC-SR04.
  3. I have more sensors but the BBB in question should live on!

Anyway, I am following along here: Sensors — BeagleBoard Documentation

Is that wiring correct? It seems the 3.3v is not connected to anything in the diagram.

Seth

P.S. Here are the ideas from Seeed Studio: Grove - Ultrasonic Ranger | Seeed Studio Wiki

Any ideas are welcomed.

Oh!

#!/usr/bin/python3

#import os
#from pathlib import Path

from time import sleep

ms = 250

pin = '0'

IIOPATH = '/sys/bus/iio/devices/iio:device0/in_voltage' + pin + '_raw'

print('Ctrl-C to stop ')

f = open(IIOPATH, 'r')

try:
    while True:
        f.seek(0)
        data = f.read()[:-1] # What does the [:-1] do in this line?
        print('data = ' + data)
        sleep(ms / 1000)
except KeyboardInterrupt:
    f.close()

I am not sure but I found this source on the docs. pages. The ADC pin is listed as P9_39. I have a resistor attached to P9_39.

I am receiving values in the one digit format so far. Anyway, a bit lost but trying here!

Update

I figured out what slicing is currently for taking out the last line for data = f.read()[:-1] # What does the [:-1] do in this line?

But…what is it slicing? ()? Is it slicing () which is empty? Does this go back to the first section of somewhere…see lost a bit.

2

Okay and Oops,

I am using GPIO now instead of the ADC. I am not sure how I got on the kick of using the ADC for getting output via GPIO but… Nevertheless, I did.

I am trying a new script I found but, and this happens, I am not 100% sure how to devise my work.

import sys
from time import sleep
from pathlib import Path
import os

usleep = lambda x: sleep(x / 1000000.0)

UltraOne = Path('/sys/class/gpio/gpio60/direction')
UltraTwo = Path('/sys/class/gpio/gpio60/value')

_TIMEOUT1 = 1000
_TIMEOUT2 = 10000

class GroveUltrasonicRanger(object):
    def __init__(self):
        self.write_text('low')

    def _get_distance(self):
        self.self = self
        self.write_text('low')
        usleep(2)
        self.write_text('high')
        usleep(10)
        self.write_text('low')

        self.write_text('in') = UltraTwo # This line makes no sense so far...
        
        t0 = time.time()
        count = 0
        while count < _TIMEOUT1:
            if self.UltraTwo.read():
                break
            count += 1
        if count >= _TIMEOUT1:
            return None

        t1 = time.time()
        count = 0
        while count < _TIMEOUT2:
            if not self.UltraTwo.read():
                break
            count += 1
        if count >= _TIMEOUT2:
            return None

        t2 = time.time()

        dt = int((t1 - t0) * 1000000)
        if dt > 530:
            return None

        distance = ((t2 - t1) * 1000000 / 29 / 2)    # cm

        return distance

    def get_distance(self):
        while True:
            dist = self._get_distance()
            if dist:
                return dist

Grove = GroveUltrasonicRanger

def main():
    if len(sys.argv) < 2:
        print('Usage: {} pin_number'.format(sys.argv[0]))
        sys.exit(1)

    sonar = GroveUltrasonicRanger(int(sys.argv[1]))

    print('Detecting distance...')
    while True:
        print('{} cm'.format(sonar.get_distance()))
        sleep(2)

if __name__ == '__main__':
    main()

That is the source for now. I need to better interpret the pathlib.Path module in Python3 at GPIO being an input.

Anyway, if you get close to making this source work, please let me know. For now, I am trying to make it work w/ the ideas in Python3 w/ pathlib.Path.

Seth

P.S. I got the source, most of it, from seeed studio’s wiki.

3

Have you considered C. It is the best way to go if you are using GPIO. Nothing wrong with python and in certain applications it is much better than C. However, when you need to communicate with the real world C is the best option. Besides, you can hit everything yourself and don’t depend on others to create a library. You can include C in your python code, however that requires C coding so you still need to know C.
I have read many of your posts and what you are trying to do will be more fruitful if you switched over to C. Just plain old C and gcc not C# or C++.

4

Hello @foxsquirrel ,

Okay. Whelp, C it is. I am a very entry level programmer w/ years of experience but w/out making things from scratch, I have little experience making things. Redundant chat here…

Thank you…I will try w/ C and/or Python3 time permitting.

Seth

P.S. I am going to review the docs. again to look over ideas and see if I can configure something from the docs.beagleboard.org instructions.

5

gomer disagrees. NO language running on linux is capable of the microsecond timing needed to get accurate readings from these devices… The only BBB solution is to use the PRU. See Derek Molloy excellent example in his ‘Exploring BeagleBone’ book.

If your sensor is not a HC-SR04, it sure looks like one, and seems to act like one. check the output closely from the link that you provided:

ansonhe@Ansons-Macbook-Pro ~:aip shell -n -c “runfile /Users/ansonhe/Desktop/ArduPy-ultrasonic.py”
Positional argument (/dev/cu.usbmodem1413101) takes precedence over --open.
Connected to ardupy
The distance to obstacles in front is: 3 centimeter
The distance to obstacles in front is: 1 inches
The distance to obstacles in front is: 7 centimeter
The distance to obstacles in front is: 2 inches
The distance to obstacles in front is: 6 centimeter
The distance to obstacles in front is: 2 inches
The distance to obstacles in front is: 6 centimeter
The distance to obstacles in front is: 2 inches

the first reading should be all you need to know. 3 centimeters is well over 2 inches yet it is reporting it as 1 (one) inch… ouch
then the next two readings report that 2 inches is BOTH equivalent to 6 AND 7 centimeters … OUCH!

it is all a matter of how accurate a measurement you need.

$.02

2 Likes
6

If it helps, try to flesh it out using blocks. Break the blocks apart and write a function for that block.
Secret to winning is do small steps, first function works, then move on to the second.

Also,
Learn to do this

//my comments go here

Six months later all you will do is stare at the monitor…

1 Like
7

One more, use cherrytree for your notes.

You can run script and such from a code block, plus much more.

8

good attitude! … I’ve reread your post have have these thoughts:

  • do you have access to or are you willing to get an oscilloscope?
    • expensive one unnecessary … even a kit build would do for this job
  • don’t mess with bi-directional IO pin… I’m not sure there is a way to do this with BBB
    • even if possible, to change direction of the pin in the short time between end of pulse and start of echo would require very tricky timing
    • buy 1 or more hc-sr04 (inexpensive) sensors instead
  • use the BBB pwm to generate your trigger signals … I can help with this easily if you are interested
  • attach the echo pin to your scope, this is a sure way NOT to damage your BBB
    • if echo pin is attached to scope, you can safely up your vcc to 5v (better)
    • this sidesteps the accuracy weakness of any language in the linux system
  • once you are skilled and experienced observing the behavior of your sensor consider how to connect echo pin to BBB or Arduino or or or

good luck!
gomer

1 Like
9

Hello @gomer ,

So, bi-directional GPIO is not used here. Okay. I see you say it is a timing issue. No worries. I will try another route.

I have an oscilloscope, i.e. Rigol (cheap version). It is a DS1102E. Anyway, I have a couple of these Seeed Studio versions and wanted to use them. Are you saying I should use HC-SR04 instead for the sensors?

Seth

P.S. It may take time on my part to retrieve the HC-SR04s. So, even though I may no reply w/ the current needed hardware, I can reply w/ other ideas in the meantime.

10

That is a FINE scope, more than adequate. With the two channels, you can see both the triggering and the echo.

I don’t have any experience with these, but from the link that you provided earlier, they use one pin for BOTH triggering and echo… It is just an additional complication that someone ELSE might be able to help you with. I’ve done multiple projects with the hc-sr04, and they only cost a few dollars. Just a suggestion.

Using the scope, you’ll see the raw data of what your MCU (BBB) will eventually see. This makes it less likely that you will blame the (cheap) sensor for what is an issue with the MCU (given that many try to use this sensor with linux… will never work accurately as I’ve already brayed.)

good luck!
gomer