| |
You can use four touch sensors per input port on the RCX.
The Cybermaster touch sensors have resistors in parallel, and this is how the
Cybermaster knows which implement is attached to the tracked robot.
It uses its sensor input as a temperature sensor reader in order to read the
resistance value on the input, which is different for each switch.
If you use the same method on the RCX (after enabling the temperature sensor in
the advanced control page) you can use four touch sensors like this:
Put resistors of 82k, 56k, 47k and 39k in series with the four switches.
Cut in half some short 9Volt leads and put 12Volt plugs on them. Then use choc
block (barrier strip) for the resistor assembly, with 1/0.6 bell wire protruding
- shove these wires into the middle of the 12V plug pins. One wire goes to the
RCX port and one to each switch.
Alternatively use Veroboard for a tidier solution, but I haven't got round to it
yet.
You can determine which of the four (and every combination of 2, 3 or 4 of them)
has been triggered by testing for temperature sensor values. This is great for
robots with multiple bumpers.
I picked the resistor values to make all combinations line up on the linear part
of the value vs resistance graph (the linear region is in the middle).
Of course you can also put a light sensor in parallel as is done on the soccer
robots. So now you have 15 sensors on your RCX!!
Happy sensing!
Mark Bellis
|
|
| |
In lugnet.robotics.rcx, Mark Bellis wrote:
> You can use four touch sensors per input port on the RCX.
>
> The Cybermaster touch sensors have resistors in parallel, and this is how the
> Cybermaster knows which implement is attached to the tracked robot.
>
> It uses its sensor input as a temperature sensor reader in order to read the
> resistance value on the input, which is different for each switch.
>
> If you use the same method on the RCX (after enabling the temperature sensor in
> the advanced control page) you can use four touch sensors like this:
> Put resistors of 82k, 56k, 47k and 39k in series with the four switches.
>
> Cut in half some short 9Volt leads and put 12Volt plugs on them. Then use choc
> block (barrier strip) for the resistor assembly, with 1/0.6 bell wire protruding
> - shove these wires into the middle of the 12V plug pins. One wire goes to the
> RCX port and one to each switch.
>
> Alternatively use Veroboard for a tidier solution, but I haven't got round to it
> yet.
>
> You can determine which of the four (and every combination of 2, 3 or 4 of them)
> has been triggered by testing for temperature sensor values. This is great for
> robots with multiple bumpers.
>
> I picked the resistor values to make all combinations line up on the linear part
> of the value vs resistance graph (the linear region is in the middle).
>
> Of course you can also put a light sensor in parallel as is done on the soccer
> robots. So now you have 15 sensors on your RCX!!
>
> Happy sensing!
>
> Mark Bellis
LEGO purists use LEGO light bricks as resistors.
I created potentiometer bricks, where the resistance is variable for each brick.
Two stacks of 4 potentiometer bricks can be seen to the left of the RCX. In
this case each stack puts the switches and resistors in series. To the left of
the potentiometer brick stack is a 16 key keyboard that has for row touch
sensors and four column touch sensors. The keyboard requires to RCX input
ports.
The potentiometers in the potentiometer bricks are the rectangular green boxes
hanging off the sides of the resistor stack. The potentiometers are 10 turn,
10K ohms, so you get a *lot* of resistance control.
The potentiometer brick is a sandwich of 2x2 electrical plates on the top and
bottom, with a regular 2x2 plate in between. The potentiometer leads are
connected to the top and bottom electrical plates.
The potentiometer bricks can be used to create series, parallel or series
parallel circuits. In my experience series gives you better resolution in the
analog input range of the RCX.
I'll have to check, but I'm pretty sure that I do not put the sensor ports into
temperature mode. Instead I used raw touch sensor readings which gives you a
range of values from 0 to 1023, giving us the maximum sensor reading resolution.
Kevin
|
|
| |
In lugnet.robotics.rcx, Mark Bellis wrote:
> You can use four touch sensors per input port on the RCX.
While in theory, this sounds very cool, in pratice, I doubt it will work quite
that well.
The biggest problem will be that the standard touch sensors may not be 100% on
when you press it. This means the sensor itself can provide some resistance,
depending on how hard you press it.
You can test this by hooking up a touch sensor (configured to display raw
values) and softly press it. You'll notice, the harder you press it (to a
point) the more the number changes. (I forget if they go up or down, using the
standard software/firmware). Then, as you release the button (VERY slowly) you
see the numbers change, again.
So, the sensors won't give you a solid on/off reading. I believe the reading
can easily vary 5 or 10 percent.
That means, if you have 4 touch sensors, there are 16 possible combinations, so
each can vary by at most 6.25% (100%/16readings=6.25%) or there is 6% between 1
and 2 or 2 and 3
So, given that each sensor could vary as little as 5%, then at BEST you have
1.25% difference. At worst, the reading differ by -20% (readings overlap 20%)
It doesn't exactly come out like that, but let's just say it won't work very
well.
> Of course you can also put a light sensor in parallel as is done on the soccer
> robots. So now you have 15 sensors on your RCX!!
This, doesn't even work in theory.
While it IS possible to connect a single touch sensor and a single light sensor
to the same port, you can not use a touch sensor multiplexor with a light
sensor.
I can go into detail, but let's just say if your reading is ~50%, does that mean
the light sensor is on gray, OR are you pressing half the touch sensors?
There's no way to tell.
Nice idea, but it won't quite work.
Steve
|
|
| |
In lugnet.robotics.rcx, Steve Hassenplug wrote:
> In lugnet.robotics.rcx, Mark Bellis wrote:
> > You can use four touch sensors per input port on the RCX.
>
> While in theory, this sounds very cool, in pratice, I doubt it will work quite
> that well.
>
> The biggest problem will be that the standard touch sensors may not be 100% on
> when you press it. This means the sensor itself can provide some resistance,
> depending on how hard you press it.
>
> You can test this by hooking up a touch sensor (configured to display raw
> values) and softly press it. You'll notice, the harder you press it (to a
> point) the more the number changes. (I forget if they go up or down, using the
> standard software/firmware). Then, as you release the button (VERY slowly) you
> see the numbers change, again.
>
> So, the sensors won't give you a solid on/off reading. I believe the reading
> can easily vary 5 or 10 percent.
>
> That means, if you have 4 touch sensors, there are 16 possible combinations, so
> each can vary by at most 6.25% (100%/16readings=6.25%) or there is 6% between 1
> and 2 or 2 and 3
>
> So, given that each sensor could vary as little as 5%, then at BEST you have
> 1.25% difference. At worst, the reading differ by -20% (readings overlap 20%)
>
> It doesn't exactly come out like that, but let's just say it won't work very
> well.
Good analysis.
Series can work quite well as long as you know that the touch sensors are
touched mutually exclusively, but you are right parallel doesn't work well. I
remember trying to come up with good resistance values to do parallel, and
didn't have much luck.
You might be able to do it with two touch sensors, right? Two sensors can have
four possible combinations, so you get 25% per combination. This is higher than
the 20% worst case, so it might work.
With three touch sensors, you get 8 combinations, at 12.5% per combination. I
don't think that would work worst case.
Kevin
|
|
| |
I have done work in this area.
I chose to solve the problem to permit 4 touch sensors to be pressed in any
arbitrary combination with high probability of getting the answer right :)
A simple R, 2R, 4R, 8R scheme will do.
I chose R = 40.2K. This is high enough that the contact resistance in the
sensors is negligable.
I used 40.2K, 80.6K, 160K and 320K. These resistors all have to be 1%.
First of all, note that 40k is eight 320Ks in parallel. 80K is four, and 160K is
two. Since the RCX's pullup resistor is 10K, you can easily compute the
resistance of the "load" (resistance of none - all of the switch es closed) by
processing the reading (0 - 1023 in passive raw mode).
The load resistance can then be converted to a "number of 320K resistors in
parallel" which must yield a number on the range 0 - 15. This number when
expressed as a binary value 0000 - 1111 then actually respresents which switches
are open and which closed.
The key routine is the conversion from raw reading (0 - 1023) to number of
320Ks. My approach was to round up by "half a unit value", ie; the effect of a
single 320K resistor before doing the final integer division which produces the
0 - 15 "answer".
I would suggest anyone trying to repeat this should take a close look at ohms
law - its pretty simple. To optimise the final quantization, a quick look at a
famous work done centuries ago - Newton's Kissing Sphere's would help. (This
theory is often used in defining signal encoding separation in modems.) The
advantage it has in this application is in only needs to be applied in one
dimension, as opposed to the modem applications which may require 4 or more
dimensions.
We actually sold these simple multiplexors back when but since we had largish
quantities of the four resistor values required, a laborious process of creating
calibrated sets was put in place to get the value matching to better than 0.3%
to increase the liklehood that the processing would guarantee the correct
answer.
JB
|
|
| |
In lugnet.robotics.rcx, Steve Hassenplug wrote:
>
> While in theory, this sounds very cool, in pratice, I doubt it
> will work quite that well.
It works very well for me, with the variation that I use home-made
touch sensors that are actually microswitches embedded into 2x2
blocks. That does mean you might need to debounce in software, but
normally I don't bother since the inertia of the mechanicals is such
that a bit of contact bounce doesn't matter.
Everything uses the normal lego wires with 2x2 connectors on teh end.
The multiplexer is a 10x2 piece 2 plates thick, with teh resistors
embedded within it. This means that with the wires attached it's four
plates thick, and therefore neatly fits within the 'standard' 5 plate
vertical grid. I actually used a network of eight resistors in there
to get teh ratios closer to teh ideal 1:2:4:8.
Although it's homebrew, it _looks_ purist in every respect except teh
contact point of the touch sensors, which are obviously microswitches.
Built into something, all parts look like they could be genuine. I
could post photos somewhere if they would be of interest to anyone -
I'm very pleased with the compactness of teh multiplexer.
I have pbforth code that unmultiplexes teh contacts, but tend not to
program in anything else. Shouldn't be hard in anything else
though. Works a treat every time I've used it.
regards, Ian SMith
|
|
| |
> Although it's homebrew, it _looks_ purist in every respect except teh
> contact point of the touch sensors, which are obviously microswitches.
> Built into something, all parts look like they could be genuine. I
> could post photos somewhere if they would be of interest to anyone -
> I'm very pleased with the compactness of teh multiplexer.
>
> I have pbforth code that unmultiplexes teh contacts, but tend not to
> program in anything else. Shouldn't be hard in anything else
> though. Works a treat every time I've used it.
Ian,
Great to see that you are having success with pbForth! I have
a couple of questoins:
1. Which version are you using?
2. Are there any features you REALLY wish were available?
3. Do you have any stories or code to share?
Ralph
--------------------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbForth>
Buy "Extreme Mindstorms: an Advanced Guide to Lego Mindstorms"
<http://www.amazon.com/exec/obidos/ASIN/1893115844/hempeldesigngrou>
--------------------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------------------
|
|
| |
> But as a purist you can use the cybermaster sensors to multiplex three
> inputs (http://www.loria.fr/~stuber/lego/cybermaster-touchsensors.html).
Hi Jürgen,
I have tried this method too, and as you say in your text, it is plagued by the
rubber contacts whose value goes down as more pressure is applied to the switch.
I measured resistance of several touch sensors while applying a very progressive
pressure, using a two stages worm screw down gearing driving a threaded axle
pushing sensor button. At the very beginning of contact, resistance is as high
as 10000 ohms, then go down very rapidly and reach an asymptote at about 500
ohms (exact value varies between touch sensors).
I'll post soon the results.
As the difference between switches resistances is only 2000 ohms, false readings
will happen (and I even doubt that double reading will cure the problem in
several mechanical designs).
But using only yellow and white sensors with 5k difference should be almost safe
- better than nothing !
Philo
www.philohome.com
|
|
| |
"Steve Hassenplug" <Hassenplug@mail.com> wrote:
[snip]
> The biggest problem will be that the standard touch sensors may not be 100% on
> when you press it. This means the sensor itself can provide some resistance,
> depending on how hard you press it.
>
> You can test this by hooking up a touch sensor (configured to display raw
> values) and softly press it. You'll notice, the harder you press it (to a
> point) the more the number changes. (I forget if they go up or down, using the
> standard software/firmware). Then, as you release the button (VERY slowly) you
> see the numbers change, again.
This has always annoyed me about the Lego touch sensors. Has anyone
ever made or seen a contraption that uses the variable pressure
sensitivity of the Lego touch sensors?
Tim
|
|
| |
Here is a chart showing the variation of contact resistance of several touch
sensors while pressing button very progressively.
- There are huge differences between various sensor
- Lightly pressed touch sensors have contact resistance in the 2 to 5 KOhms range.
- Fully depressed resistance varies (for the samples I measured) between 400 and 560 Ohms
Photographs of the test contraption:
Top view
Touch sensor
close-up
Philo
|
|
| |
Tim Auton wrote:
> This has always annoyed me about the Lego touch sensors. Has anyone
> ever made or seen a contraption that uses the variable pressure
> sensitivity of the Lego touch sensors?
>
>
> Tim
I've made one. A wall follower. I set the sensor to raw mode and looked at three
ranges. It tried to stay in the middle range, which for this 'bot meant lightly
touching the wall. The wall follower had a bumper analogous to a highly curved
(180 degrees) insect feeler. The touch sensor was oriented vertically and the end
of the feeler nearest the 'bot moved horizontally over the bump on the sensor. I
think I used a technic #3 angle connector ( http://www.peeron.com/inv/parts/32016
), with the pin hole as the pivot point of the feeler and the side of one of the
ends moving over the bump of the sensor.
IIRC, the ranges I used were around 0-200, 201-900, 900-1023. The sensor's values
tended to hover around 0 at no contact, 950+ at high contact, and 350-500 for
light contact.
-Brian
|
|
| |
On Wed, 10 Sep 2003 22:56:24 GMT, Ralph Hempel <rhempel@bmts.com> wrote:
> > I have pbforth code that unmultiplexes teh contacts, but tend not to
> > program in anything else. Shouldn't be hard in anything else
> > though. Works a treat every time I've used it.
(apologies for delay - my server decided to stop talking to lugnet for
some reason, hopefully now fixed)
> Great to see that you are having success with pbForth! I have
> a couple of questoins:
>
> 1. Which version are you using?
Errm, probably 2.1.0 (but I don't have it immediately to hand at the
moment - that's the name of the directory on my computer with teh srec
file of teh firmware I use, however).
> 2. Are there any features you REALLY wish were available?
I did think I'd like something on getting 2 RCXs to talk to each
other, and a few more example scripts, but a peruse of your web site
reveals that these have been addressed even before I asked for them!
> 3. Do you have any stories or code to share?
Not really. The reason I use pbforth is because I'm no good at it!
I earn some of my money programming in (order of favour) perl, C,
visual basic (spit), and have dabbled (also for money) in postscript,
tcl/tk and nearly language things like sed and awk and so on.
On the RCX, I didn't want to use anything I was familiar with (much
rather learn something new - where's teh fun in doing something you
know how to do?), and in my distant past I nearly bought a home
computer which spoke forth (though I can't remember what it was - 80s
sometime). Hence, pbForth seemed ideal.
My learning materials have been a printout of powerpoint 'introduction
to pbforth' which is 31 slides copyright you 1999, a file
'rcxWordlist.html' that I seem to have downloaded in Feb 2002, and a
copy of ANSI X3.215-1994. As such, my code is probably not something
which ought to be inflicted on teh world at large (though it works).
I also tend to dismantle everything I build and lose everything I code
as soon as it's working - I have to document, QA, save, store,
evaluate, optimise, develop etc at work and for fun I'd rather hack it
operational and then start on a new challenge!
My current project is a two RCX, three drive holonomic platform (a
killough) with a 'commander' RCX and an 'engine room' RCX. The idea
is that the commander says something like "drive 1 stationary, drive 2
reverse to rotation x, drive 3 advance to rotation y", and teh engine
room does the motors while monitoring the rotation sensors.
Meanwhile the commander is monitoring some other sensors (probably via
the multiplexer) and might at any moment instruct "all stop" while it
does something else. At present rate of progress, you can look
forward to this sometime in 2007.
So, I'm probably not a great advocate or example of pbforth use.
I'm really glad you wrote it, however
regards, Ian SMith
--
|\ /| no .sig
|o o|
|/ \|
|
|
|
