DIY multi-touch

Let's build a low cost open source capacitive multi-touch sensor matrix! Current prototypes can be seen here: youtube playlist.

UPDATE: This forum is closed. For further updates please visit www.wiretouch.net.

Equipment

Werde heute einige Dinge bestellen. Die Liste ist noch offen und befindet sich in der Dropbox. Oszilloskop und Signalgenerator sprengen allerdings das Projektbudget. Die sollten an sich an der TU in Massen herumliegen, zB. ums Eck in der Floragasse. Es wird allerdings immer irgendeine Art der Mitgliedschaft verlangt. Hat hier jemand interfakultäre Kontakte?

Single-Supply Op Amp Squarewave Oscillator

Ich habe einmal einen LM358AN und TLV2372IP gestestet, beides single-supply Opamps - dazu unser neues Oszilloskop (das günstigste, das ich finden konnte).

Wenn ich den Widerstand von R1 verringere wird die Frequenz zwar höher, die Amplitude aber niedriger und die Squares verlieren schon bei 120kHz stark an Form. Einen niedrigeren Kondensator habe ich momentan leider nicht bei der Hand. Wenn ich allerdings den Kondensator mit unserem "Gimmick" tausche, komme ich auf ca. 97kHz und ein eigentlich recht sauberes Signal.

AttachmentSize
squarewave.jpg 69.46 KB

duh

Und das Gimmick lässt sich so natürlich auch als Sensor verwenden (Frequenz sinkt bei Annäherung).

50Hz

Mit Resonator und CMOS hab ich eine ordentliche Rechteckschwingung mit 453kHz (ca. 0-5V) hinbekommen. Einmal durchs Gimmick durch, ist das Signal noch vorhanden (mV Bereich) und die Amplitude verändert sich jetzt merklich bei Annäherung der Hand. Dank Gimmick stört jetzt allerdings auch eine 50Hz Welle…

Metaday

armin hat mir letztens erzählt, dass peter gerne beim kommenden metaday über die capacitative touch sparte präsentieren will, um leute aufzureißen. ich halte das allerdings zu diesem zeitpunkt für einen taktisch bzw. auch strategisch recht unguten zug nach meinen bisherigen erfahrungen mit dem metalab, und hier ist warum:

1) generell ist es für open-source projekte ganz schlecht, volunteers zu suchen, bevor schon was funktionierendes da ist: die motten fliegen zum erfolg, nicht zu den challenges. aus genau diesem grund warte ich auch immer selbst, bis eins meiner projekte "fertig" ist, bevor ich es poste/twittere/etc. open-source funktioniert als kreislauf von lernen und beitragen, d.h. wenn noch nichts da ist, durch das ich die materie des projekts erlernen kann, gibt es auch wenig anknüpfungspunkte, bei denen ich beitragen kann. bestes beispiel: GNU hurd vs. Linux – guess which one already worked when it was announced.

2) das metalab ist sehr bunt gemischt. insbesondere traue ich dort genau 4 leuten zu, sinnvolle contributions machen zu können, also rein aufgrund ihrer fähigkeiten. genau die sind bei den metadays aber so gut wie nie dabei, sondern sitzen hinten im lab und basteln. umgekehrt kämen aber sofort ganz ganz viele grenztriviale hillfsvorschläge von den unbewusst weniger qualifizierten anwesenden, a la "habt ihr schon decoupling caps probiert?". zu den 4 guten leuten hab ich einen guten draht, d.h. wenn einmal was da ist, frag ich sie lieber direkt, als uns am metaday der masse zu exponieren – wobei ich da auch keine großen hoffnungen habe, die leute sind busy und selbst für ihre eigenen interessen schwer zu begeistern: ich versuch seit monaten, RepRap-mäßig was auf die beine zu stellen, aber klappt nicht – derweil ist noch nicht einmal ihr eigener mendel fertig.

3) das metalab mag kurze, einfache, eindrucksvolle projekte, keine aufwändigen mühsamen mit wenigen fanfaren: wenn wir wen brauchen, der uns eine pong-demo mit unserer surface programmiert, perfekt, aber für die grundlagen werden wir nur leute anziehen, die sich profilieren wollen.

4) die schwierigkeiten, die wir momentan haben, lassen sich auch nicht einfach lösen, indem wir wen von außen hinzuziehen: das prinzip haben wir schon verstanden, schwierig sind eher die limitation einzelner komponenten (z.b. die eingangskapazität unserer opamps) bzw. die tatsache, dass die smartskin-lösung auf dem exakten tuning ihrer komponenten basiert, die mehr experimentellen als rechnerischen charakter hat. und die 50Hz welle ist an sich beim momentanen stand relativ egal, da wir ohnehin einen integrator brauchen werden (schaut halt im oszilloskop nicht schön aus, ist aber aufgrund ihrer gleichförmigkeit ziemlich egal) – und ansonsten kämpfen wir bei 400KHz nicht gegen viele böse wellen, da kein funkstandard dort sein baseband hat. und trotzdem können wir das durch ordentliches shielding bzw. ordentliches ground-wiring sofort lösen – remember, im moment wohnt unser prototyp auf einem breadboard, das mit seinen vielen langen leitungen selbst nochmal eine dicke antenne ist! also vereinfacht: um aluminiumfolie um unser ding zu wickeln, brauchen wir echt keine hilfe.

5) das projekt hat aber auch gerade das potential, einige metalabber zu begeistern, *wenn* schon etwas funktioniert. jetzt schon das pulver zu verschießen heißt, eine riesen-chance weg zu schmeißen.

zusammengefasst: don't do it, not right now.

schätze das sehr ähnlich ein

Ich schätze das sehr ähnlich ein. Wenn wir das Projekt bei den lokalen Hackerspaces bewerben wollen, sollte eine gewisse Basisfunktionalität vorhanden sein. Was den Prozess momentan beschleunigen könnte, wären vielleicht ein paar Tipps erfahrener Spezialisten. Hier mal eine PhD Thesis, ganz frisch von der TU Delft: A Low-Cost Universal Integrated Interface for Capacitive Sensors.

Schaltplan

Nach dem Erfolgserlebnis letzten Donnerstag, hier eine Skizze des momentanen Aufbaus:

AttachmentSize
schaltung_3.jpg 49.55 KB

OpenMT

openmtproject, ArduMT1

"ArduMT2: Capacitive multi-touch (coming soon)"

Ähnliches Projekt, ähnlicher Arbeitsplatz… :)

AttachmentSize
ardumt_ceat.jpg 60.8 KB

collaboration

"I opened a new thread for a sort of loose collaboration." touch_ui Ich bin gespannt. Damit das funktioniert, sollten wir hier auf Englisch wechseln…

Hello from OpenMT

Hi all,

It's great to know a team also interested in capacitive multi-touch. Hope to have a good relationship between you and my OpenMT project.

hey there! really glad we

prototype: single crosspoint

Here's a short video of our current prototype.

We are sending a 450kHz square wave through a coated wire crosspoint. The weakened signal gets amplified by a high speed opamp. Afterwards it gets cleaned by a switch which is controlled by the original square wave. Finally an RC circuit (a fine tuned low pass filter) gives an arduino board some voltage to measure. The board sends the values to a small processing sketch which finally creates the (rather annoying) sine wave sound.

A sketch of the current circuit is shown above. The actual values of the components strongly depend of the original input signal and the wires used. We also added a few additional decoupling capacitors.

In the next step we will try to use a demultiplexer to send timed signals through different lines of a grid.

Great work!

Wow, it's excellent and suprising that your prototype shows such high sensitivity. You may make a 3D input device as well as multi-touch :)
3D input device: http://www.touchuserinterface.com/2011/02/amazing-nemopsys-3d-gesture-co...

By the way, I also implemented my own and tested it with scanning electronics attached. It works for a single point. But when scanning starts, it fails to sense. My sensor is based on MIT's electric field imaging method. Scanning electronics I used is a modified version of ArduMT1.

Since I'm preparing for the next release of OpenMT, this capacitive multi-touch project is a little delayed ...

thank you :)

We too experienced some problems with the multiplexer. It took us some time but I think we are making slow progress now. Here's a short video showing our new prototype. More comming soon (hopefully).

Multiplexers...

What MUX do you use? I've used 74HC4053 triple two channel MUX. I think my problem is due to analog sensig electronics. But you've already implemented a good capacitive sensing circuit, this MUX would be helpful.

prototype: two crosspoints

Here's a sketch of our current prototype. The whole circuit is heavily inspired by Jun Rekomito's Smartskin project. Unfortunately his paper doesn't give out much details about the actual implementation…

We are currently using two Arduino boards. One controls the multiplexer, a CD74HC4067 (on a breakout board).The second board takes the measurements.

I will post some images of the signals next so it becomes more obvious what's actually going on.

AttachmentSize
schaltung_4.jpg 131.33 KB

waves

So here they are. I'm not using the multiplexer here, so this is a single sensor again. Looking at the images I have the feeling… maybe the RC circuits need some readjustment. Hmmm.

AttachmentSize
waves.jpg 270.38 KB

Small suggestions

I'm not sure I fully understand the circuit. But let me show you my experience regarding multi-touch scanning (not capacitive sensing).

In my opinion, I think your current MUX is not suitable for multi-touch since it remains unselected electrodes floating. However, for multi-touch, it is important to ground unselected electrodes. This technique is often called zero potential scanning. I've used a set of 74HC4053 triple 2 channle MUX to implement the zero potential scanning circuit.

Good luck.

Phantom Touch

On a resitive touch surface conductance increases as external force is applied. Thus "rerouting" by pressing several crossingpoints becomes possible. At least these are the "phantom touches" described in Rosenberg's&Perlin's UnMousePad (figure 5).

In our setup the touch weakens the signal through mutual capacitance. Rerouting shouldn't be a problem. However, at the moment we are still experimenting with only two intersections. Grounding may become more and more of a topic when side-effects increase with the complexity of our little setup. I will keep that in mind!

We are currently completely reworking the circuit. A small demo is available here.

Great and

It's not easy to identify the panel structure with the video. Let me give my old setup:

1mm plastic cover sheet
upper electrodes
0.4mm plastic (acrylic) film
bottom electrodes
thick plastic

Good luck!

prototype: 48 crosspoints

Here's a video of our current prototype: http://www.youtube.com/watch?v=zU1H-CCVbu0
One single arduino board powers everything, controls the multiplexers, measures the voltage level and sends the data to the laptop.

row order bug

I'm touching the lower right corner of the matrix and I'm getting the following image (I marked the problematic areas). The image corresponds with the received string, so I don't think there's an error in the drawing or parsing routine. From my current point of view it's either an issue with the serial buffer or with the multiplexer.

AttachmentSize
arrayindexbug.jpg 121.38 KB

Georg's secret

Turns out, the value of the integration capacitor was too high thus making the measurements "laggy". It seems we fixed this now.

prototype: 176 crosspoints, 2xinterpolation

Last Thursday Georg and me upgraded our prototype to 176 crosspoints. Using linear interpolation we can already produce some nice low-res images. Here's a short video.

@OpenMT: Your package just arrived and the sensing area looks great! I will try to test it as soon as possible.

Great work

Hi, I saw the 176 cross points video. It's great! I hope the panel arrived to you also work with your prototype. I eager to see good results of your system with my panel :)

next steps

Some thoughts on next steps:

  • We still haven't figured out what causes the row order bug.
  • We do have line artefacts and they seem to appear every 2nd row. Last Friday we managed to compensate these errors by adjusting the signal amplification, but this feels a bit like a workaround for me. At least we do not know the cause yet and our solution might actually degrade the sensor's sensitivity.
  • I ordered two little FFC-Breadboard connectors so we can finally test our circuit with Wook's sensor panel. And we should try to increase the number of sensors of our own matrix.
AttachmentSize
artefacts.png 14.6 KB
catmull_rom_spine_x5.png 16.85 KB
georgsfoot.png 17.44 KB

0.5mm FFC Breadboard Adapter

I just received the package from Riga. The 40-pin version is currently out of stock. The parts are on its way to a soldering company, so I guess we have to wait a bit…

AttachmentSize
ffc_breadboard_adapter.jpg 162.67 KB

Taststudie

only tangentially related: touch experiment by David Katz, 1925

AttachmentSize
katz_taststudie.jpg 58.93 KB

prototype: 704 crosspoints

Todo:

  • decrease latency
  • fix 2 buggy rows
  • add capacitors
  • switch amplified signal
  • better debugging tools
  • fix contrast stretch
  • less noise
  • grounding

short video

Here's a new video showing the current prototype. We fixed some bugs and we decreased the latency by squeezing as much as possible through the limited arduino-macbook serial connection.

Grounding didn't improve the signal quality, but we are actually quite satisfied with the overall results. The noise on the upper right corner is caused by a few missing crosspoints (see attached image). We just ran out of cable while building the grid.

@OpenMT: We tried to connect our circuit with the Sensible UI grid you sent, but we didn't get any useable data yet. I guess the circuit has to get altered to get the correct field-effect. We will have to contemplate a bit about this…

AttachmentSize
ceat_multitouch_700crosspoints.jpg 157.43 KB
ceat_multitouch_700crosspoints_hand.jpg 38.46 KB

Processing CPU usage

I switched to GLGraphics which dropped the CPU usage back to sane levels (compare: issue 729). Rumors have it that Processing 2.0 will be released this fall and will include a new OpenGL implementation based on GLGraphics. P2D will be removed.

data transmission problems

concerning our new arduino-processing transmission issue: Georg's encoding and decoding algorithms are sound (I personally recalculated the binary numbers, no joke), but the buffer on the receiving side contains erroneous data. So far I came to the following insights:

Our little test program can not reproduce the same numbers on my Macbook (OS 10.7.3). Downgrading RXTX to 2.1-7 or upgrading Processing to the pre-alpha version didn't change that.

It actually produces the correct numbers when executed on a Linux box (white Intel Core 2 iMac, Ubuntu, Java 1.6.0_26-b03, Processing 1.5.1 and 1.2.1).

Maybe we can narrow it down a bit more…

lag / jitter

So we stopped using Processing's Serial.event(), we have our own buffer approach and our data seems to be transmitted correctly now. But there is still some sort of latency problem.

This is how my log looks like when using a 38400 baud rate (1 second, 60 fps, 5 "packets"):

...... DATA(217.0) ............ DATA(200.0) ............. DATA(216.0) ............. DATA(217.0) ............ DATA(200.0) ....

A point represents the invocation of the draw() method. The draw method also checks if there's anything coming from the serial connection. So if mySerialPort.available()>0 it writes DATA and records the milliseconds that have past since the last time.

And this is how it looks like using a higher baud rate (e.g.: 57600) (1 second, 60 fps, 5 or 9 "packets"):

..................... DATA(617.0) . DATA(17.0) . DATA(16.0) . DATA(17.0) . DATA(16.0) ....................................

Now the data arrives in short bursts. The over all performance is worse. Only 1 update per second can be perceived.

...

OK, this is still an OSX specific issue. I just tested the code on Ubuntu 11.10 running on the iMac and now I get even intervals and a smooth animation. (before I also had to sidestep some serious Ubuntu related performance problems by switching from Unity to Gnome Classic.)

prototype: ca. 700 crosspoints, blob detection

Here are two pictures from last Friday's session. A lot of stuff has been changed. The tracker now sends 14-15 updates per second and the blob detection already gives some promising results. A new video is available here.

AttachmentSize
ceat_multitouch_700crosspoints_finetuned.jpg 72.22 KB
ceat_multitouch_700crosspoints_finetuned_tracking.jpg 38.75 KB

pcb sensor matrix

Here's a picture of the new sensor matrix.

AttachmentSize
ceat_pcb.jpg 67.21 KB

historical remarks

I stumbled upon these three relevant papers by Bent Stumpe (et al). Fascinating.

Two devices for operator interaction in the central control of the new CERN accelerator, 1973
A new principle for an X-Y Touch Screen, 1977
Experiments to find a manufactoring process for an x-y touch screen, 1978

AttachmentSize
CERN-73-06.pdf 4.33 MB
StumpeMar77.pdf 1.1 MB
StumpeFeb78.pdf 735.39 KB

adjacent channel crosstalk?

The conclusion of our last session was that our multiplexer weakens our signal in the last few channels. We are using four multiplexers and the attached image should illustrate our problem quite well.

I also attached an article about multiplexer crosstalk in analog multiplexers.

AttachmentSize
ceat_mux_problem.png 30 KB
an_35_multiplexer_crosstalk.pdf 1.09 MB

sampling order

Changing the sequence of measurements didn't solve the problem.

AttachmentSize
ceat_mux_problem2.png 31.95 KB

prototype: sending TUIO messages (video)

We went back to using only two multiplexers and we also rearranged some components on the breadboard. The processing sketch now features a signal cutoff slider, supports two different blob detection libraries and is able to send TUIO messages. The data gets sent to another computer which runs Pd and generates the audio feedback. A short video is available here: http://youtu.be/AaGAN2iooCA

AttachmentSize
ceat_102012.jpg 114.83 KB

less periodic noise

A few weeks ago we finally got rid of the periodic noise at the multiplexer intersection by connecting them in an alternating way to the vertical cables of the matrix. The resulting picture is quite satisfying - even without the subtraction of the background noise.

AttachmentSize
ceat_112012.jpg 37.05 KB

wiretouch.net

This discussion forum is closed. For further updates please visit wiretouch.net.

Syndicate content