Problem mit "Positionserfassung"

[Brückenwächter]

Hallo miteinander.
Nach langer Zeit melde ich mich mal wieder :)
Die ein oder andere Bastelei ist entstanden und neue Projekte kamen und gingen.
Jetzt steh ich aber vor einem "Problem" für das ich keine Lösung habe.

Ich möchte die Position von 2 Punkten in einem beliebigen Raum im Verhältnis zueinander auf 1cm genau erfassen.
Es gibt also keine Möglichkeit ein Koordinatensystem in irgend einer Form aufzuspannen oder per GPS zu arbeiten.
Auch existiert keine Sichtlinie zwischen den Punkten.
Um es mal an einem Beispiel zu erklären möchte ich die Position eines Roboterarmgelenkes und die Position des Greifers erfassen.
(Es ist ein Beispiel, nicht der Anwendungsfall! Es wird also keine Motoren oder Aktoren mit Positionserfassung etc. geben)

Mir würde es auch reichen, das Verhältnis der 2 Positionen zueinander zu erfassen.

Mein ursprünglicher Ansatz - 2 Beschleunigungssensoren zu verwenden,
beide bei Aktivieren auf 0.0.0 zu stellen und dann die jeweiligen Veränderungen mitzurechnen.
Funktioniert aber nicht weil:
1. die Rechenleistung eines Atmel 328 reicht nicht aus (werden in Summe 4 oder evtl 6 Punkte werden)
2. die Präzision reicht nicht aus.


Mir gehen aktuell die Ideen dafür aus :-/
Hat jemand von euch eine?

[HeXPloreR]

Mal ne dumme Frage von mir: Wie soll das funktionieren ohne ein Bezugssystem? - alleine die genannten Faktoren "2 Positionen" und "1cm" setzen irgendein Bezugssystem voraus das mit mindestens 1cm etwas anfangen kann. Sonst ist es einfach nur "irgendwas irgendwie Entferntes voneinander".

Wieso gibt es keine Möglichkeit ein Bezugssystem zu erstellen. Startpunkt scheint es ja zu geben, dann kann man auch ein Buezugssystem darauf erstellen. Wenn man das nur nicht möchte dann ist es ein ganz anderes Problem.

Wenn man die Veränderung der Punkte mitrechnen kann, dann stellt sich die Frage nach der Abhängigkeit voneinander. Um mal beim Roboterarm zu bleiben: Verfährtst du das Gelenk, dann bewegt sich automatisch der Greifer mit obwohl der selbst nichts gemacht hat. Hat sich nun die Position von Gelenk zu Greifer dadurch verändert? - Nein, relativ gesehen ist nichts zwischen diesen beiden Punkten passiert. Und auch wenn man keine einzige Maßangabe dazu hätte, könnte man sagen sie liegen im Verhältnis so wie vorher auch. Aber das Verhältniss von vorher muss schon noch irgendwo her kommen.

Findest Du möglicherweise ein passenderes Beispiel um das Problem zu verdeutlichen - wenn der Anwedungsfall nicht geheim ist dann wäre genau der ganz gut ;)

Viele Grüße
Jörg

[Brückenwächter]

"Mal ne dumme Frage von mir: Wie soll das funktionieren ohne ein Bezugssystem?" --- Wenn ich die Antwort auf diese Frage wüsste, gäbe es den Thread nicht.

Ich versuch es aber noch einmal etwas ausführlicher zu erklären und verzichte lieber auf das Posten von Ansätzen, da eine Rechtfertigung für Verworfenes irgendwie unproduktiv ist.

Der Anwendungsfall ist nicht geheim aber auch ausreichend bescheuert um ihn nicht zu posten, hat aber etwas mit einem Kinderspielzeug zu tun das auch gelegentlich im Zirkus Einsatz findet.
Man nennt die Dinger "Diabolos (http://de.wikipedia.org/wiki/Diabolo_(Spielgerät))", die meisten kennen sie wahrscheinlich vom Sehen her.
Wir haben 2 "Stecken" in den Händen deren Spitze unsere Punkte A und B sind.
Da sich der "Spieler" auch bewegen kann wird ein Koordinatensystem schon schwierig, da er auch quer durch Deutschland reist eher unmöglich.
(Mal von der eventuellen Möglichkeit mehrere hochauflösender Kameras und dem Einsatz massiver Rechenleistung abgesehen)
Ziel ist es jetzt die Spitze der 2 Stecken zu erfassen UND die Position des gesteuerten Spielzeuges zu befassen.
Es sind also in Summe 3 Sensorwerte mit jeweils x/y/z (<-- dient lediglich als ANSATZ! wenn eine bessere Idee vorhanden ist, dann her damit!)
Theoretisch existiert also eine "Sichtlinie" aber ich kenne weder ein optisches noch akkustisches System, dass eine derartige Bewegungsgeschwindigkeit unter vertretbarem Technikeinsatz ermöglichen würde.

Mir würde der Ansatz mit der Erfassung der beiden Stecken zueinander vollkommen ausreichen (und ja, hier gäbe es ja einen Startpunkt), ohne den Diabolo selbst zu betrachten.
Und weil mir die Punkte A und B genügen, habe ich den Anwendungsfall nicht gepostet - man wird sich sonst nur in dem 3. Faktor verstricken der nicht Inhalt des Threads ist.

Den "einfacheren" Fall mit brennenden Stäben habe ich schon mit einer Kamera realisiert, erreiche aber eben bei weitem nicht die ausreichende Geschwindigkeit und Präzision und ist der Ansatz nicht transportabel :-(
Auch einen getunten Diabolo hab ich aktuell testweise im Einsatz (erfasse Beschleunigungen in x y z)

[HeXPloreR]

Ich möchte mal jetzt schon erwähnen das Du selbst ja ausgeschlossen hast ein Bezugssystem zu benutzen bzw der Meinung bist es ginge nicht aufzuspannen. Wie stellst Du dir denn so ein Bezugssystem vor? - Malt man da Linien auf die Straßen von Hamburg bis München - das geht natürlich nicht.

Also ganz ehrlich wenn man da schon ein bestehendes Koordinatensystem wie GPS ausschließt dann hat man schon einiges falsch gemacht , wenn man im gleichem Atemzug "reisen durch Deutschland" sagt. Es soll doch ein Bezug auf einen ORT hergestellt werden? Wie kann das gehen ohne Koordinatensystem.
Mir fällt da auf die schnelle die Move-Steuerung von Sony ein, oder ein Kinect-Sensor und Wii Nunchuc + GPS. Und selbst eine Kinect rechnet nichtz einfach so einen Punkt im Raum aus ohne sich selbst als Bezug zu nehmen.
Und das sich die Sticks in einen wesentlih kleineren Koordiantensystem bewegen werden als GPS abdeckt sollt jetzt auch klar sein. Son 1m³ Kubus sollte da zum Anfang wohl ausreichen.

Du möchtest also ein System entwickeln, ohne irgendwelche Bezüge zu irgendeinem Koordinatensystem und am besten von einem Spi _ona_ge Sattelliten aus deine Sticksspitzen A und B inklusive Orientierung erkennen.

Ich versteh auch die Aufgabe nochnicht. Ein Spieler steht in Hamburg und möchte wissen wo genau die Spitzen der Sticks von einen anderen Spieler in München stehen - ne sorry, diese 3. Position vom Spielgerät jetzt ja auch noch? Wäre es nicht einfacher nur das Spielgerät zu erfassen?
Dann hast Du recht, die Idee ist wirklich ausreichend bescheuert. Ich mag sie :)

Vor unendlich Langer Zeit fand ich mal diese Video bei YouTube: https://www.youtube.com/watch?v=1O1hiE7sVPM oder eher sowas hier https://www.youtube.com/watch?v=-KxjVlaLBmk
Obs hilfrecih sein wird .... keine Ahnung :)

[Brückenwächter]

Reisen durch Deutschland = Ein Kamerasystem ist nicht ausreichend mobil, ein optisches Koordinatensystem damit komplett ausgeschlossen.

Es geht aktuell nur darum die Position der Stabspitzen zueinander festzustellen (ohne Sicht, ohne Ultraschall!)
Im nächsten Schritt sollen dann noch die Hände mit einbezogen werden (= 4 Punkte)
und dann kommen dazu noch die diabolointernen Informationen.

Die ursprüngliche Idee - eine fiktive Nullposition ermitteln (A (0/0/0), B (0/0/0)) und dann mit den Gyros mitzurechnen wieviel man sich bewegt, zielte ja auf eine Vektorenberechnung ab.
Dummerweise ist der Rechenaufwand zu hoch, vor allem wenn man dann noch die zusätzlichen Punkte in der Hand einbeziehen würde.
Würde pro Programmzyklus dann wahrscheinlich den Aufruf von fiktiven (weil berechneten und ohne Bezugssystem einfach mal hingeworfenen) 4 Koordinaten aus dem Speicher, Rückgabewert von 4 Werten aus den Sensoren und darauf folgend deren Einberechnung in die Speicherwerte und Überschreiben des Speichers zur Folge haben.
Grob zusammengerechnet müsste ich dann pro Erfassung 12 Berechnungen / Lese- / Schreibvorgänge durchführen weshalb ich das als Option ausgeschlossen habe.
Zur Realisierung wäre übrigens eine horizontale Ebene nötig und man bräuchte noch eine Lösung zur Korrektur des "wann fang ich eigentlich an zu spielen?" denn auf der "Justierfläche" beginnt man sicherlich nicht.

Ich hatte mal noch über den Einsatz eines Magnetfeldes nachgedacht, etwa im Stil eines Theremin aber da kommt das identische Problem.

[damfino]

Würde es so anfangen:
1. festlegen dass zB Linker Stab Spitze immer der Nullpunkt ist.
2. zu Begin sind beide Stäbe parallel ohne Abstand nebeneinander, so kann man die Ausgangslage festlegen. (Startknopf am Stab?)
3. ab dann mit Beschleunigungssensoren und Gyros die Bewegungen und Abstände berechnen
Hände sollten mitberechnet werden können da die Länge der Stäbe bekannt ist.

Wie man das berechnet, davon klinke ich mich mal aus, ebenso wie die Hardware klein genug wird um damit noch spielen zu können.

Glaube realistischer ist eine Kamera oberhalb montiert die zB Infrarot Leuchtpunkte in den Stabenden erkennt. Transportabel ist eine Kiste mit Rechner und ein Stativ mit Kamera sicher.

LG!

[i_make_it]

Der Ursprung des Koordinatensystems ist der Wirbel T1 der Wirbelsäule des Künstlers.
Die Bewegungen von Schultern, Ellenbogen, Handgelenken Händen und Sticks und damit auch die Positionen von Punkten an den Sticks oder am Körper beziehen sich darauf. Ab C1 gibt es schon veränderungen bei Kopf und Halsbewegungen und die anderen T-Wirbel ändern Ihre relative Position dazu bei Rumpfbewegungen. Ebenso die L-Wirbel. Der Bezugspunkt ist unabhängig von Beinpositionen und der Position und Lage des Menschen im Koordinatensystem der Erde. Skelettmodelle für animierte Figuren (z.B. Blrnder) haben dort auch ihren Bezugspunkt für Schultern/Arme und Hals/Kopf.

Das ein Kamerasystem ausscheidet, glaube ich nicht weder von der Größe, vom Gewicht noch vom Preis.

Die Sony PS3 Eye-Cam kann 120fps und in HD sind immer noch 60fps drin, für rund 20-30€ pro Stück.
Motion Capturing ist da dann nur noch eine Softwarefrage und der Marker.
Wenn keine Tricks wie ums Bein rum etc. vorkommen, kann man an T1 und den Schultern je einen Marker aufkleben ud an den Spitzen der Sticks. eine Cam per Rucksack etwa 40cm hinter dem Künstler (die die 3 Marker an Rücken und Schultern aufnimmt) und je eine Cam an den Schultern sollten funktionieren um in den meisten Positionen die Marker an den Sticks zu erfassen.

[gregors]

... wenn man da schon ein bestehendes Koordinatensystem wie GPS ausschließt dann hat man schon einiges falsch gemacht , wenn man im gleichem Atemzug "reisen durch Deutschland" sagt. ...

Wieso hat man dann schon einiges falsch gemacht (und was)?

Ich versuche derzeit, durch den ausschließlichen Einsatz von IR-Tastern vier bis fünf Zimmer voneinander zu unterscheiden bzw. zu erkennen. Wenn ein Koordinatensystem nötig wird (und das muss nicht unbedingt sein), kann man es auch nachträglich implementieren. Bei entsprechender Programmierung stelle ich mir das nicht so schwierig vor. Durch die Beschränkung auf IR-Taster muss ich mir halt überlegen, wie ich diese bestmöglich einsetze, um die bestmöglichen Informationen zu erhalten. Insofern hatte dieser Typ (irgendein bekannter Typograf) recht mit der Aussage, dass sich Kreativität nur innerhalb von Grenzen richtig entfalten kann.

Gruß

Gregor

[HeXPloreR]

Ich denke ich habe es ausreichend beantwortet oben - außerdem scheint diese Idee nicht weiter verfolgt zu werden.

Was meinst Du denn mit "IR-Taster" genau? - ich hoffe jetzt mal nicht diese Lichtschalter für inne Wand?!?

Z.B. mit Sharps IR-Entfernungsmessern ist es schon ein ganz anders Thema. Und auch hier hast Du einen Bezug, nämlich die gemessen Entfernung.
Und das Du ggf kein Koordinatensystem verwenden musst liegt vermutlich an einer anderen Aufgabenstellung / Formulierung.
Wenn man von einen "sicheren" Anfangspunkt startet, dann macht ein Koordinatensystem in dem man sich bewegen kann durchaus Sinn und unterstützt oder vereinfacht die ganze Sache sogar.

Wenn Dein System genug Informationen über die Räume sammeln kann, dann kann es diese später auch wieder identifizieren. Wenn die Räume sehr stark unterschiedlich sind ist es umso einfacher dieses mit Shaprs zu erledigen.


Viele Grüße
Jörg

[gregors]

... Was meinst Du denn mit "IR-Taster" genau? - ich hoffe jetzt mal nicht diese Lichtschalter für inne Wand?!?

Ich meine zum Beispiel eine Reihe IR-Sende-LEDs, die die Umgebung be„blitzen“ und eine Reihe von IR-Empfängern, die entsprechend der empfangenen (reflektierten) Lichtmenge unterscheiden können, ob etwas näher oder weiter weg ist.
Die Dinger von Sharp mag ich nicht benutzen, weil die mir zu sehr nach „Tütensuppe“ aussehen (anstöpseln, fertig).


Und das Du ggf kein Koordinatensystem verwenden musst liegt vermutlich an einer anderen Aufgabenstellung / Formulierung.
Wenn man von einen "sicheren" Anfangspunkt startet, dann macht ein Koordinatensystem in dem man sich bewegen kann durchaus Sinn und unterstützt oder vereinfacht die ganze Sache sogar.

Ja, dass ich die Aufgabenstellung anders formuliere, macht viel aus. Ich möchte zum Beispiel die über die Räume gesammelten Informationen in einer Netzstruktur (einem Gebilde aus Knoten und Kanten/Verbindungslinien) so unterbringen, dass mir logische Schlüsse so viele Informationen liefern, dass ich feststellen kann, wo meine „Fahrmaschine“ (Roboter nenne ich das vielleicht in ein paar Monaten) sich gerade befindet.

[PICture]

Hallo!

@ Brückenwächter

Mir ist bisher nur eine "verrückte" Idee eigefallen: den Abstand per synchron mit Licht (z.B. IR) ausgestrahltem US messen. Ich stele mir das so vor, dass die US Quelle ein kurzes Impuls rund um sich schickt und auf empfangenes Echo vom zweiter Stabspitze wartet. Diese zweite Stabspitze sedet beim Empfang vom US ein Lichtblitz und ermöglichst somit aus Zeitdifferenz zwischen US und Licht Impulsen den Abstand berechnen. Sorry falls es unverständlich bzw. zu kompliziert ist. ;)

Übrigens, so "berechnet" man die Entfernung vom Blitzschlag bei einem Gewitter, ist also lange ausprobiert. :D

[oberallgeier]

... eine "verrückte" Idee ... so "berechnet" man die Entfernung vom Blitzschlag bei einem Gewitter, ist also lange ausprobiert.Nicht nur das läuft so. Das Ganze ist im Prinzip ein Transponder (evtl. auch ein Sekundärradar) wie er in der Luftfahrt gang und gäbe und beinahe schon elementar ist (abgesehen von den unterschiedlichen physikalischen Eigenschaften der benutzten Wellen hier und dort).

[HeXPloreR]

... Sharp mag ich nicht benutzen, weil die mir zu sehr nach „Tütensuppe“ aussehen (anstöpseln, fertig). ...

Naja etwas mehr wird schon noch dazu gehören, denn durch bloßes anstecken funktionieren die wohl nicht - ist ja schliesslich kein USB.
Ich empfehle die "Tüttensuppe", vielleicht auch eine andere Sorte - mit mehr US Zutaten. Danach irgendwann kann man immer noch schauen ob man was richtiges kocht, oder ob einem das Geschaffende schon zufrieden stellt.

Mal ehrlich, will man das Rad immer wieder selbst erfinden? - reicht einem die Komplexität die Räume zu erkennen nicht aus? - möchte man das Ziel erreichen, und sich gegebenenfalls dann um die ungeliebten Sharps kümmern? Oder möchte man seine Zeit und Energie vorerst darin investieren seine Sende- und EmpfangsLED-Bänke zu sortieren und einsatzbereit zu machen?
Na, muss ja selber selbst wissen.

Viele Grüße
Jörg

[gregors]

Naja etwas mehr wird schon noch dazu gehören, denn durch bloßes anstecken funktionieren die wohl nicht - ist ja schliesslich kein USB.[/qote]

Ja, klar. Ich meinte, dass mir da zuviel Zeug mitspielt, in das ich nicht „reingucken“ kann. Und das mit dem selbstgebauten IR-Taster ist so neu nicht. Wenn ich die beteiligten Teile gut genug kenne und getestet habe, sollte ich damit ziemlich viel anfangen können, denke ich mir so.

[QUOTE=HeXPloreR;615078]Ich empfehle die "Tüttensuppe", vielleicht auch eine andere Sorte - mit mehr US Zutaten. Danach irgendwann kann man immer noch schauen ob man was richtiges kocht, oder ob einem das Geschaffende schon zufrieden stellt.
Mal ehrlich, will man das Rad immer wieder selbst erfinden? - reicht einem die Komplexität die Räume zu erkennen nicht aus? - möchte man das Ziel erreichen, und sich gegebenenfalls dann um die ungeliebten Sharps kümmern? Oder möchte man seine Zeit und Energie vorerst darin investieren seine Sende- und EmpfangsLED-Bänke zu sortieren und einsatzbereit zu machen?


Das Rad möchte ich bestimmt nicht neu erfinden. Aber wenn ich mit IR-LEDs und IR-(Empfangs)-Dioden genauso weit (oder fast so weit) komme, was mich dann im Vergleich zum Sharp nur Bruchteile gekostet hat, und ich dafür nur Zeit investieren muss, bin ich motiviert, das zu probieren.

Primär geht es mir ja nicht darum, mir eine Maschine zu bauen, die mir z. B. den Aschenbecher hinterherträgt oder Verschüttete rettet, sondern darum, möglichst viel zu lernen und Spaß zu haben. Beim Hobby sollte man besser vermeiden, die Sinn- oder die Frage nach dem Kosten-/Nutzen-Verhältnis zu stellen.

Gruß

Gregor

PS: Wieso erscheint beim ersten Zitat keine „Sprechblase“, beim zweiten aber schon?

[PICture]

.... weil beim ersten Zitat im Word "/quote" fehlt ein Buchstaben "u". Das lässt sich aber noch nachbessern. ;)

[HeXPloreR]

...kein USB. [ /quote ]

PS: Wieso erscheint beim ersten Zitat keine „Sprechblase“, beim zweiten aber schon?


..., und ich dafür nur Zeit investieren muss, bin ich motiviert, das zu probieren.
Zeit ...und Wissen. Welches möglicherweise auch erst erworben werden muss. Alleine um Grundlagen nachzulesen kann nen Menge Zeit drauf gehen, vom verstehen und anwenden nochmal ganz abgesehen.

Ich habe irgendwann mal mit meinen Hexapod angefangen ... und mich in den kleinsten Details verloren, das passiert mir immer noch manchmal. Aber mitleiweile bin ich soweit das ich abwäge ob dieses Detail dann (vorerst) zielführen ist oder nicht.
Ob Du nun eien Roboter baust der was hinterherträgt oder "nur" einen Kartographieroboter - das spielt überhaupt keine Rolle. Mögen die Anforderungen bei steigender Komplexität zwar ansteigen, bietet doch ein kleines Projekt genug Details die zum verweilen einladen. Ebenso wie Fehlerquellen.
Die Frage nach dem Kosten-/ Nutzen-Faktor stelle ich auch garnicht mehr, eben weil es Hobby ist.

Allerdings eine Frage stelle ich: "die Motivation sinkt vielleicht mit der Zeit, dann hat man zwar wenig Geld für Teile die im Schrank liegen ausgegeben, aber der Roboter funktioniert vielleicht immer noch nicht?"

Nun da Du überzeugt bist motiviert genug zu sein um es zu versuchen: Erlauter Dein Konzept doch noch mal etwas genauer.

Wie stellst Du Dir die Anordnung der IR LED's vor?
Welche Hardware (µC) möchtest Du nutzen?
Welche Kenntnisse bringst du bereits in Dein Projekt ein?

Welche Probleme fallen Dir spontan im Zusammenhang mit IR-Licht ein?
Wie groß sind die Räume?
Welche Genauigkeit stellst Du Dir vor?

Viele Grüße
Jörg

[gregors]

Wie stellst Du Dir die Anordnung der IR LED's vor?
Welche Hardware (µC) möchtest Du nutzen?
Welche Kenntnisse bringst du bereits in Dein Projekt ein?

Welche Probleme fallen Dir spontan im Zusammenhang mit IR-Licht ein?
Wie groß sind die Räume?
Welche Genauigkeit stellst Du Dir vor?

Zuerst hatte ich vor, eine Batterie von IR-LEDs in Fahrtrichtung leuchten zu lassen. Jetzt kam ich aber darauf, dass das gar nicht das bringt, was ich möchte. Jetzt möchte ich dieselbe Batterie von IR-LEDs den Boden direkt vor meinem „Roboter“ beleuchten lassen und das reflektierte Licht mit Empfängern (TSSP58P38 von Vishay) auswerten. Die erzeugen einen Impuls, dessen Länge der Stärke des empfangenen Lichts entspricht. Das erscheint vielleicht ein bisschen unpraktisch, weil man „Stärke“ eher mit einem analogen Signal assoziiert – der Vorteil eines Signals, dessen Länge variiert, liegt aber darin, dass ich keine analogen Eingänge meines µC (Arduino resp. ATmega328) benötige, um es auszuwerten.

Die Anleitungen für Selbstbau-IR-Tastern, die ich bislang gefunden habe, zeigen eine IR-Empfangs-Diode, die zusammen mit Sende-LEDs zu einem „Päckchen“ verschnürt ist (Empfangsdiode in der Mitte, sechs IR-LEDs drumherum). Die Empfangsdiode liefert dann halt „nur“ ein analoges Signal – wie ich das zu einem Signal mache, das in seiner Länge variiert, weiß ich noch nicht. Vielleicht nehme ich statt einer Standard-Empfangs-LED den oben erwähnten Sensor. Der hat eine andere Bauform als eine Standard-LED, aber dafür liefert er aber schon ein aufbereitetes Signal.

Die Probleme mit der Kartierung/Ortsbestimmung wollte ich zuerst mit „IR-Baken“ und Dreiecksberechnungen lösen, aber die Baken habe ich ebenso gestrichen wie die unterschiedlichen Sensoren ([mechanische] Taster uvm.), die ich jetzt durch IR-Taster ersetzt habe. Wie ich das mit der genauen Orts-/Ausrichtungsbestimmung mache, weiß ich noch nicht, aber es soll in jedem Raum zumindest eine Stelle geben, wo sich der „Roboter“ eichen kann. Diese Stelle soll (so stelle ich mir das zumindest gerade vor) lediglich aus einem A4-Blatt bestehen, das auf den Boden geklebt ist (in definiertem Abstand zu einer Wand). Dort kann der Roboter (die Anführungsstriche lasse ich jetzt weg :-) dann „gucken“, ob seine Sensoren funktionieren, was für Werte sie zurückliefern usw.

Dass ich mir ziemlich viel vorgenommen habe, weiß ich. Aber ich glaube, dass ich in der Zeit, die ich benötige, um das Vorgenommene zu realisieren, auf brauchbare Lösungen für die noch bestehenden Probleme komme. Und wenn das klappt, habe ich einen Roboter, der mit einem minimalen Einsatz von „Eichstellen“ auskommt. A4-Blätter auszudrucken und auf den Boden zu kleben, ist machbar :-)

Gruß

Gregor

PS: Danke für den Hinweis wegen der fehlenden Sprechblase. Ich hatte immer nur das Start-Tag betrachtet und konnte dort keinen Fehler finden ...

[HeXPloreR]

... weiß ich. Aber ich glaube, dass ich in der Zeit, die ich benötige, um das Vorgenommene zu realisieren, auf brauchbare Lösungen für die noch bestehenden Probleme komme. ...

Das ist gut so. Ich glaube wir haben alle hier gelernt das es immer wieder neue Herausforderungen in unseren Projekten gibt. Wäre das nicht so, könnte man alles schon, wäre es ja auch nur halb so spannend.