Hallo,

ein paar von euch kennen ja sicher das hier:
http://cs.nyu.edu/~jhan/ledtouch/index.html

Nach ziemlich langem basteln (seit Februar ...) hab ich das Ding
nachgebaut und meine Version kann sogar a bisserl mehr ...

- 8*4 LEDs (die endgültige Version hat 8*8)
- ARM7 (SAM7S64)
- Kommunikation und Stromversorgung über USB2.0
- Weitestgehen Umgebungslicht-unabhängig
- Capture-Rate von >25Hz
- Kleine Bauform von 60mm*60mm

Es gibt ein kleines Demo-Video was ich mit einem Screen-Capture-Programm
aufgenommen habe. Der schwarze Punkt in der Mitte ist der berechnete
Schwerpunkt und man kann ihn fast pixelgenau navigieren. Sollte für eine
Gestenerkennung eigentlich reichen.

http://home.in.tum.de/~pototsch/touch1.avi (XVID4, 3MB)

Wenn der Link nicht erreichbar ist, dann über meine Homepage:
http://www.pcb-dev.com/showsite.php?open=f3c1975f2...


Informationen, wie Schaltpläne und Software gibts jetzt aber noch nicht
- erst wenn die 8*8 Version arbeitet. Ich hab den Thread eigentlich eher
gestartet, weil ich fragen wollte, ob es hier Leute gibt, die Lust
hätten an einer Gestenerkennung für das Panel zu arbeiten (vorzugsweise
Linux). Mir fehlt leider sowohl die Zeit als auch der Wissensstand um da
was sinnvolles hinzukriegen.

Und wie schauts prinzipiell aus? Gibts da welche die mitarbeiten wollen
würden?

Mfg
Thomas Pototschnig

Bild vergessen ...

Mfg
Thomas Pototschnig

> Gestenerkennung

also sowas ähnliches wie das "One-Stroke" Schrifftsystem vom Palm
Handheld Computer ? Damit kann ich helfen, habe eine Delphi (PASCAL)
Anwendung geschrieben der per Neuronalem Netzwerk solche One-Stroke
Schriffterkennung kann. Das Neuronale Netzwerk, das GUI usw. habe ich
alles fertig (war mal ein "Forschungsprojekt" vor 4 Jahren)

Also, eine Geste beginnt an einem Punkt auf deinem "Touchpad", bis zu
einem Endpunkt. Es bildet sich eine Kurve mit mehreren Koordinaten die
abgefahren wurden. Wenn du diese Daten auf den PC bekommst, in einem
anständigen Format, dann kann ich in ca. 3 Stunden meine Anwendung
darauf umschreiben. Essentiell besteht die aus 2 Softwaremodulen

1.) Learning/Training
2.) Gestenerkennung

Gruß Hagen

Hallo Hagen,

danke für dein Angebot!

Die Daten kommen über USB einfach als 32 16bit werte zwischen sowas 250
bis 750. In meiner Software (Video von oben) hatte ich eine dumme
Kalibrierung eingebaut, die für jede LED dynamisch die Min- und
Max-Schranke anpasst (Kalibrierung ist dann quasi so, dass man mit der
Hand einmal komplett drauf muss bis die Min- und Max-Werte passen). Das
wurde für die Farbdarstellung dann auf einen Bereich von 0 bis 240 (HSV,
Hue: 0 bis 240° -> RGB) umgerechnet. Der Schwerpunkt wurde ohne
Veränderung der Messwerte direkt berechnet. Ich denke anhand des
Mittelwerts der Werte kann man schon erkennen, wann der Finger wirklich
auf den LEDs ist und dann mit einer Gestenerkennung anfangen.

Ich könnte meinen Code mal so umbauen, dass er die Daten in ein
Text-File schreibt und ein paar Gesten aufnehmen. Dann kann man
vielleicht damit besser experimentieren.

Delphi ist vielleicht ein kleines Problem, weil ich hätte gerne die
Gestenerkennung für ein Embedded-Linux gehabt und da wär's praktisch
wenn das in C/C++ wäre. Wieviel Zeilen Code hat denn dein Projekt
ungefähr? Ich hab Jahrelang unter BP7 und eine Zeit in Delphi
programmiert und könnte versuchen es zu portieren.

Mfg
Thomas Pototschnig

So nachdem ich XVID Codec installiert habe konnt ich auch deine AVI
anschauen.

Der Source für das Neuronale Netzwerk umfasst 2500 Zeilen in
Delphi/PASCAL. Auf C/C++ umschreiben wollte ich das Monster nicht,
besonders weil ich auch moderne Sprachkonstrukte benutze die es so nicht
in C/C++ gibt. Portieren kann man zwar alles aber die Muse dazu habe ich
in diesem Fall nicht.

Man müsste dann sowieso zwei Sourcen pflegen. Einmal die Software für
den PC die ein Neuronales Netz trainiert, quasi erschafft, und dann
speichert. Auf deiner Linux-MCU würde die zweite Software arbeiten die
nur ein fertiges Netz benutzt um eine Aussage zu treffen, also ganz ohne
die Möglichkeit das Netz zu trainieren. Denn der Trainings-code ist der
Löwenanteil im Source und benötigt die meiste Rechenzeit.

Alles in allem noch ne Menge Arbeit fürs Hobby und man sollte sich
fragen ob du wirklich eine Gestennerkennung programmieren möchtest und
ob das dann auch eine sinnvolle Anwendung findet. Falls ja und ich kann
mich darauf verlassen, wäre ich bereit bischen Zeit darin zu
investieren.

Das Kalibrierungsproblem erledigt sich von selbst. Du sendest ja alle
Datenwerte aller LEDs auf deinem Touchpad. Das neuronale Netzwerk
bekommt nun zb. 20 solcher Packete, also 20mal im zeitlichen Abstand von
Millisekunden das komplette eingescannte Touchpad. In diesem Moment
rechnet das Netzwerk relativ zum gesamten Touchpad, und somit immer mit
dem Mittelwert der Aussteuerung der LEDs untereinander. Das Netzwerk
reagiert quasi nur auf die "Reizunterschiede" zwischen den LEDs, statt
mit absoluten Werten zu arbeiten. Dh. egal welche Werte deine LEDs ->
ADCs -> ermittelt das Netzwerk reagiert nur auf Touchpads deren LEDs
einen Schwellenwert zueinander überschreiten. In deinem AVI wären zb.
alle LEDs blau und eine Gruppe davon hätte einen stark abweichenden Wert
davon. Das NN erkennt dies als Berührung durch den Finger. Es ist nun
egal ob die LEDs blau oder rot sind solange es eine Gruppe von LEDs gibt
deren Wert weit vom Durchschnitt abweicht erkennt dies das Netzwerk.

Allerdings frage ich mich ob so ein "Software-Geschütz" nicht besser mit
einem echten Touchpanel mit großer Auflösung wäre.

Gruß Hagen

Naja der trick dabei ist ja, dass man den mittelwert doch ziemlich genau
bewegen kann. Da macht die geringe auflösung nicht so viel aus.

Das Netzwerk reagiert aber nicht auf den Mittelwert sondern auf alle
LEDs, das gesammte Touchpad. So erkennt es zb. auch ungültige Gesten bei
denen nicht ein Fingerkontakt sondern mehrere existieren. Der Mittelwert
ist also unwichtig, das macht das Netzwerk quasi von selbst. Bzw. anders
ausgedrückt: den Mittelwert zu benutzen bedeutet Informationsverlust aus
Sicht des Netzwerkes. Man kann also bestimmte Gesten nicht mehr
trainieren noch erkennen. Zb. eine Zoom-Geste benutzt zwei Finger, am
Anfang zusammengedrückt und dann immer weiter geöffnet. Wir haben also
eine Geste dessen Mittelwert immer an der gleichen Stelle verbleibt, es
aber denoch ein Bewegungsmuster gibt. Namälich am Anfang einen
Druckpunkt der sich in zwei aufteilt die dann immer weiter auseinander
driften. Der Mittelpunk bei so einer Geste wäre immer an der gleichen
Stelle. Und daraus kann das Netz keine Geste erkennen.

Gruß Hagen

Stimmt, darüber hab ich noch garnicht nachgedacht. Ich hatte nur in
errinnerung, dass wenn man die daten schon etwas vorbearbeitet das
netzwerk eher damit klar kommt.

Ja, das stmimt schon. Das Preprozessing der Daten fürs Netzwerk ist sehr
wichtig, oft wird man das Netz nie zum Laufen bekommen wenn das
Preprozessing nicht stimmig ist. Allerdings ist das bei einer Auflösung
von 16x16 Pixeln eher weniger wichtig. Entweder alle 256 Inputs am Netz
oder ein HVD-Preprocssing. Dabei betrachtet man die Horizintalen
Zeilen+vertikalen Spalten und die Diagonalen des Touchpads. Statt 256
Inputs im Netz also nur 16+16+17 = 49 Inputs.

Als Netzwerk kommt nur ein sogenanntes Recurrentes Netzwerk in Frage.
Das sind Netze die "Neuronen", ich sage lieber Units, besitzen deren
Output als Input benutzt wird, also eine Rückverdrahtung haben. Solche
Netzwerke haben ein Gedächtnis und können sequentielle Muster erlernen.
Dh. man scannt zb. alle 100 Millisekunden das Touchpad, es entstehen
sequentielle Muster, und das Netzwerk trainiert sich auf die Abfolge
mehrerer solcher Muster aneinander gereiht. Mit normalen Netzwerken wie
Hopefield/Backpropagation NNs ist sowas nicht machbar.

Gruß Hagen

> Alles in allem noch ne Menge Arbeit fürs Hobby und man sollte sich
> fragen ob du wirklich eine Gestennerkennung programmieren möchtest und
> ob das dann auch eine sinnvolle Anwendung findet. Falls ja und ich kann
> mich darauf verlassen, wäre ich bereit bischen Zeit darin zu
> investieren.

Wieviel Zeilen code hat denn nur die Erkennung selber? Für das
Trainieren reicht die Delphi-Version ja auch - so ein
Betriebssystem-Fetischist muss man nicht sein, dass man alles für Linux
haben muss. Nur halt die Endplatform ist halt dann ein Linux.

Ja, es gibt einen Grund warum ich unbedingt das Touch-Panel fertig
kriegen wollte ... Ich arbeite seit 2 Jahren kleinere Komponenten (Mein
PAL-Encoder ist zB eine davon -> High-Quality-PAL-Grafikkarte in
Codesammlung) für ein Monsterprojekt aus. Das Touch-Panel soll quasi das
Haupt-Bedien-Element des Projekts werden. Das Projekt ansich ist ein
Monster-Autoradio und es sollten z.B. so Gesten wie "Kreis im/gegen
Uhrzeigersinn" für Vol+ und Vol- erkannt werden und sowas. Gibt noch
andere geplante Komponenten, aber das ist so ein 10-Jahres-Projekt :-)

Gibt es denn irgendeine Ausarbeitung zu deiner Gestenerkennung? Oder
kannst du mir Literatur empfehlen? Ich würde mir das auch gerne selber
noch anschauen und rausfinden, ob ich das nicht doch noch selber
probieren möchte, bevor du da ein Haufen Zeit investierst ...

Mfg
Thomas Pototschnig

Ich probier das hier vielleicht mal aus:
http://www.ci.pwr.wroc.pl/~piasecki/publications/h...

Sieht interessant und einfach aus. Mal kucken ob ich damit weiterkomme
:-)

Mfg
Thomas Pototschnig

Poah, das ist ja krass. Wie genau funktioniert das? In einem dieser LED
Gehäuse auf der Platine ist eine IR-LED und ein IR-Fototransistor, bzw
IR-Diode? Und der "gemessene" analoge Wert der quasi von der Hand
"zurückkommt" wird an den PC geschickt?
Oder wird die IR-LED selbst als lichtmessendes Instrument benutzt (Soll
ja auch irgendwie gehen, habe ich mal gelesen)


Wenn mich nicht alles täuscht könnte man damit doch ein richtig
stylisches leuchtendes Touchpad realisieren, um zum Beispiel bei einem
Notebook die Maus zu steuern...

So genial, aber doch so einfach! Ich bin entzückt :D

Simon Küppers wrote:
> Poah, das ist ja krass. Wie genau funktioniert das? In einem dieser LED
> Gehäuse auf der Platine ist eine IR-LED und ein IR-Fototransistor, bzw
> IR-Diode? Und der "gemessene" analoge Wert der quasi von der Hand
> "zurückkommt" wird an den PC geschickt?
> Oder wird die IR-LED selbst als lichtmessendes Instrument benutzt (Soll
> ja auch irgendwie gehen, habe ich mal gelesen)

LEDs können auch als Photo-Dioden betrieben werden. Zwei LEDs senden
Licht aus, die LED dazwischen empfängt es wieder. Dann braucht man "nur
noch" das Ganze multiplexen und voila fertisch :-) Gibt also keine
Fototransistoren ...


> Wenn mich nicht alles täuscht könnte man damit doch ein richtig
> stylisches leuchtendes Touchpad realisieren, um zum Beispiel bei einem
> Notebook die Maus zu steuern...

Wenn man sichtbare LEDs verwendet kann man auf dem Touch-Panel sogar
noch irgendwelche 8*8-Grafiken anzeigen ...

Als Maus ... hmm ... das müsste ich fast mal ausprobieren ...

> So genial, aber doch so einfach! Ich bin entzückt :D

Ich hatte eigentlich sogar richtig böse Probleme mit dem scheinbar
Einfachen und wollte es diverse male an die Wand werfen ;-)

Mfg
Thomas Pototschnig

Wie messt ihr denn die als Detektor verwendeten LEDs aus? Schon mit ADC,
aber wie ist beschaltung etc? Ich habe es mal mit einer LED (leuchten,
umpolen, messen) probiert, hat aber nicht funktioniert....

Mit einer LED wirst du nicht viel schaffen. Außer du polst schneller um
als das Licht unterwegs ist - das ist aber schon echt schnell ... :-)

Versuchs mal mit zwei LEDs - kann man normalerweise so betreiben wie
normale Photo-Dioden ...

Mfg
Thomas Pototschnig

ja ok, aber wie beschaltet ihr das und wie lest ihr ein? mit nem ADC
oder wie macht ihr das?

Standard-Photodioden-Schaltung ist sowas hier z.B:
http://hyperphysics.phy-astr.gsu.edu/hbase/electro...

OP als Strom->Spannungswandler geschaltet. Ua = -Iphoto * Rf

Die Photodioden werden normalerweise mit z.B. 80µA oder so angegeben.
Ist glaub ich der Photostrom bei 1000lx oder so ... d.h. bei 80µA
würdest du mit einem 10k-Widerstand -0.8V kriegen. Bei normalen LEDs ist
der Photostrom eigentlich noch kleiner, weil die nicht für den Einsatz
als Photo-Dioden optimiert wurden.

Mfg
Thomas Pototschnig

benötigst du für die erkennung die gesammte rehenleistung des ARM, oder
glaubst du, dass es möglich wäre das ganze auch auf einem Avr laufen zu
lassen?

(war ja klar, dass die Frage irgendwann kommt^^)

:-)

Ja, mit der Frage hab ich gerechnet. Ehrlich gesagt langweilt sich der
ARM zu 99,9999%. Es ist eigentlich überhaupt kein Problem das auf einen
AVR zu portieren, vorausgesetzt er hat genug Pins. Der einzige Nachteil
- ich glaub aber, dass sich das nicht negativ auswirkt - ist, dass der
ARM7 32 Port-Pins gleichzeitig umschalten kann und es so keine
zwischenzustände beim Multiplexen oder so gibt.

ARM7 ists eigentlich nur geworden, weil der USB hat und er günstig ist
und weil ich irgendwann mit den AVRs garnichts mehr machen will ...

Mfg
Thomas Pototschnig

Hi ist ein interesantes Projekt, ich hab erst gestern auch mit ner LED
als Photosensor missbracuht und bin erstaunt über die empfindlichkeit.
Da ich hier auch nen paar LED-Matrix rumfahren hab und das auch mal aufn
AVR hauen will wäre es schön wenn du mir vieleicht den Quellcode und
vieleicht den Schaltplan schicken könntest, die umsetzung aufn AVR
dürfte dann kein Problem mehr sein. Vielen Dank!

grüßle lightninglord

Hallo,

ich hab jetzt alle Sachen wie Source-Code, Layout, Schaltplan usw unter
der GPL V2 lizensiert.

http://www.pcb-dev.com/showsite.php?open=f3c1975f2...

Viel Spaß damit :-)

Mfg
Thomas

Das Programm von Hagen ließe sich evtl. unter Linux mit Freepascal
(http://www.freepascal.org/) compilieren. Im großen und ganzen ist
Freepascal Pascal und Delphi kompatibel und für viele Plattformen
verfügbar.

Gerhard

Hallo Thomas

> ich hab jetzt alle Sachen wie Source-Code, Layout,
> Schaltplan usw unter der GPL V2 lizensiert.

Coole Sache. Danke.

Grüße
Flo

So, ich muss jetzt mal diesen alten Thread herauskramen in der Hoffnung
dass Thomas oder jemand anders, der ein wenig Ahnung von Analogem
Gedönsel hat mitliest :-)

Im Anhang befindet sich die analoge Aufbereitung des Signals, das von
der LED kommt. Wenn ich das richtig verstanden hab, ist der Ablauf so:

1. Spalte wird aktiviert (D.h. jede 2. LED in Vertikalrichtung bekommt
Spannung an die Anode angelegt)
2. Eben diese LEDs, die Spannung an die Anode gelegt bekommen, kriegen
über die Reihen Masse an ihren Kathoden angelegt.
3. Nun beginnt eine Schleife der Reihe nach die Ausgänge auf Masse zu
legen, an dessen LEDs keine Spannung an der Anode liegt.
4. Jedes mal wird über die Spalte, die direkt neben der bestromten
Spalte liegt die analoge Aufbereitung, sowie der AD-Wandler gelegt (das
ganze über einen analogen MUX).

Wenn dies so richtig ist, ergeben sich mir ein paar Fragen:
Dadurch dass an den Reihen der Reihe nach Masse angelegt wird, liegt die
an der Spalte gemessene Spannung im negativen Bereich.
1. Diese negative Spannung gelangt nun in den MUX. Der MUX kann
Spannungen schalten, die außerhalb der Versorgungsspannung liegen?
2. Durch den MUX gelangt die Schaltung an einen *nicht*invertierenden
Verstärker, der aber nur mit Masse/+5V versorgt wird?!
3. Nun verlassen mich komplett die Analogkenntnisse, und ich sehe direkt
nach dem nichtinvertierenden Verstärker ein paar Hochpässe und einen als
invertierenden Verstärker beschalteten Operationsverstärker.
4. Oder wie sieht das aus? Ich wäre sehr dankbar, wenn mir einer das
komplizierte Analogtechnikgebilde mal einer erklären könnte.

EDIT: Also ich habe mir nochmal die Schaltungen zu der Fotodiode
angeschaut. Speziell der Link, den Thomas oben verlinkt hat.

Es sieht für mich so aus, als entstehe der Fotostrom in Sperrrichtung.
Das heißt, dass, wenn man die Anode an Masse anschließt, über die
Kathode eine positive Spannung misst. So würde Thomas Schaltung sinn
machen. Allerdings würde ich dann nicht verstehen, dass er einen
invertierenden Verstärker einsetzt. Ich vermute mal dass der im
Subtrahierbetrieb arbeitet. Wenn ja: Warum genau?

hallo leuts,

habe den beitrag nicht komplett gelesen, muß aber sagen das mir die
ansätze (touch-sensor, neuronales netz, gestenerkennung) sehr gefallen.
würde mich evtl. auch noch mit einklinken.

@hagen re

wäre es möglich das ich mir mal den pascal-code anschauen kann ?
vielleicht schreibe ich ihn in c/c++ um. ich habe zwar keinen schimmer
von dessen ressourcenverbaruch und portierbarkeit, aber wäre
interessiert an einem solchen algorithmus (und damit etwas
rumzuspielen). wäre das ok ?!

gruß
rene