Algorithmus zur Lokalisation auf einem Fussballfeld gesucht

[Sebastian.Zug]

Hallo zusammen,

ich suche einen (mikrocontrollertauglichen) Algorithmus, um mich auf einem Tisch mit hohem Rand mit Hilfe von Abstandsensoren lokalisieren zu können. Der Tisch hat zum Beispiel Abmaße von 2mx1m ich verwende 3 Laser Abstandssensoren im Winkel von 120 Grad. Der eine spuckt mir einen Wert von 50, der zweite von 70 und der dritte von 120 Zentimetern zum Rand aus. Frage: Wo bin steht der Robby auf dem Tisch?

Bislang habe ich es so gemacht, dass ich über meinen Tisch ein Netz mit einer Auflösung von 2 cm gelegt habe und dann für alle Punkte markiert habe die 50cm und weniger von einer Wand entfernt sind. Dann eine zweite Matrix mit allen Punkten die 70 cm und weniger von der Wand entfernt sind und eine dritte ... Dann habe ich die 3 Matrizen übereinander gelegt und geschaut ob es Punkte gibt, die in allen 3 Matrizen enthalten sind. Meist waren das wegen der Ungenauigkeit der Sensoren mehrere.

Das Problem ist nur ... das Verfahren ist zu aufwendig für meinen 8bit Controller :-( Kann man das Ganze nicht irgendwie analytisch lösen. So was muss doch schon mal irgendwer effektiver gelöst haben.

Freue mich auf Eure Anmerkungen, Links, Hinweise

Sebastian

[RoboNull]

Denks dir mal durch.

Den Gedankengang erschwerst du dir schon, dass du die Sensoren je 120 Grad angeordnet hast. Angenommen du hast 4 Abstandssensoren N, S, W, O. Dann kannst du ziemlich genau sagen, wo sich der Roboter befindet - WENN er parallel zu einem Seitenrand ist!

Ist er schräg dann wirds schwerer das Ganze auszuwerten.

Die meisten Roboter haben für solche Operationen auch noch einen Kompass, dieser ist jedoch leicht durch Elektronik zu stören. Ultraschallsensoren würden meiner Meinung auch noch Sinn machen um weitere Gegenstände zu identifizieren.

Angenommen du nimmst den Kompass:
Dann könntest du deine Richtung recht genau bestimmen, die differenziellen Grade zur parallelen Bande bestimmen und die Abstandssensoren dann darauf umrechnen.

=> Arbeit. Abstand wählen => Werte austesten etc.
=> recht statisch auf ein bestimmtes Feld bezogen.

Interessant für dich ist sicherlich das hier:
http://www.scipub.org/fulltext/jcs/jcs62173-179.pdf

[PICture]

Hallo!

@ Sebastian.Zug

Ich stimme dem RoboNull völlig zu, dass du dir die Entwicklung selber erheblich erschwerst. Theoretisch um 2D Position zu bestimmen reichen zwei um 90° drehbare Laser in zwei Ecken aus.

MfG

[Sebastian.Zug]

Hallo zusammen,

Ihr habt natürlich recht, die gängigen Verfahren beruhen auf einer deutlich größeren Menge von Punkten, die zum Beispiel mit Laserscannern erzeugt und aus einem Kamerabild gefiltert wurden.

Ich habe am Wochenende beim RoboCub aber auch die Liga für Kinder angeschaut, deren größtes Problem darin bestand festzustellen wo man sich befindet. Nun habe ich die oben beschriebene, sehr aufwendige Lösung gehackt ... für Mikrocontroller aber völlig unbrauchbar.

Nun versuche ich das ganze in ein Gleichungssystem zu drücken und dabei den Rechenaufwand möglichst gering zu halten.

... in dem Paper von @RoboNull nutzt man einen anderen Ansatz, da werden die Roboter von einem stationären Kamerasystem getrackt, ich möchte das ganze aber gern auf dem Roboter laufen lassen.

Na vielleicht fällt noch jemandem was ein ...

[damfino]

Hallo,
Du hast also 3 Abstandssensoren im Winkel von 120° auf dem Robi? Die Position kannst mit ein paar Winkelfunktionen ausrechnen, einfach mal bei Dreiecken nachschauen.
Der Haken an der Sache ist, wenn der Robi beliebig fahren darf, gibt es 4 korrekte Ergebnisse! Du weisst ja nicht wo der kürzeste Abstand ist, Norden, Süden, Osten, Westen?
In Kombination mit einem Kompass müsste es eindeutig sein. Dazu braucht man ein globales=Feld und ein örtliches=Robi Koordinatensystem, und kann so das örtliches System immer am globalen ausrichten.
Habe mir sowas ähnliches schon selber überlegt, aber muss das erst mal eine Idee haben wie man das auf 25x43m umsetzt ohne dass man von einem Laser erblindet.

LG!

[mare_crisium]

Sebastian,

da hast Du ein sehr interessantes Problem gestellt :-) !

Lass' uns mal schnell die Bekannten und Unbekannten des Gleichungssystems durchgehen:
Bekannt sind die Richtungen der Peilrichtungen im fahrzeugfesten Koordinatensystem. Ausserdem sind die drei Entfernungen entlang der Peilrichtungen zur Spielfeldbegrenzung (Bande) bekannt.
Gesucht sind die x- und y-Koordinate des Standortes im spielfeldfesten Koordinatensystem und der Drehwinkel des Fahrzeugs gegenüber einer dieser beiden Koordinaten (3 Unbekannte). Unbekannt sind auch die Lage der Schnittpunkte der Bande mit den Peilrichtungen (3 Unbekannte). Es geht also in Summe um 6 Unbekannte.

Mit den bekannten Grössen können wir drei Gleichungen aufstellen; für jeden Schnittpunkt zwischen Peilrichtung und Bande gibt's eine Gleichung.

Im Moment überblicke ich noch nicht, ob diese Gleichungen Vektor- oder Skalargleichungen sind. Wenn's Vektorgleichungen sind, ist das Problem lösbar (6 Gleichungen mit 6 Unbekannten). Sind die Gleichungen skalar, dann fehlen 3 Gleichungen.

Wie denkst Du darüber?

Ciao,

mare_crisium

EDIT: Habe 3 Unbekannte übersehen, nämlich die Nummern der Banden, mit denen die Peilrichtungen sich schneiden. Das macht in Summe 9 Unbekannte. Damit wäre das Problem mit drei Peilrichtungen nicht lösbar. - Oder?

[XBert]

Eine eindeutige Lösung kann es nicht geben, es müsste aber möglich sein das ganze iterativ zu lösen.
Meine Idee ist folgende: Wenn man von jedem Randpunkt einen Kreis aufspannt mit dem Radius a (z.b die gemessenen 50) und von jedem Punkt an diesem Kreis einen weiteren Kreis zeichnet mit Radius b (z.b 70) und dann nachsieht wo der 2te Kreis die Seitenwand schneidet. Wenn die 3 Punkte einen Winkel von 120° einschließen müsste man eine potenzielle Lösung haben. Um die letzten Falschen noch zu eliminieren zeichnet man einen 3ten Kreis mit Radius c vom Mittelpunkt von Kreis 2 aus und schneidet wiederum mit der Wand. So müsste es doch funktionieren (schnell ist es zwar nicht wirklich, aber vielleicht kann man es noch vereinfachen)

LG XBert

[Sebastian.Zug]

Hallo zusammen,

vielen Dank für Eure Beiträge! Ich würde mich freuen, wenn wir die Diskussion in dieser Intensität fortsetzen !!!

Ich habe mich nun auch an die analytische Lösung gemacht. Wie schon @mare_crisium deutlich machte, kann man mithilfe einiger trigonometrischer Gleichungen die Position bestimmen. Schwierig ist das Ganze nur wegen der verschiedenen Fälle, die es zu beachten gilt: Der Rechenweg unterscheidet sich zum Beispiel für die Fälle dass:

* jeder Sensor eine andere Wand erfassen
* 2 Sensoren zu einer gemeinsamen Wand messen


Wenn man nun überlegt, dass es 4 Wände (A,B,C,D) gibt, dann kann man für 3 Sensoren (m1,m2,m3) eine Tabelle aufstellen, die die Fälle die @mare_crisium im Edit zu seinem Post andeutet, zu erschlagen



Fall m1 m2 m3
1 A B C
2 A A B
3 A B B
usw


Wie viele gültige Kombinationen es gibt muss ich mir noch überlegen. Im Prinzip muss ein Programm nun in allen Fällen nach einer Lösung oder einem Lösungsraum suchen.

Für den Fall (1) aus obiger Tabelle möchte ich einen Berechnungsweg zur Diskussion stellen, der auf die anderen (3 Sensoren sehen 3 Wände) Fälle übertragbar ist. Für Fall (1) kann es anders als bei (2) nur eine eindeutige Lösung geben kann. Es geht also darum, die bekannten Faktoren so zu kombinieren, dass entweder eine wahre Aussage entsteht oder ein Widerspruch produziert wird.

Ich habe mich auf die Winkelsumme von alpha, beta, gamma und phi konzentriert, die ja 180 Grad ergeben müsste. Dafür habe ich voneinander unabhängige Gleichungen dafür aufgestellt. Ich werde es dann gleich mal in einem Skript testen ... aber vielleicht findet ja jemand von Euch einen Weg der 2 oder 3 Rechenschritte weniger braucht :-)

Grüße und ein schönes Wochenende

Sebastian

PS: Die Idee von @XBert habe ich leider nicht verstanden, vielleicht kannst Du sie mit einer Skizze verdeutlichen. Danke.

PSS: Natürlich hat @damfino mit seiner Überlegung recht, dass sich Mehrdeutigkeiten und schlimmstenfalls Lösungsräume ergeben. Die möchte ich damit abfangen, dass ich den Roboter in seiner Bewegung ausgehend von einer bekannten Inertialposition anhand einer Odometrie tracke und die Positionsschätzung der Sensoren zur Korrektur gegenüber dem Absolutsystem verwende.

[mare_crisium]

Sebastian,

ich gehe solche Sachen lieber mit Vektorrechnung an, das ist für mich anschaulicher als die Trigonometrie und liefert dieselben Ergebnisse. Deshalb habe ich ein pdf angehängt, in dem ich versucht habe zu erklären, wie ich an die Sache herangehen würde.

Aus den Gründen, die ich in meinem letzten Post erklärt habe, bin ich der Meinung, dass das Problem unlösbar ist. Dann habe ich aber folgendes Gedankenexperiment gemacht (wenn ich's in Wirklichkeit probiert hätte, hätte ich Ärger mit meiner Herzdame bekommen :-) ):

Man stecke drei Schaschlik-Spiesse um 120° versetzt in eine Kartoffelscheibe. Die herausstehenden Enden sollen die Entfernungen zu den Banden darstellen. Jetzt lege man die Scheibe auf die Glasscheibe eines gerahmten Bildes :oops: oder auf ein rechteckig eingefasstes Tablett. Wenn es gelingt, die Scheibe in eine Position zu manövrieren, in der jede der drei Spiess-Enden den Rahmen berührt, dann gibt's eine Lösung. Das schien mir dann doch nicht so umöglich zu sein ;-) .

Dabei ist mir klargeworden, dass sich jede Lösung wiederholt. Bei einem rechteckigen Spielfeld zweimal (um 180° gedreht) und bei einem quadratischen viermal (um je 90° gedreht). Insofern hat XBert mit der vermuteten Mehrdeutigkeit recht.

Ciao,

mare_crisium

EDIT: Anhang gelöscht, wg. Upload-limit

[rossir]

Vielleicht kann man synthetisch vorgehen (statt analytisch). Stichwort MonteCarlo Localisation.

Wenn Du glaubst, dass der Roboter sich an Position (x, y, a) befindet kann man errechnen was Laser 1 (der nach vorne in Winkelrichtung a schaut) theoretisch für einen Abstand zum Rand messen müsste (Solldistanz). Das kann man für alle drei Laser machen:
sd1 ist Solldistanz für Laser 1 mit Winkel a.
sd2 ist Solldistanz für Laser 2 mit Winkel a+120.
sd3 ist Solldistanz für Laser 3 mit Winkel a-120.

Das kann man mit den Istdistanzen (also den konkreten Messwerten) der Laser vergleichen.
id1 ist Istdistanz von Laser 1 mit Winkel a.
id2 ist Istdistanz von Laser 2 mit Winkel a+120.
id3 ist Istdistanz von Laser 3 mit Winkel a-120.

Jetzt kann man x, y und a ein wenig und vorsichtig variieren, produziert/synthetisiert sich also eine kleine Menge von
Positionsvarianten.

Schließlich nimmt man genau die Positionsvariante als neue/bestätigte Position des Roboters an, welche mit
ihren sd-Werten am besten mit den tatsächlichen id-Werten übereinstimmt.

Mit dem folgenden Code könnte man die sd-Werte (also sd1, sd2 und sd3) berechnen. (Stimmt der?)

double dsim(double x, double y, double a) {
double xd=max(xmax, ymax), yd=max(xmax, ymax);
double c = cos(a);
double s = sin(a);
if (c < 0) xd = (0 - x) / c;
if (c > 0) xd = (xmax - x) / c;
if (s < 0) yd = (0 - y) / s;
if (s > 0) yd = (ymax - y) / s;
double dsim = (xd < yd ? xd : yd);
return dsim;
}

[Sebastian.Zug]

Hallo zusammen,

sorry, dass ich Eure umfangreichen Beiträge noch nicht gewürdigt habe !!! In dieser Woche fehlt ein wenig Zeit ...

Danke für die Überlegungen an @mare_crisium, da brauche ich glaube ich ein paar Stunden um das ganze zu durchschauen ... spätestens am Wochenende bin ich wieder da, wahrscheinlich mit einer Handvoll Fragen. Die Mehrdeutigkeit der Lösung ist mir, zumal sehr anschaulich von Dir geschildert schon klar, ich möchte dieses Problem gern durch ein Tracken der Position aus einer definierten Inertialposition heraus lösen.

Dazu passt auch der Hinweis von @rossir wenn ich anhand der Odometrie schon eine Positionsschätzung habe, brauche ich nicht alle möglichen Positionen des Spielfeldes abzusuchen sondern nur das engere Umfeld !!!

Grüße

Sebastian

[Sebastian.Zug]

Hallo zusammen,

ok, da habe ich wieder losgebastelt ohne vorher zu überlegen. Bisher war ich völlig auf 3 gleichverteilte Sensoren am Roboter eingeschossen, dass man mit denen unter Umständen gar keine (auch mit Richtungswissen) Aussage zur Position treffen kann, ist mir erst anhand der Kartoffelscheiben Darstellung von @mare_crisium klar geworden.

Also habe ich mich jetzt erst mal damit beschäftigt herauszufinden, wie viele Sensoren ich eigentlich am Roboter brauche, um mich in allen Position auf dem Tisch zu recht zu finden. Klar, wenn ich nur Sensoren mit einer geringen Reichweite habe, nützt der mir in der Mitte des Tisches nichts, kann am Rand aber noch ganz brauchbare Ergebnisse liefern.

Ich habe einen Simulator geschrieben und für bis zu 10 Sensoren mit einer Reichweite von 1cm bis zur Tischdiagonalen die Frage testet - Siehe Gesamtübersicht.pdf . Ich untersuche für jeden Eintrag in der Matrix (1 cm als Auflösung) jede Orientierung des Roboters darauf, ob eine hinreichende Zahl von Messwerten besteht um eine Lokalisierung auszuführen.
Interessant ist, dass man offenbar mindestens 6 Sensoren braucht um sich bei dieser Tischkonfiguration (122 x 188) zurecht zu finden.

Um das Ganze etwas zu illustrieren zwei Bilder unterschiedlicher Reichweiten mit 3 und 6 Sensoren ... wobei die Reichweite (85cm) auch für 6 Sensoren noch nicht ganz ausreicht, um sich auf dem ganzen Tisch lokalisieren zu können. (0 bedeutet, dass in keiner Richtung eine korrekte Positionierung möglich ist, 1 sagt hier funktioniert die Lokalisierung in allen Richtungen)


Soweit so gut ... Was meint Ihr, ist die gleichverteilte Anordnung der Sensoren zu nicht zu toppen oder bekommt man mit unsymetrischer Verteilung unter Umständen eine Positionierung mit geringerer Reichweite hin? Das Problem ist die Performance meiner Simulation. Um alle in 8 Sensorkonfigurationen aus der Gesamtdarstellung durchzuspielen hat mein Rechner über eine Stunde gebraucht :-(

Grüße und einen schönen Sonntag noch

Sebastian

[rossir]

Irgendeine Voraussetzung Deiner Simulation verschweigst Du oder verstehe ich nicht.


Hier zwei Gegenbeispiele:
Kein Roboter (auch mit 1000 Lasersensoren (symetrisch oder asymetrisch angeordnet) die jeweils unendliche Reichweite hätten) kann zwischen den folgenden Positionen (x, y, a) unterscheiden:
Gegenbeispiel 1
(10, 10, 180) und (112, 178, 0)

Gegenbeispiel 2
(61, 94, 0) und (61, 94, 180)

Allgemein:
Die Laserlokalisation allein hilft nicht um zwischen einer Position und der punktgespiegelten Position zu unterscheiden.

D.h. bei Deiner Untersuchung dürfte höchsten der Wert 0.5 (statt 1.0) raus kommen.

Das mit der 1cm Auflösung Deiner Matrix verstehe ich zwar aber Du sagst nichts zur Auflösung der untersuchten Roboterblickrichtungen.

[Sebastian.Zug]

Ok, das habe ich nicht richtig deutlich gemacht ... Ich gehe zunächst noch davon aus, dass ich eine fehlerfreie Schätzung der Orientierung des Roboters habe. In der nächsten Stufe baue ich dann ein Modell zur Ableitung der Orientierung aus der Odometrie ein. Dann muss ich mir entsprechend einen Kopf machen, wie man die Ungenauigkeiten gegeneinander abwägt damit das Ganze über der Zeit nicht aus dem Ruder läuft.

Die Auflösung des Winkels beträgt ein Grad.

Grüße

Sebastian

[rossir]

Du hälst also nichts von der MonteCarlo Localisation Variante (siehe weiter oben)?

Ich frage, weil ich selbst einen Roboter plane der sich mit drei IR-Distanzsensoren in einem 3m x 3m Feld zurecht finden soll. Auch mit dem Problem der Schätzung der Position über längere Zeitspannen.

[Sebastian.Zug]

@rossir

Welche Sensoren schweben Dir da vor? Wenn ich mir die Ergebnisse der Simulation anschaue, kann ich selbst bei optimaler Schätzung der Orientierung mit 3 Sensoren keine Positionierung in jedem Punkt gewährleisten. Oder brauchst Du das gar nicht, sondern genügt eine Prüfung der Positionsschätzung von Zeit zu Zeit.

Ich denke die Dein Ansatz zur Monte Carlo Localisation ist gut geeignet um die Positionsschätzung mit der Richungsschätzung zu verschmelzen. In mehreren Iterationen kann man ausgehend von der Berechnung anhand der Odometrie immer wieder die Richtung anhand der Berechneten Postion verfeinern. Hast Du ein Paper dazu, dass man rasch mal überfliegen kann?

Kann mir jemand eine Tipp geben, in welchem Buch oder wissenschaftlichen Paper sich schon mal jemand mit der Frage "Wieviele Distanzsensoren brauche ich für die Lokalisierung" auseinander gesetzt hat?

Tausend Dank wie immer

[mare_crisium]

@Sebastian,

die Frage, wieviel Sensoren und welche, stellt sich erst, nachdem die Frage nach dem Algorithmus beantwortet ist ;-). In diesem Sinne: Guck' doch mal hier:

http://www.allpsych.uni-giessen.de/dirk/projects/particle.pdf

Die Suchwort-Kombination "+Kalman+Partikelfilter" liefert reiche Beute; u.a. hinsichtlich Monte-Carlo-Verfahren (@rossir ;-) )!

Eine Alternative könnten ortsfeste Navigationsbaken sein. Die Ortsberechnung aus den Peilrichtungen bzw. Peilrichtungen und Entfernungen ist klar. Für die Aufgabe, die Baken aufzufinden ;-) und zu identifizieren, müsste man eine geeignete Methode aussuchen.

Ciao,

mare_crisium

[rossir]

Ich möchte den IR Sensor GP2Y0A02YK nutzen.

Zur Anzahl der Lasersensoren habe ich keine Lösung, aber folgende Überlegung anzubieten.
Wenn der Roboter sich nicht drehen kann, dann reichen zwei Lasersensoren um den Ort genau zu bestimmen:
Einer der senkrecht auf die Längsseite des Spielfeldes (x-Achse) zeigt und
ein anderer (um genau 90 Grad versetzt) der senkrecht auf die Kurzseite (y-Achse) zeigt.

Ich denke, Allgemein wird gelten: Nur wenn ein Laser die x-Achse trifft und (irgend) ein anderer Laser die y-Achse trifft kann ich die Position bestimmen.

Jetzt lautet die Frage: Wieviel Laser brauche ich, damit immer einer davon die x-Achse trifft und irgend ein anderer die y-Achse trifft. Selbst dann, wenn der Teufel den Roboter auf dem Spielfeld positioniert und ausrichtet.

Der Teufel hat auf der Mittellinie gute Chancen den Roboter so zu drehen, dass kein Laser auf eine der beiden Kurzseiten trifft. Am Mittelpunkt selbst ist die Chance am größten.

Der Winkel zwischen dem Mittelpunkt (61, 94) und zwei benachbarten kurzen Ecken (0,0) und (0, 122) ist
2*acos(94/(sqrt(94*94+61*61)))
Das sind ca. 66 Grad.

D.h. man braucht 6 Laser (360/6=60) damit der Teufel keine Chance hat. Die kann man ruhig asymetrisch anbringen, solange zwischen Nachbarn nirgends mehr als 66 Grad entstehen.

[mare_crisium]

@Sebastian und @rossir,

es müsste doch mit dem Teufel zugehen, wenn man das nicht auch ausrechnen kann :-) . Für den Fall mit vier Sensoren und eine der möglichen Situationen bin ich nahe daran, eine Lösung auszurechnen. Der letzte Schritt fehlt noch, aber das scheint mir nur noch eine Frage der Ausdauer zu sein...

Ciao,

mare_crisium

EDIT: Anhang gelöscht: Der Ansatz im Posting vom 18.05. ist viel besser.

[z-irgendwas]

Nimm doch einfach Drei Sensoren und lagerst die drehbar(servo).Du wertest einfach das Abstandssignal aus, merkst dir den Winkel.Dann zeichnest du Drei virtuelle Kreise am Schnittpunkt von allen ist dann der Roboter.(du musst natürlich auch noch die positionen dar Sensoren auf deinem Roboter mit einbeziehen).

[rossir]

@mare_crisium

Du sagst nichts zu dem Problem der spiegelsymetrischen Positionen. Willst Du es spannend machen?

Selbst Deine Formeln (Respekt!) bestätigen die hierin liegende Unentscheidbarkeit:
Nimm an Du hast für die Position P die Werte:
E0, E1, E2 und E3
Dann hast Du für die spiegelsymetrische Position P' die Werte
E0'=E2, E1'=E3, E2'=E0 und E3'=E1

Und zwischen r0=(E1-E3)/2 und r0=(E3-E1)/2 etc. unterscheiden Deine Formeln (mit bedacht natürlich) nicht.

Ich verstehe, dass Du m0 bzw. m1 geometrisch konstruieren kannst. Aber in Deiner Formel
m0=1/2*(xu+xo, Ly)
bleiben xu und xo unbekannt, oder?!

[mare_crisium]

rossir,

tja,



bleiben xu und xo unbekannt, oder?!


da hast Du den Nagel mitten auf den Kopf getroffen :oops: . Ich hatte wohl vor lauter Bäumen den Wald nicht mehr gesehen.

Es geht natürlich viel einfacher: An der Skizze kann man sehen, dass sich der Cosinus des Drehwinkels aus L_x/(E_0+E_2) bzw. L_y/(E_1+E_3) berechnen lässt. Und die Ortskoordinaten x und y findet man über x = (E_2 * L_x)/(E_0+E_2) und y = (E_3 * L_y)/(E_1+E_3)
(ganz einfacher Strahlensatz).

An der Drehsymmetrie ändert sich leider nichts. Das Fahrzeug kann nicht feststellen ob's in meiner Skizze nach oben, oder um 180° gedreht, nach unten fährt. Auf dem Fussballfeld kann das zu sehr unglücklichem Rückstand führen ;-).

An der vereinfachten Version bastele ich gerade.

Ciao,

mare_crisium

[mare_crisium]

@sebastian und @rossir,

hier die bessere Lösung ;-).

Ciao,

mare_crisium

EDIT: Anhang durch überarbeitete Version _V08 ersetzt

EDIT: Anhang gelöscht wg. Upload-limit

[rossir]

Na ja, wenn ich die Wahl habe zwischen z.B.
A) y=Ly*E3/(E1+E3)
und
B) y=Ly/2-cos(a)*(E1-E2)/2
nehme ich doch lieber A. Denn B scheint mir - im Gegensatz zu Deinen Ausführungen - in der Praxis, eher weniger Robust zu sein. Oder, schätze ich da etwas falsch ein?

Aber, das habe ich nachgerechnet, es stimmt
Ly*E3/(E1+E3) = Ly/2-cos(a)*(E1-E2)/2
Wieder Respekt!

Ich denke, Du hast meine Überlegung "Zur Anzahl der Lasersensoren" (weiter oben) nicht gelesen. Denn wenn Du schreibst, dass sich jeder Fall (mit nur 4 Lasersensoren) so lösen läßt bist Du - so glaube ich - überoptimistisch.

Und wenn man erst mal einsieht, dass 6 Lasersensoren nötig werden, dann sind Rechnungen mit 4 Lasersensoren erst mal nur etwas zum warm werden.

[mare_crisium]

@rossir,

welches die robustere Formel ist, muss die Praxis zeigen - und da müssen wir auf Sebastian warten ;-) .

@z-irgendwas,

Dein Vorschlag ist naheliegend, hat aber einen Haken: Die Kreise kann man nur ziehen, wenn man die Lage der Schnittpunkte der Peilrichtungen mit den Banden kennt. Leider kennt man aber in Sebastians Anwendung die Koordinaten der Schnittpunkte nicht. Das macht die Sache aber erst interessant - sonst wär's ja nur eine einfache Bakennavigation ;-).

Ciao,

mare_crisium

[z-irgendwas]

Hat es irgendjemand mal ausprobiert?

@ mare_crisium: du hast ja leider recht