Okay, I'm about ready to drill some holes in a servo case and attempt to read a striped pattern on one of the gears (yet to be affixed).
Is there a prefered orientation for these? should the two dots on the sensor be parallel with the encoder lines? Is there in info about how thin the encoder lines can be? I figure I'll try to keep the lines at least 1/8 inch wide.
Has anyone used these with a Prop yet? I don't suppose and extra 4.7K resistor on the output line will interfere with the sensor's function?
I've read ecro mention inkjet printed stripes don't get picked up by the sensor. Have any of you tried a Sharpie to darken the stripes?
I also used a 10k pullup rather than the 6.8k in erco's schematic. I didn't notice that the orientation made any difference but that probabl;y depends on how wide the stripes are...
Have you got access to a laser printer & coated paper? That's best IMO. I blanch at the thought of manually darkening via Sharpie. Maybe try coated paper in your inkjet printer first.
The disks will be pretty small so it won't take very long to darken the stripes (if needed) with a Sharpie. I did this with my Roboni-I encoders.
I think I had to use aluminum foil on white gear in order to get the IR to reflect. The white plastic was transparent to IR and didn't reflect it on its own.
Once I added the foil, I blackened in some stripes. It was kind of odd not to have the IR reflect back at all from a nice white surface. (The stripes are on the other side of the gear. This was the only photo that was easy to find of it.)
Good to know Ron. I'll try the inkjet stripes before darkening them with a Sharpie. I say you video earlier. Very cool.
I'm not sure what it is, but there's just something cool about being able to read stripes on a wheel like you did in your video. I think part of the appeal is the sensor is reading the reading the stripes faster than one would think is possible. Those stripes are just sailing past in a blur and yet the encoders don't have a problem detecting them.
I also used a 10k pullup rather than the 6.8k in erco's schematic.
Also good to know. I have lots of 10k resistors handy.
Looking at the schematic erco posted in post #1, it looks like pin 3 pulls the output low.
Do any of you know if pin 3 drives the line high? If it is an open drain output, then I shouldn't need an additional current limiting resistor on between the output and the Prop I/O pin. If it's not open drain, then I will need a current limiting resistor but then the pull-up resistor doesn't make sense.
I'm going to assume it's an open drain output unless told otherwise.
The 6.8k is between 5V and pin3 - so it is pulling it high.
Right, the resistor pulls it high, pin 3 pulls it low (when it's signalling a pulse). I suppose it's possible for pin 3 to be driven both high and low, but then why add a pull-up?
I could find a datasheet to be sure, but I'm betting the schematic as posted is Prop pin safe.
Right, the resistor pulls it high, pin 3 pulls it low (when it's signalling a pulse). I suppose it's possible for pin 3 to be driven both high and low, but then why add a pull-up?
I could find a datasheet to be sure, but I'm betting the schematic as posted is Prop pin safe.
Sorry Duane, I read it wrong - thought you were saying that the resistor was a pulldown - I get your scenario/concern with the Prop now.
. . . I'm betting the schematic as posted is Prop pin safe.
If I connect the output to ground I measure 740uA which is more than a Prop pin can safely handle. But when I measure the current to through a Prop input pin, it's only 170uA. The cutoff limit for a Prop pin is 500uA. So I'm pretty sure (again) these sensors are Prop safe.
Here's a picture of one of the sensors ready to be mounted inside a servo.
I used 1/8 watt resistors and a 0603 smt 0.1uF cap on the bottom of the piece of board.
Duane: You're making me proud! Your quick use of these sensors and tidy little soldering job on that tiny little package is quite impressive. How DO you do it?
Martin_H says he's also using one soon, and Ron Czap was the first guy in the pool! Mike Cook bought 50, and midrobots got 20, so I'm expecting big things from this forward deployment.
Repeating, if we Forumistas ever decide to team up on a collaborative project, applying our respective strengths, the world is our oyster. There is NOTHING this team could not accomplish!
For anyone who missed out on the hundred pack deals: (the ten-packs are still available): As promised, Tim at Junun Robotics re-stocked these. He's been out for a while, but now that he's been erco-sized, his price has dropped from $2.25 IIRC to the affordable new price of $1.50 .
I've been having some trouble with my plan to add an encoder to a servo.
I'm getting a lot of noise on the encoder line when the servo is turned on.
I'm using two different techniques to monitor the encoders with the Propeller. One is to use the "ina" statement.
PUB EncoderLoop'' count pin transitions.
oldState := 2 ' impossible state so currentState won't match on the first loop
repeat
currentState := ina[ENCODER_PIN]
if currentState <> oldState
oldState := currentState
encoderCount++
This isn't as supseptible to noise as the technique using counters.
ctra[30..26] := 010 ' set up posative edge detection from page 159 of the PEK.
ctra[5..0] := ENCODER_PIN
frqa~
phsa~
ctrb[30..26] := 110 ' set up negative edge detection from page 159 of the PEK.
ctrb[5..0] := ENCODER_PIN
frqb~
phsb~
ZeroCount
' skip to ZeroCount method
PUB ZeroCount
'' Must be called from cog where counters were setup.
measureSpeedTimer := cnt
encoderCount := 0
previousCountIna := 0
readEncoderCount := 0
frqa~
phsa~
ctrb[30..26] := 110 ' set up negative edge detection from page 159 of the PEK.
ctrb[5..0] := ENCODER_PIN
frqb~
phsb~
frqa := 1
frqb := 1
Here's the method to display the data.
PUB DisplayCounts
'' Must be called from cog where counters were setup.
Debug.Position(0, DATA_LOC_Y)
Debug.str(string("encoderCount = "))
Debug.Dec(encoderCount)
Debug.str(string(13, "phsa + phsb = "))
Debug.Dec(phsa + phsb)
Debug.ClearEnd
Debug.str(string(13, " phsa = "))
Debug.Dec(phsa)
Debug.ClearEnd
Debug.str(string(13, " phsb = "))
Debug.Dec(phsb)
Debug.ClearEnd
Debug.str(string(13, "ledDisplayMode = "))
Debug.str(ModeToStr)
Debug.ClearEnd
With the servo off, I can manually spin the gear and the two different techniques agree.
Here's some sample output.
fileName = QsEncoderDemo130904e
Enter number to indicate which mode to use.
4) LEDs display binary count of counter b.
3) LEDs display binary count of counter a.
2) LEDs display binary count of both counters
1) LEDs display binary count of ina changes
0) LED display encoder pin state (on or off)
Enter "z" to zero encoder count.
encoderCount = 1914
phsa + phsb = 1914
phsa = 957
phsb = 957
ledDisplayMode = BINARY_COUNT_INA_MODE
localSpeedIna = 51
localSpeedCtr = 51
The above output was with me hand turning the gear. As you can see the two techniques used to read the encoder are in agreement.
This next output is with the motor powered and turning relatively slow.
fileName = QsEncoderDemo130904e
Enter number to indicate which mode to use.
4) LEDs display binary count of counter b.
3) LEDs display binary count of counter a.
2) LEDs display binary count of both counters
1) LEDs display binary count of ina changes
0) LED display encoder pin state (on or off)
Enter "z" to zero encoder count.
encoderCount = 2135
phsa + phsb = 8365
phsa = 4182
phsb = 4183
ledDisplayMode = BINARY_COUNT_INA_MODE
localSpeedIna = 75
localSpeedCtr = 1121
With the motor on, the counters must be picking up some noise because they the start counting very quickly when the gear is moving slowly.
I tried adding a Schmitt trigger to see if it would help. The Schmitt trigger made it so the "ina" technique also picked up the noise (not as much as the counters though).
So far, my idea of having an encoder inside a servo isn't working out well (again).
Any thoughts on how to reduce the noise from the servo motor?
In case anyone is interested, I've attached the spin file to this post.
Edit: See post #77 for most recent version of code.
There should be room to fit a few caps in with the motor. I'll give it a try.
I don't think I mentioned the encoder seems to pick up less noise at high speeds. At max speed (using the little servo tester you gave me) the speed reads just about 400 transitions per second (which should be 100 rpm (two black stripes on the gear)). At full speed, the two reading techniques agree with each other.
BTW, Sharpies don't absorb enough IR to work on brass. Even with a piece of tape over the Sharpie ink and another layer of ink on top of the tape, it still didn't absorb the IR. I'm using a couple of pieces of Gorilla tape for my stripes. I'll probably need to find a different solution when I put the gearbox back together. The Gorilla tape may be too thick to let everything spin like it's supposed to.
IIRC Gorilla tape is like glossy duct tape. Flat/matte black masking tape (art supply) may work better. Or, use any tape to mask off shiny brass areas and spray with Krylon ultra flat black, my fave.
IIRC Gorilla tape is like glossy duct tape. Flat/matte black masking tape (art supply) may work better.
Don't you think I know that!?! Grumble, grumble.
So Mr. KnowItAll, it turns out it was the Gorilla tape. The Gorilla tape had a couple of bright spots which were causing quick blips which the counters picked up.
I dug out my Parallax USB o'scope and this was what full speed showed.
This trace doesn't explain everything I was seeing previously but it't pretty clear it picking up some bright spots on the tape. You can see two relatively equal large up blips per cycle. This is the bare brass. There's one low section each cycle about the same size as the two large up blips which is the non-shiny tape. The other piece of tape apparently has a couple of shiny spots causing false positives.
I have some black masking tape I purchased from Parallax a while back. I'll try that to see if it works better. I used the Gorilla tape since there was a piece within arms reach while I was testing the encoder.
So I ask once again. Don't you ever get tired of being right?
I hope not, since you keep getting me out trouble with your rightness.
Just to be safe, maybe you should paint your barrel-shaped tread rollers flat black...
Don't worry, everyone hates erco. At work, we have an expensive high speed camera which makes amazing super slow motion videos. Stops bullets in flight, balloons bursting, etc. Requires super bright lights and lot of instruction to operate. A PITA to set up IMO, I never use it. Yet most other people love to use it to attempt to troubleshoot toys & tracksets, cars crashing & doing weird things. Usually they fail either in observing, diagnosing, or remedying the problem correctly. I let them try for a while before I stroll up, look at the item (not the video), and offer a quick fix that works about 95% of the time.
Thirty years of experience comes in handy sometimes.
In a related story, I never use an oscilloscope. I have a fine Parallax USB scope I won here somehow, but I really haven't needed it.
Yet. But I do work the Smile out of my many free HF multimeters!
It turns out the Gorilla tape was only causing a small part of the problem.
Here's a picture of the encoder mounted inside the servo with the gear by its side.
I found my black masking tape from Parallax and the oscilloscope showed nice clean high and low pulses coming from the encoders. I still had severe disagreements between the counts from the Spin loop (which were accurate) and the counts generated by the Propeller's counters (which could be very inaccurate).
I wondered if there were some high speed blips the Spin loop wasn't catching that the counters were but the o'scope traces were nice and clean even at 50us per division (the highest res setting).
I still don't know what the counters were counting but by switching the encoder power from the same power supply as used by the servo to the USB power shared with the QuickStart, the noise problem completely went away.
Since I had the counters working correctly (as long as the power to the encoder was clean), I decided to add one more technique, of reading encoders using the Propeller, to the code.
I added the following PASM code to monitor the encoder.
DAT org
pasmCode rdlong encoderCountCog, par
' encoderCountCog now holds the pin used by the encoder
mov encoderMask, #1
shl encoderMask, encoderCountCog
mov encoderCountCog, #0
wrlong encoderCountCog, par
mov oldScan, ina
and oldScan, encoderMask
'-------------------------------------------------------------------------------
readPin mov newScan, ina
and newScan, encoderMask
cmp newScan, oldScan wz
if_nz call #addBlip
jmp #readPin
'-------------------------------------------------------------------------------
addBlip mov oldScan, newScan
add encoderCountCog, #1
wrlong encoderCountCog, par
addBlip_ret ret
'-------------------------------------------------------------------------------
encoderMask res 1
encoderCountCog res 1
oldScan res 1
newScan res 1
fit
I'm pretty sure the PASM loop takes less than a microsecond so I'd think it would pick up some of the noise the counters are catching but the PASM agrees with the Spin loop even with a noisy power supply on the encoder.
It seems very strange that the counters would pick up noise the PASM loop completely misses.
If there is some mysterious noise, maybe try a small cap across the sensor output to filter it. What's the Propeller's high/low switching threshold (IOW what voltage is sensed high vs which is low, as in 1.4V for the Stamp)?
If there is some mysterious noise, maybe try a small cap across the sensor output to filter it.
I tried a 0.1uF cap on the output. It didn't help.
I'm pretty sure the logic threshold for the Prop is 1.65V.
I posted a question about this in the Prop forum. Tracy Allen had theory about what was happening.
As I mentioned above, if I use the USB power from the QuickStart board to power the encoder instead of the servo's power supply the noise goes away. I haven't added the filtering caps to the motor yet. Now that I have a better idea of what's going on, I'll try the filter caps on the motor to see if they make a difference.
Score! I informed Tim at Junun robotics about these sensors on Ebay and he restocked. He's now selling them for $1.50 each, lower than ever! http://www.junun.org/MarkIII/Info.jsp?item=48
Score! I informed Tim at Junun robotics about these sensors on Ebay and he restocked. He's now selling them for $1.50 each, lower than ever! http://www.junun.org/MarkIII/Info.jsp?item=48
Good call, Pub. I need to corner the S6986 market then create incredible demand for it so I can sell them for extremely high margins and fill the twins' college fund.
Was it Larry/lardom who was struggling recently to make DIY encoders?
Dang. I need to get mine out of the shipping tube!
Been so busy getting the Quadrover, Quadcopter, Penguins, Toddlers, BOEbots, and blue Scribbler ready for the Boston EXPO. (S2 is still apart as I was prepping it for chrome paint).
I will be demonstrating the most excellent S6986 Laser Sensor. You have some to sell? College unemployment fund.
The special black primer spray can decided to break it's valve when I took the top off. Picture a guy running wildly through the basement with his hand and shirt over the can to make it outside where it continued to spew for 5 minutes. What a mess.
I wanted to impress erco.. I'll put it back together a Photoshop it, he'll never know.
Comments
I had no problem with an inkjet striped wheel (I did use the highest quality setting) - see the video http://forums.parallax.com/showthread.php/149740-Rare-Wheel-Encoder-Sensors-Available-Strike-Now!?p=1203122&viewfull=1#post1203122
I also used a 10k pullup rather than the 6.8k in erco's schematic. I didn't notice that the orientation made any difference but that probabl;y depends on how wide the stripes are...
Oops, sorry about that ocer.
Yeah, I figure I'll go with parallel dots and stripes to begin with.
The disks will be pretty small so it won't take very long to darken the stripes (if needed) with a Sharpie. I did this with my Roboni-I encoders.
I think I had to use aluminum foil on white gear in order to get the IR to reflect. The white plastic was transparent to IR and didn't reflect it on its own.
Once I added the foil, I blackened in some stripes. It was kind of odd not to have the IR reflect back at all from a nice white surface. (The stripes are on the other side of the gear. This was the only photo that was easy to find of it.)
Good to know Ron. I'll try the inkjet stripes before darkening them with a Sharpie. I say you video earlier. Very cool.
I'm not sure what it is, but there's just something cool about being able to read stripes on a wheel like you did in your video. I think part of the appeal is the sensor is reading the reading the stripes faster than one would think is possible. Those stripes are just sailing past in a blur and yet the encoders don't have a problem detecting them.
Also good to know. I have lots of 10k resistors handy.
Looking at the schematic erco posted in post #1, it looks like pin 3 pulls the output low.
Do any of you know if pin 3 drives the line high? If it is an open drain output, then I shouldn't need an additional current limiting resistor on between the output and the Prop I/O pin. If it's not open drain, then I will need a current limiting resistor but then the pull-up resistor doesn't make sense.
I'm going to assume it's an open drain output unless told otherwise.
The 6.8k is between 5V and pin3 - so it is pulling it high.
Right, the resistor pulls it high, pin 3 pulls it low (when it's signalling a pulse). I suppose it's possible for pin 3 to be driven both high and low, but then why add a pull-up?
I could find a datasheet to be sure, but I'm betting the schematic as posted is Prop pin safe.
Sorry Duane, I read it wrong - thought you were saying that the resistor was a pulldown - I get your scenario/concern with the Prop now.
If I connect the output to ground I measure 740uA which is more than a Prop pin can safely handle. But when I measure the current to through a Prop input pin, it's only 170uA. The cutoff limit for a Prop pin is 500uA. So I'm pretty sure (again) these sensors are Prop safe.
Here's a picture of one of the sensors ready to be mounted inside a servo.
I used 1/8 watt resistors and a 0603 smt 0.1uF cap on the bottom of the piece of board.
Martin_H says he's also using one soon, and Ron Czap was the first guy in the pool! Mike Cook bought 50, and midrobots got 20, so I'm expecting big things from this forward deployment.
Repeating, if we Forumistas ever decide to team up on a collaborative project, applying our respective strengths, the world is our oyster. There is NOTHING this team could not accomplish!
http://www.junun.org/MarkIII/Info.jsp?item=48
And while we talkin' 'bout six-packs:
I'm getting a lot of noise on the encoder line when the servo is turned on.
I'm using two different techniques to monitor the encoders with the Propeller. One is to use the "ina" statement.
PUB EncoderLoop'' count pin transitions. oldState := 2 ' impossible state so currentState won't match on the first loop repeat currentState := ina[ENCODER_PIN] if currentState <> oldState oldState := currentState encoderCount++This isn't as supseptible to noise as the technique using counters.
Here's the method to display the data.
PUB DisplayCounts '' Must be called from cog where counters were setup. Debug.Position(0, DATA_LOC_Y) Debug.str(string("encoderCount = ")) Debug.Dec(encoderCount) Debug.str(string(13, "phsa + phsb = ")) Debug.Dec(phsa + phsb) Debug.ClearEnd Debug.str(string(13, " phsa = ")) Debug.Dec(phsa) Debug.ClearEnd Debug.str(string(13, " phsb = ")) Debug.Dec(phsb) Debug.ClearEnd Debug.str(string(13, "ledDisplayMode = ")) Debug.str(ModeToStr) Debug.ClearEndWith the servo off, I can manually spin the gear and the two different techniques agree.
Here's some sample output.
fileName = QsEncoderDemo130904e Enter number to indicate which mode to use. 4) LEDs display binary count of counter b. 3) LEDs display binary count of counter a. 2) LEDs display binary count of both counters 1) LEDs display binary count of ina changes 0) LED display encoder pin state (on or off) Enter "z" to zero encoder count. encoderCount = 1914 phsa + phsb = 1914 phsa = 957 phsb = 957 ledDisplayMode = BINARY_COUNT_INA_MODE localSpeedIna = 51 localSpeedCtr = 51The above output was with me hand turning the gear. As you can see the two techniques used to read the encoder are in agreement.
This next output is with the motor powered and turning relatively slow.
fileName = QsEncoderDemo130904e Enter number to indicate which mode to use. 4) LEDs display binary count of counter b. 3) LEDs display binary count of counter a. 2) LEDs display binary count of both counters 1) LEDs display binary count of ina changes 0) LED display encoder pin state (on or off) Enter "z" to zero encoder count. encoderCount = 2135 phsa + phsb = 8365 phsa = 4182 phsb = 4183 ledDisplayMode = BINARY_COUNT_INA_MODE localSpeedIna = 75 localSpeedCtr = 1121With the motor on, the counters must be picking up some noise because they the start counting very quickly when the gear is moving slowly.
I tried adding a Schmitt trigger to see if it would help. The Schmitt trigger made it so the "ina" technique also picked up the noise (not as much as the counters though).
So far, my idea of having an encoder inside a servo isn't working out well (again).
Any thoughts on how to reduce the noise from the servo motor?
In case anyone is interested, I've attached the spin file to this post.
Edit: See post #77 for most recent version of code.
Delta filter (3 caps) on the motor?
Yep.
Nope. I should have thought of that. Thanks.
There should be room to fit a few caps in with the motor. I'll give it a try.
I don't think I mentioned the encoder seems to pick up less noise at high speeds. At max speed (using the little servo tester you gave me) the speed reads just about 400 transitions per second (which should be 100 rpm (two black stripes on the gear)). At full speed, the two reading techniques agree with each other.
BTW, Sharpies don't absorb enough IR to work on brass. Even with a piece of tape over the Sharpie ink and another layer of ink on top of the tape, it still didn't absorb the IR. I'm using a couple of pieces of Gorilla tape for my stripes. I'll probably need to find a different solution when I put the gearbox back together. The Gorilla tape may be too thick to let everything spin like it's supposed to.
Don't you think I know that!?! Grumble, grumble.
So Mr. KnowItAll, it turns out it was the Gorilla tape. The Gorilla tape had a couple of bright spots which were causing quick blips which the counters picked up.
I dug out my Parallax USB o'scope and this was what full speed showed.
This trace doesn't explain everything I was seeing previously but it't pretty clear it picking up some bright spots on the tape. You can see two relatively equal large up blips per cycle. This is the bare brass. There's one low section each cycle about the same size as the two large up blips which is the non-shiny tape. The other piece of tape apparently has a couple of shiny spots causing false positives.
I have some black masking tape I purchased from Parallax a while back. I'll try that to see if it works better. I used the Gorilla tape since there was a piece within arms reach while I was testing the encoder.
So I ask once again. Don't you ever get tired of being right?
I hope not, since you keep getting me out trouble with your rightness.
Don't worry, everyone hates erco. At work, we have an expensive high speed camera which makes amazing super slow motion videos. Stops bullets in flight, balloons bursting, etc. Requires super bright lights and lot of instruction to operate. A PITA to set up IMO, I never use it. Yet most other people love to use it to attempt to troubleshoot toys & tracksets, cars crashing & doing weird things. Usually they fail either in observing, diagnosing, or remedying the problem correctly. I let them try for a while before I stroll up, look at the item (not the video), and offer a quick fix that works about 95% of the time.
Thirty years of experience comes in handy sometimes.
In a related story, I never use an oscilloscope. I have a fine Parallax USB scope I won here somehow, but I really haven't needed it.
Yet. But I do work the Smile out of my many free HF multimeters!
Here's a picture of the encoder mounted inside the servo with the gear by its side.
I found my black masking tape from Parallax and the oscilloscope showed nice clean high and low pulses coming from the encoders. I still had severe disagreements between the counts from the Spin loop (which were accurate) and the counts generated by the Propeller's counters (which could be very inaccurate).
I wondered if there were some high speed blips the Spin loop wasn't catching that the counters were but the o'scope traces were nice and clean even at 50us per division (the highest res setting).
I still don't know what the counters were counting but by switching the encoder power from the same power supply as used by the servo to the USB power shared with the QuickStart, the noise problem completely went away.
Since I had the counters working correctly (as long as the power to the encoder was clean), I decided to add one more technique, of reading encoders using the Propeller, to the code.
I added the following PASM code to monitor the encoder.
DAT org pasmCode rdlong encoderCountCog, par ' encoderCountCog now holds the pin used by the encoder mov encoderMask, #1 shl encoderMask, encoderCountCog mov encoderCountCog, #0 wrlong encoderCountCog, par mov oldScan, ina and oldScan, encoderMask '------------------------------------------------------------------------------- readPin mov newScan, ina and newScan, encoderMask cmp newScan, oldScan wz if_nz call #addBlip jmp #readPin '------------------------------------------------------------------------------- addBlip mov oldScan, newScan add encoderCountCog, #1 wrlong encoderCountCog, par addBlip_ret ret '------------------------------------------------------------------------------- encoderMask res 1 encoderCountCog res 1 oldScan res 1 newScan res 1 fitI'm pretty sure the PASM loop takes less than a microsecond so I'd think it would pick up some of the noise the counters are catching but the PASM agrees with the Spin loop even with a noisy power supply on the encoder.
It seems very strange that the counters would pick up noise the PASM loop completely misses.
I tried a 0.1uF cap on the output. It didn't help.
I'm pretty sure the logic threshold for the Prop is 1.65V.
I posted a question about this in the Prop forum. Tracy Allen had theory about what was happening.
As I mentioned above, if I use the USB power from the QuickStart board to power the encoder instead of the servo's power supply the noise goes away. I haven't added the filtering caps to the motor yet. Now that I have a better idea of what's going on, I'll try the filter caps on the motor to see if they make a difference.
This was good karma and a win/win for everyone, as he was out of stock for several years.. See my previous post about Tim giving me his last few samples: http://forums.parallax.com/showthread.php/142284-Junun-Robotics?highlight=junun+robotics
But he didn't restock on the S6986
You need to sell him a bunch to fund the school fund.
(What am I talking about? Sell him a few at extremely high margins. Save the rest for us)
Was it Larry/lardom who was struggling recently to make DIY encoders?
Ouch!
Those are great encoder sensors but that price seems kind of high.
Dang. I need to get mine out of the shipping tube!
Been so busy getting the Quadrover, Quadcopter, Penguins, Toddlers, BOEbots, and blue Scribbler ready for the Boston EXPO. (S2 is still apart as I was prepping it for chrome paint).
I will be demonstrating the most excellent S6986 Laser Sensor. You have some to sell? College unemployment fund.
So both you and Martin_H were workin' that sensor at the Boston Expo? Whuja do?
I just had a static display with my Activity Bot with the laser and sensor showing the >10' range.
I gave Martin my NAPA reflective tape and he used it for his Claw Bot demo with great range and repeatably. He swears he's going to to another video.
Thanks, Anna.
I got that FROZEN reference.
Prince Hans of the Southern Isles.
Yup. Untill..........
The special black primer spray can decided to break it's valve when I took the top off. Picture a guy running wildly through the basement with his hand and shirt over the can to make it outside where it continued to spew for 5 minutes. What a mess.
I wanted to impress erco.. I'll put it back together a Photoshop it, he'll never know.
http://www.alsacorp.com/products/killercans/kc/killerchrome.htm