Controlling multiple Ping sensor

Kh3ldrin

Hey guys, i am very new with robotic stuffs·and got·a couple of questions to ask regarding BS2.
I read through the functionalities of the BS2 and its written in 1 of the segments that the BS2 can source and sink up to 30mA of current per I/O pin, so what does source and sink means?
Also the total amount of current drawn through the BS2 cant exceed 60mA per group of 8 pins, are these groups of 8 pins meaning pin 0-7, 8-15?
And the last question is how many Ping ultrasonic sensor can 1 BS2 drive?

Thanks in advance.

Mike Green

There are two CMOS transistors in a BS2 output circuit, one that connects the output pin to Vdd, the other that connects it to ground (Vss). By connecting the I/O pin to Vdd, it's considered to be "sourcing" current. By connecting the I/O pin to Vss, it's considered to be "sinking" current. I believe a BS2 I/O pin can source 20mA or sink 25mA. The group limits are 50mA per group (pins 0-7 and pins 8-15 each constitute a group). The total amount of current for the entire BS2 is (I believe) 100mA. Since the BS2 uses a PIC16F57 microprocessor, you can download the datasheet for this device from Microchip. The datasheet has the official limits.

Since the BS2 doesn't have to provide power for the PING))), only a control signal, it could theoretically drive 16 PING)))s, one for each I/O pin. The PING)))s would have to be powered by an external regulator of some sort like the one on the Board of Education or Stamp Super Carrier Board or something you might make for yourself. Look at the documentation for the PING))) for the actual amount of power supply current needed. Note that it doesn't make much sense to trigger several PING)))s at the same time since the sound pulse of one will typically be received by others and result in a false reading.

SRLM

Plus it's not even possible to have multiple Pings))) going at once since the BS2 can only do one operation at a time. Now if you were to use the Propeller you might have to start thinking more about the source/sink, but with the BS2 on a regulated board you can do most operations short of driving a motor or LED without worrying about current. If the device has dedicated Vdd/Vss lines then the power is coming from the regulator/battery, and not the BS2.

Kh3ldrin

Thanks guys for the reply.

So can the BS2 do an operation simultaneously for multiple pings))), assuming they werent affected by each other (facing different directions/placed far from each other)?

The operation i meant here is to fire all the pings at once and accept the very first return pulse from·any of the pings))), i believe this could be done by including the pin numbers for the other pings))) in the fire/acquire codes. I am not sure·about this as i have not done any coding as well, just theorycrafting that this might work.·(using pings)))/BS2 for proximity detection)

Thanks again

allanlane5

No. The BS2 is a "single-tasking" architecture. The Ping is designed for the BS2 -- you 'trigger' a 'ping', then the BS2 waits in a "PULSIN" instruction to get back a pulse-width from the PING indicating the 'echo time' of the PING signal.

The Ping works on ultrasonic sound, 40 Khz I believe. The Ping is good to about 10 feet. The result of this is that if you DID 'fire off' two Pings, the likelihood is that the first ping would get 'return' signals from the second ping, which would confuse it -- you wouldn't get reliable distance signals from the second ping.

It IS possible (with a little external hardware for a hardware 'tick') to get a form of "Basic Language multi-tasking" out of the BS2 -- but it's slow (2000 to 10,000 instructions per second max). Then again, that's usually "fast enough" for many robotics applications.

SRLM

You might be able to hook up the Pings))) all to one IO pin, and use that to "multitask". However, you'll have to be careful that only one of them sends a return pulse. Otherwise you could get a very long pulse coming in.

Zoot

Somebody said...
You might be able to hook up the Pings))) all to one IO pin, and use that to "multitask". However, you'll have to be careful that only one of them sends a return pulse. Otherwise you could get a very long pulse coming in.

You'd need a bidirectional MUX (controlled itself by a few other pins) to do this. This way you could select the outgoing/incoming I/O pin. Is pin count really the issue here, or just running lots of PINGs? If the latter, then here is some rough code that will fire and sample 8 pings on one port of a Stamp (remember that Ping can take nearly 20ms to return a long pulse, so you would not be able fire all of them between, say, servo pulses. But you could fire ONE each between servo pulses, getting a full bank of readings in 8 servo pulses. In any case, this will sample all of 'em in one go....

ManyPings PIN 0 ' pings on pins 0-7

i VAR Nib ' counter
work VAR Word ' work word, not necessary but will speed up the routine and save code space
sonarDist VAR Word(8) ' 8 distances
trigVal CON 10 ' or whatever gives you approx 10us on your flavor Stamp
snrConv CON 99999 ' sorry I don't have conversion value in front of me [img]http://forums.parallax.com/images/smilies/smile.gif[/img]

FOR i = 0 TO 7
   LOW ManyPings(i)
   PULSOUT ManyPings(i), trigVal
   PULSIN ManyPings(i), work
   work = work >> 1 '  divide by 2
   work = work ** snrConv
   sonarDist(i) = work
NEXT

To take this further, if you don't resuse the index counter, you can just sample one ping at a time each time through your main loop, devoting other time to refreshing servo pulses, checking sensors, whatever:

ManyPings PIN 0 ' pings on pins 0-7

currPing VAR Nib ' counter
work VAR Word ' work word, not necessary but will speed up the routine and save code space
sonarDist VAR Word(8) ' 8 distances
trigVal CON 10 ' or whatever gives you approx 10us on your flavor Stamp
snrConv CON 99999 ' sorry I don't have conversion value in front of me [img]http://forums.parallax.com/images/smilies/smile.gif[/img]


Main:

  'tons of code

  ' more code

  ' send single servo pulse

  ' check a sensor

  ' do one ping
   LOW ManyPings(currPing)
   PULSOUT ManyPings(currPing), trigVal
   PULSIN ManyPings(currPing), work
   work = work >> 1 '  divide by 2
   work = work ** snrConv
   sonarDist(currPing) = work
   currPing = currPing + 1 & $7  ' next ping, wraparound after 8 pings

   GOTO Main

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

SRLM

It's probably cheaper to just mount a Ping))) on a servo rather than have a dozen Pings))) mounted all around. Not to mention it saves you IO pins. However, If you are trying to cut down on moving parts, multiple Pings))) would do so. What is your project?

dwbowen

Wouldn't something like this work?

' {$STAMP BS2px}
' {$PBASIC 2.5}

dist0 VAR WORD
dist1 VAR WORD
dist2 VAR WORD
dist3 VAR WORD

main:

PULSOUT 0, 5
PULSIN 0, 1, dist0
PULSOUT 1, 5
PULSIN 1, 1, dist1
PULSOUT 2, 5
PULSIN 2, 1, dist2
PULSOUT 3, 5
PULSIN 3, 1, dist3

DEBUG HOME, DEC3 ? dist0
DEBUG DEC3 ? dist1
DEBUG DEC3 ? dist2
DEBUG DEC3 ? dist3

GOTO main

SRLM

You'll want to add some pause statements between the PULSOUT/PULSIN code in order to give time for the Ultransonic noise and echos to die away. Otherwise you might get conflicting data.

Zoot

Roll the multiple pulsins/pulsouts into a loop -- saves lots of code space and lets you keep things consistent. See my example above.

Also, I don't think the pauses are necessary -- I've got multiple pings on a few projects -- since the ping has setup/transmit times, and given the relative slowness of the stamp, by the time the next pulsout trigger rolls around the echos will have died away.

On a faster chip, such as SX or Prop, a bit of delay may be necessary.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

SRLM

Ah. Thanks for the correction.

Kh3ldrin

Thanks all for the replies, what i need is really just a proximity detection on the front and rear end of my project robot, so i guess i only need to fire 2 pings))) at both ends together and which ever detects anything will stop the robot. I am only on the first phase of the project, so something simple will do, thats why i didnt want to include all the servos and stuffs.

SRLM

Kh3ldrin said...
...which ever detects anything will stop the robot.

It would be kinder on your motors if you had some sort of ramping solution to stop the bot. Keep in mind that the range on the Ping is about 10 feet, so you'll need to have an area of 20 feet clear at either end of your robot. If you are working inside, that will probably be a problem and cause your 'bot to play dead. Seems better to have the robot turn when something is detected within, say, 2 feet.

Kh3ldrin

I didnt think about that haha, thanks.
Anyway i think its possible to adjust the gain on the ping))) so that it only transmit for maximum distance of 4ft? I guess this will prevent the robot from playing dead.

SRLM

You can't adjust how long the ping))) waits for a echo: it's built into the circuitry. At least, there's nothing in the documentation about it. So you're stuck with a 10 foot maximum distance. However, why is this a problem? Your BS2 can convert it to a true/false value in just a few lines of code. The way that you seem to be doing it is very heavy on the hardware side of things, while ignoring the software part.

patterson7019

You can get measurements from about 2 cm (0.8 inches) to 3 meters (3.3 yards). It has been working well on my robot in the house. To further that, all you need to do is check if something is closer then say 10cm, and if so, stop. About 40-50cm is a good distance to turn to avoid the object rather then stop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://perfectaperture.com/robb

Kh3ldrin

Ok thanks guys with the advices.