A very interesting thread. Especially since the S2 has been out a full year now and nobody's tried to add a PING yet! But it sure shows how responsive the group is to a new challenge! Those level shifters have caused numerous problems with the Stingray to date.
Those level shifters have caused numerous problems with the Stingray to date.
As much as I understand why they're used, I'm not a huge fan of bidirectional level shifters. I guess they're okay in situations where open-drain logic with pullups is otherwise employed. But where active high/low driving in both directions is required, I'm not sure how they can be expected to perform well, since their very nature entails compromise.
As much as I understand why they're used, I'm not a huge fan of bidirectional level shifters.
I strongly dislike the level shifters in the S2. Even if you solder wires directly to the Prop pins, the level shifter will still interfere with the curcuit. You'd have to remove the level shifter in order to use the bare Prop pins.
There should be lots of other sensors that can be used with the S2. One of these ultrasonic sensors will likely work without modification. I have one and I'll try it with my S2 (as soon as I can find the sensor (I saw it a couple of days ago so I know it's somewhere around here)). Servos should be easy to use with the S2. If you have other sensors there's a good chance I'll also have one. I'll help you get any other sensors (if I have one) working with the S2. If you're thinking of purchasing a sensor, again, it's likely I already have one and I can try it out with my S2 before you purchase one yourself.
Hi Duane,
I've just downloaded the MaxBotics data sheets & they certain look interesting / more promising, do you have one kicking around that you could try?
Yes, I found mine yesterday. (If it had been a snake it would have bitten me.)
I physically connected it to my S2 earlier today. I plugged the analog pin on the MaxBotic unit to the AN0 pin on the hacker port. I haven't written any software to test it yet. I'll probably be able to test it tomorrow (Tuesday). Make that later today (I just noticed it's after midnight here).
I don't see any reason why it wont work with the S2.
I'll let you know how it goes.
Edit: Sorry Mark, I just noticed I never submitted this post. I still plan to work on the software for the MaxBotic ultrasound later today.
It looks like the MaxBotic ultrasound unit will work with the S2.
I initially tried to use an analog port on the S2 to measure the analog pin on the MaxBotic unit. I didn't think this worked well.
I switched to using the TX pin on the MaxBotic with more success. I just used this line of code to start reading the data using PST.
Pst.StartRxTx(0, -1, 1, 9600)
The unit uses an inverted signal so the mode needs to be set to "1" when using the serial driver. I used "-1" as the TX pin. I'm not sure if PST likes this or not. So far it works.
I'm working on a little demo that will play a tone based on the distance of an obstical. I hope to add the ultrasound sensor information to the "Avoid Obsticals" part of the S2 demo program.
I just wanted to let you know these units do work with the S2.
That should have worked. Can you provide more details about why it was not satisfactory?
-Phil
I was afraid you'd ask why.
I think I can expain the problem better if a use some code to compare what the S2 receives with its serial link with its analog readings. I also would like to know why it didn't work well (and I'll explain more what I mean by "didn't work well").
That should have worked. Can you provide more details about why it was not satisfactory?
-Phil
The main problem was I didn't do the math correctly. You're right, it does work. At least most of the time. There are still some glitches. I don't know if it's a bad connection or some other problem.
The S2's ADC should give 51 units per volt (255/5). The MaxBotic outputs about 10mV per inch or 100 inches per volt (I think it's really closer to 98 inches per volt). So each ACD unit should equal about two inches. It would have helped if I had done this math earlier. I was expecting larger numbers to be returned from the "get_adc_results" method.
Here's the code I used to test the unit.
CON
_UltraBaud = 9600
_DebugBaud = 9600
'Serial object enumeration
#0, _Ultra, _Debug
'Ultrasonic range units Vcc/512 per inch
OBJ
s2 : "s2"
's2_test : "s2_test"
music : "s2_music"
Pst[2] : "Parallax Serial Terminal"
VAR
BYTE state_current,state_previous,state_changed,battery_min,light_last,light_last_detect,light_running_avg
LONG periodic_last_call
PUB start | localCharacter
''S2 Demo Start-up & Program Selection
'Check if the button was held at power on
DIRA[s2#BUTTON]~
'Start hardware driver cogs and low level routines
s2.start
s2.start_motors
s2.start_tones
s2.button_mode(true, true)
Pst[_Ultra].StartRxTx(0, -1, 1, _UltraBaud)
Pst[_Debug].start(_DebugBaud)
repeat
localCharacter := Pst[_Ultra].CharIn 'rxcheck
if localCharacter <> -1
if localCharacter <> 13
Pst[_Debug].char(localCharacter)
else
Pst[_Debug].str(string(", p6 = "))
Pst[_Debug].dec(s2.get_adc_results(s2#ADC_P6))
Pst[_Debug].str(string(", p7 = "))
Pst[_Debug].dec(s2.get_adc_results(s2#ADC_P7))
Pst[_Debug].str(string(", 5V = "))
Pst[_Debug].dec(s2.get_adc_results(s2#ADC_5V))
Pst[_Debug].str(string(", 5V/2 = "))
Pst[_Debug].dec(s2.get_adc_results(s2#ADC_5V_DIV))
Pst[_Debug].str(string(", Vss = "))
Pst[_Debug].dec(s2.get_adc_results(s2#ADC_VSS))
Pst[_Debug].char(13)
The unit was connected to A0 which is referenced with "ADC_P6". I included the reading on A1 as well for comparison.
There isn't good agreement between the two sources in some of the long range data. The analog number should be about half of the number received via the serial link.
I've done some more experimenting with the MaxBotic sensor.
Phil is right (again). The S2 can read the analog signal from the sensor just fine. I must have had a bad jumper wire in my earlier tests because the strange readings (where the analog reading didn't agree with the serial output) have gone away.
I wanted to see how linear the relationship was between what the sensor sent through its serial line and with the voltage read by the S2 from the analog line.
I wrote some code to wait for a stable reading on both lines (both readings were the same three times in a row) and then use the analog reading as the "x" value and the serial output as the "y" value in order to come up with an equation of a line.
The program used two subsequent x and y readings to derive a linear equation (y = mx + b).
Ideally the y-intercept "b" would be zero. I found it varied from a low of -3.838 to a high of 3.500. I expected the slope to be close to 2. The computed slope did end up being close to 2 most of the time. It varied from a low of 1.500 to a high of 2.086.
I didn't want to two data points to be really close to each other so I required the value received through the serial line be at least 5 unit different between the two sets.
Here's the section of code doing the comparing and computing.
stableCount := 0
repeat
sNew := Pst[_Ultra].DecIn 'rxcheck
aNew := s2.get_adc_results(s2#ADC_P6)
if sPrevious == sNew and aPrevious == aNew
'if sNew <> stableS or aNew <> stableA
if ||(sNew - stableS) > 5
if ++stableCount == _StableReading
pseudoSlope := 1000 * (sNew - stableS) / (aNew - stableA)
pseudoIntercept := (1000 * sNew) - (pseudoSlope * aNew)
pseudoSerial := (pseudoSlope * aNew) + pseudoIntercept
Pst[_Debug].str(string(13, "serial = "))
Pst[_Debug].dec(sNew)
Pst[_Debug].str(string(", analog(x) = "))
Pst[_Debug].dec(aNew)
Pst[_Debug].str(string(", serial/analog = "))
'Pst[_Debug].dec(1000*sNew/aNew)
PseudoPoint(1000*sNew/aNew, 1000)
Pst[_Debug].str(string(", slope(m) = "))
'Pst[_Debug].dec(pseudoSlope)
PseudoPoint(pseudoSlope, 1000)
Pst[_Debug].str(string(", intercept(b) = "))
'Pst[_Debug].dec(pseudoIntercept)
PseudoPoint(pseudoIntercept, 1000)
Pst[_Debug].str(string(", (y = mx + b)serial(y)= "))
'Pst[_Debug].dec(pseudoSerial)
PseudoPoint(pseudoSerial, 1000)
stableS := sNew
stableA := aNew
stableCount := 0
else
stableCount := 0
else
stableCount := 0
sPrevious := sNew
aPrevious := aNew
PUB PseudoPoint(value, denominator)
if value < 0
Pst[_Debug].char("-")
-value
if value > denominator
result := value / denominator
Pst[_Debug].dec(result)
value //= denominator
else
Pst[_Debug].char("0")
Pst[_Debug].char(".")
repeat while denominator > 1
denominator /= 10
if value > denominator
result := value / denominator
Pst[_Debug].dec(result)
value //= denominator
else
Pst[_Debug].char("0")
Here's some of what was displayed in the terminal window.
I'm now confident the MaxBotic unit will work with the S2 with using either the analog line or the serial line.
The serial line appears to be more accurate the analog line and I will likely use the serial line in my S2/ultrasound projects. It is nice to know the analog line is an option in case I need one more of the digital pins for some other device.
The MaxBotic sensors also have a PWM output that I have not tested with the S2.
Now it's time to have some fun (well more fun of a different sort) and use this sensor to help the S2 find its way around.
I added the MaxBotic senor reading into the obstacle avoidance part of the S2 default program.
I removed all the normal sounds made by the default program. The only sounds made are in response to the ultrasound sensor.
The S2 plays a note based on the value returned by the MaxBotic sensor. Shorter distances produce higher notes. The interval between notes is also less with shorter distances.
When the sensor detects an object ten inches away or less, it uses the same procedures as when it detects a stall to find a different direction to travel. To differentiate between normal stalls and obstacle avoidance from the sonar reading, I added a robot sound (from S2 GUI) to indicate the sonar had detected the obstacle.
I personally think this enhanced version works much better than than original obstacle avoidance program. The ultrasound really compliments the IR sensors.
There are lots of improvements to this program I can think of but for now I'm very pleased with how well it works.
@Hover1, Thanks for the pictures. I appreciate knowing what a Rev B Ping looks like.
@Mark, I hope you get a chance to see my latest version of a S2 with an MaxBotix ultrasound sensor on it. I started a new thread to post the new code and a video of the S2 finding its way with ultrasound.
Here's another program to try with a Ping))) on an S2. Theoretically it really should not work at all, but it does on my S2. Those with S2's and Ping)))s, please give it a try, see if it works, and report your results here.
Phil I haven't read this whole thread but I checked your program with a Ping plugged into hacker port0 and at first I didn't get readings on the serial terminal but after probing the connections a bit
I looked up and noticed 5 readings on the terminal.
I think they were correct as they were 38 & 39mm and the Ping was about 1.5" from the table it was facing. All though I can't duplicate it giving readings.
What I have scoped is a hacker port with nothing plugged into it has 5v. With the Ping plugged in but no programm running it is ~3.4v and the trigger led is lit constantly. With your program running it is
~2.1v with an a/c component of ~.5v with the trigger led lit constantly.
With mine set to $9000_0000, I get sporadic correct values, intermixed with values that are way too low. So I guess each person's sweet spot is going to be a little different.
Thanks for your help, Dave. Email me your mailing address, and I'll send you an Ping))) mounting bracket for your S2.
I only tried a couple of values. The first one I tried didn't have enough 0's and I had a consistent fixed # returned. Then I tried $9600_0000 with no response, then $9000_0000 and it worked.
I may have to come up with a way to autotune the frqa value.
Try this program to find the optimum value:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
PING = 0
OBJ
pst : "Parallax Serial Terminal"
PUB start | time, i
pst.start(9600)
frqa := $9000_0000
repeat i from $8000_0000 to $a000_0000 step $0080_0000
frqa := i
dira[PING]~~
waitcnt(cnt + clkfreq / 100)
outa[PING]~~
waitcnt(cnt + clkfreq / 1000)
outa[PING]~
time := -cnt
ctra := constant(%00110 << 26)
waitpeq(0, constant(1 << PING), 0)
time += cnt
ctra := 0
pst.hex(i, 8)
pst.char(" ")
pst.dec((((time / 80 - 800) >> 1) * 10_000 / 29034 - 90) #> 0)
pst. str(string(" mm", 13))
You'll get an output that looks something like this:
80000000 1052 mm
80800000 0 mm
81000000 780 mm
81800000 0 mm
82000000 667 mm
82800000 0 mm
83000000 662 mm
83800000 0 mm
84000000 645 mm
84800000 0 mm
85000000 645 mm
85800000 0 mm
86000000 638 mm
86800000 0 mm
87000000 650 mm
87800000 0 mm
88000000 640 mm
88800000 0 mm
89000000 645 mm
89800000 0 mm
8A000000 642 mm
8A800000 0 mm
8B000000 634 mm
8B800000 0 mm
8C000000 637 mm
8C800000 0 mm
8D000000 637 mm
8D800000 0 mm
8E000000 632 mm
8E800000 0 mm
8F000000 471 mm
8F800000 0 mm
90000000 49 mm
90800000 2811 mm
91000000 2811 mm
91800000 2811 mm
92000000 2811 mm
92800000 2811 mm
93000000 2811 mm
93800000 2816 mm
94000000 2811 mm
94800000 2811 mm
95000000 2811 mm
95800000 2811 mm
96000000 2811 mm
96800000 2816 mm
97000000 2810 mm
97800000 2816 mm
98000000 2811 mm
98800000 2816 mm
99000000 2810 mm
Pick a number from the center of the steady range. In my case that would be $9480_0000.
Comments
Thank you for the offer regarding sensors I'm sure it won't be long before you hear from me again !
I'm pretty astounded by quick response I got to my original question & the levels everyone went to help answer the issue, way beyond my expectations.
Hopefully a simple solution will present itself, given time, meanwhile I'm off to play with my S2
Once again, thanks all
Mark
-Phil
http://forums.parallax.com/showthread.php?136528-S2-Expansion-Board
I strongly dislike the level shifters in the S2. Even if you solder wires directly to the Prop pins, the level shifter will still interfere with the curcuit. You'd have to remove the level shifter in order to use the bare Prop pins.
Hi Duane,
I've just downloaded the MaxBotics data sheets & they certain look interesting / more promising, do you have one kicking around that you could try?
Cheers
Mark
I physically connected it to my S2 earlier today. I plugged the analog pin on the MaxBotic unit to the AN0 pin on the hacker port. I haven't written any software to test it yet. I'll probably be able to test it tomorrow (Tuesday). Make that later today (I just noticed it's after midnight here).
I don't see any reason why it wont work with the S2.
I'll let you know how it goes.
Edit: Sorry Mark, I just noticed I never submitted this post. I still plan to work on the software for the MaxBotic ultrasound later today.
It looks like the MaxBotic ultrasound unit will work with the S2.
I initially tried to use an analog port on the S2 to measure the analog pin on the MaxBotic unit. I didn't think this worked well.
I switched to using the TX pin on the MaxBotic with more success. I just used this line of code to start reading the data using PST.
The unit uses an inverted signal so the mode needs to be set to "1" when using the serial driver. I used "-1" as the TX pin. I'm not sure if PST likes this or not. So far it works.
I'm working on a little demo that will play a tone based on the distance of an obstical. I hope to add the ultrasound sensor information to the "Avoid Obsticals" part of the S2 demo program.
I just wanted to let you know these units do work with the S2.
-Phil
I think I can expain the problem better if a use some code to compare what the S2 receives with its serial link with its analog readings. I also would like to know why it didn't work well (and I'll explain more what I mean by "didn't work well").
I'll post some examples soonish.
Happy New Year to you both & thank you!
Cheers
Mark
The S2's ADC should give 51 units per volt (255/5). The MaxBotic outputs about 10mV per inch or 100 inches per volt (I think it's really closer to 98 inches per volt). So each ACD unit should equal about two inches. It would have helped if I had done this math earlier. I was expecting larger numbers to be returned from the "get_adc_results" method.
Here's the code I used to test the unit.
CON _UltraBaud = 9600 _DebugBaud = 9600 'Serial object enumeration #0, _Ultra, _Debug 'Ultrasonic range units Vcc/512 per inch OBJ s2 : "s2" 's2_test : "s2_test" music : "s2_music" Pst[2] : "Parallax Serial Terminal" VAR BYTE state_current,state_previous,state_changed,battery_min,light_last,light_last_detect,light_running_avg LONG periodic_last_call PUB start | localCharacter ''S2 Demo Start-up & Program Selection 'Check if the button was held at power on DIRA[s2#BUTTON]~ 'Start hardware driver cogs and low level routines s2.start s2.start_motors s2.start_tones s2.button_mode(true, true) Pst[_Ultra].StartRxTx(0, -1, 1, _UltraBaud) Pst[_Debug].start(_DebugBaud) repeat localCharacter := Pst[_Ultra].CharIn 'rxcheck if localCharacter <> -1 if localCharacter <> 13 Pst[_Debug].char(localCharacter) else Pst[_Debug].str(string(", p6 = ")) Pst[_Debug].dec(s2.get_adc_results(s2#ADC_P6)) Pst[_Debug].str(string(", p7 = ")) Pst[_Debug].dec(s2.get_adc_results(s2#ADC_P7)) Pst[_Debug].str(string(", 5V = ")) Pst[_Debug].dec(s2.get_adc_results(s2#ADC_5V)) Pst[_Debug].str(string(", 5V/2 = ")) Pst[_Debug].dec(s2.get_adc_results(s2#ADC_5V_DIV)) Pst[_Debug].str(string(", Vss = ")) Pst[_Debug].dec(s2.get_adc_results(s2#ADC_VSS)) Pst[_Debug].char(13)The unit was connected to A0 which is referenced with "ADC_P6". I included the reading on A1 as well for comparison.
There isn't good agreement between the two sources in some of the long range data. The analog number should be about half of the number received via the serial link.
Here's some of the output.
I'll fiddle around with this a bit more to see if I can figure out what causes the problem with the analog reading.
You're welcome. And I hope you're have a good new year.
I confident the MaxBotix units will work with the S2.
Phil is right (again). The S2 can read the analog signal from the sensor just fine. I must have had a bad jumper wire in my earlier tests because the strange readings (where the analog reading didn't agree with the serial output) have gone away.
I wanted to see how linear the relationship was between what the sensor sent through its serial line and with the voltage read by the S2 from the analog line.
I wrote some code to wait for a stable reading on both lines (both readings were the same three times in a row) and then use the analog reading as the "x" value and the serial output as the "y" value in order to come up with an equation of a line.
The program used two subsequent x and y readings to derive a linear equation (y = mx + b).
Ideally the y-intercept "b" would be zero. I found it varied from a low of -3.838 to a high of 3.500. I expected the slope to be close to 2. The computed slope did end up being close to 2 most of the time. It varied from a low of 1.500 to a high of 2.086.
I didn't want to two data points to be really close to each other so I required the value received through the serial line be at least 5 unit different between the two sets.
Here's the section of code doing the comparing and computing.
stableCount := 0 repeat sNew := Pst[_Ultra].DecIn 'rxcheck aNew := s2.get_adc_results(s2#ADC_P6) if sPrevious == sNew and aPrevious == aNew 'if sNew <> stableS or aNew <> stableA if ||(sNew - stableS) > 5 if ++stableCount == _StableReading pseudoSlope := 1000 * (sNew - stableS) / (aNew - stableA) pseudoIntercept := (1000 * sNew) - (pseudoSlope * aNew) pseudoSerial := (pseudoSlope * aNew) + pseudoIntercept Pst[_Debug].str(string(13, "serial = ")) Pst[_Debug].dec(sNew) Pst[_Debug].str(string(", analog(x) = ")) Pst[_Debug].dec(aNew) Pst[_Debug].str(string(", serial/analog = ")) 'Pst[_Debug].dec(1000*sNew/aNew) PseudoPoint(1000*sNew/aNew, 1000) Pst[_Debug].str(string(", slope(m) = ")) 'Pst[_Debug].dec(pseudoSlope) PseudoPoint(pseudoSlope, 1000) Pst[_Debug].str(string(", intercept(b) = ")) 'Pst[_Debug].dec(pseudoIntercept) PseudoPoint(pseudoIntercept, 1000) Pst[_Debug].str(string(", (y = mx + b)serial(y)= ")) 'Pst[_Debug].dec(pseudoSerial) PseudoPoint(pseudoSerial, 1000) stableS := sNew stableA := aNew stableCount := 0 else stableCount := 0 else stableCount := 0 sPrevious := sNew aPrevious := aNew PUB PseudoPoint(value, denominator) if value < 0 Pst[_Debug].char("-") -value if value > denominator result := value / denominator Pst[_Debug].dec(result) value //= denominator else Pst[_Debug].char("0") Pst[_Debug].char(".") repeat while denominator > 1 denominator /= 10 if value > denominator result := value / denominator Pst[_Debug].dec(result) value //= denominator else Pst[_Debug].char("0")Here's some of what was displayed in the terminal window.
I'm now confident the MaxBotic unit will work with the S2 with using either the analog line or the serial line.
The serial line appears to be more accurate the analog line and I will likely use the serial line in my S2/ultrasound projects. It is nice to know the analog line is an option in case I need one more of the digital pins for some other device.
The MaxBotic sensors also have a PWM output that I have not tested with the S2.
Now it's time to have some fun (well more fun of a different sort) and use this sensor to help the S2 find its way around.
I added the MaxBotic senor reading into the obstacle avoidance part of the S2 default program.
I removed all the normal sounds made by the default program. The only sounds made are in response to the ultrasound sensor.
The S2 plays a note based on the value returned by the MaxBotic sensor. Shorter distances produce higher notes. The interval between notes is also less with shorter distances.
When the sensor detects an object ten inches away or less, it uses the same procedures as when it detects a stall to find a different direction to travel. To differentiate between normal stalls and obstacle avoidance from the sonar reading, I added a robot sound (from S2 GUI) to indicate the sonar had detected the obstacle.
I personally think this enhanced version works much better than than original obstacle avoidance program. The ultrasound really compliments the IR sensors.
There are lots of improvements to this program I can think of but for now I'm very pleased with how well it works.
Sure enough, the external resonator was added to Rev B.
Front side. Rev A on the left.
Back Side. Rev B on the right.
@Mark, I hope you get a chance to see my latest version of a S2 with an MaxBotix ultrasound sensor on it. I started a new thread to post the new code and a video of the S2 finding its way with ultrasound.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PING = 0 OBJ pst : "Parallax Serial Terminal" PUB start | time pst.start(9600) frqa := $9800_0000 repeat dira[PING]~~ waitcnt(cnt + clkfreq / 100) outa[PING]~~ waitcnt(cnt + clkfreq / 1000) outa[PING]~ time := -cnt ctra := constant(%00110 << 26 | PING) waitpeq(0, constant(1 << PING), 0) time += cnt ctra := 0 pst.dec(((time / 80 - 800) >> 1) * 10_000 / 29034) pst. str(string(" mm", 13))Thanks,
-Phil
I looked up and noticed 5 readings on the terminal.
I think they were correct as they were 38 & 39mm and the Ping was about 1.5" from the table it was facing. All though I can't duplicate it giving readings.
What I have scoped is a hacker port with nothing plugged into it has 5v. With the Ping plugged in but no programm running it is ~3.4v and the trigger led is lit constantly. With your program running it is
~2.1v with an a/c component of ~.5v with the trigger led lit constantly.
I have a rev A ping
Try lowering the value ($9800_0000) assigned to frqa just a little bit, and see if you get consistent results.
-Phil
Thanks for your help, Dave. Email me your mailing address, and I'll send you an Ping))) mounting bracket for your S2.
-Phil
Try this program to find the optimum value:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PING = 0 OBJ pst : "Parallax Serial Terminal" PUB start | time, i pst.start(9600) frqa := $9000_0000 repeat i from $8000_0000 to $a000_0000 step $0080_0000 frqa := i dira[PING]~~ waitcnt(cnt + clkfreq / 100) outa[PING]~~ waitcnt(cnt + clkfreq / 1000) outa[PING]~ time := -cnt ctra := constant(%00110 << 26) waitpeq(0, constant(1 << PING), 0) time += cnt ctra := 0 pst.hex(i, 8) pst.char(" ") pst.dec((((time / 80 - 800) >> 1) * 10_000 / 29034 - 90) #> 0) pst. str(string(" mm", 13))You'll get an output that looks something like this:
Pick a number from the center of the steady range. In my case that would be $9480_0000.
-Phil
-Phil