Ortung über Funk? (RFID) Kartierung von Räumen

[i_make_it]

Du bist jetzt an den Punkt ángekommen wo du besser mal einen Blick in den Thread "Navigation mittels Triangulation" wirfst:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=41447

Das untenstehende ist ein Auszug meiner Überlegung zur Kartierung aus dem selben Thread

Ist zwar nur eine recht primitive Lösung aber ein Anfang der sich ziemlich schnell implementieren lässt.
######
Ich tüftele momentan an einer Rasterkarte (weil einfacher zu implementieren als Vektorkate) bei der ich 2 I2C Rams nehme und jedes Bit von Speicher eins den selben Rasterpunkt wie in Speicher zwei repräsentiert. So stehen mir 2 Bit für die Zustandsbeschreibung zur Verfügung.

00= unbekannt
01= mögliches Hinderniss (Fernsensor hat ein Echo eingefangen)
10= Rasterzelle ist frei (durch mindestens zwei verschiedene Sensoren oder durchfahren verifiziert)
11= Hinderniss

Später möchte ich mit 3 oder 4Bit arbeiten damit ich bewegliche Hindernisse (Menschen usw) noch mit einem Status für bewegliche Hindernisse versehen kann.
So kann der Roby stark und schwach frequentierte Pfade erkennen und seine Routenplanung entsprechend anpassen.
Bei 265kB Ram komme ich auf 2097152 Speicherzellen, das sind rund 1448 Zellen Kantenlänge. Bei 2cm je Zelle, 28,96Meter.
Was für mein Testgelände mehr als ausreichend ist.
############

[Spyro08]

Ja, also Rasterkarte klingt ja schon mal nicht schlecht.

Ich habe das jetzt so gedacht:
Der µc hat ein Rechteck vorliegen, was zum Beispiel 50*80 Felder groß ist.
Jetzt- um die ganze Geschichte auf verschiedene Umgebungen anzupassen - kann man eingeben:

Feldlänge: 50cm

Jetzt wählt man noch das Feld auf in dem der Robo sicha m Anfang befindet:

Start: Feld1.

Jetzt kann der Robo gerade aus losfahren und immer berechnen in welchem Feld er sich gerade befindet. Fährt er durch das erste Feld durch, wird das z.B. in den EEPROM als 0 geschrieben. Nun ist er in Feld 2 angekommen und stößt irgendwo an --> Feld ist belegt. also kommt eine 1 in den EEPROM. und die Geschichte immer weiter, wo Nullen sind kann der Robo dann also überall lang fahren.
die ganze Messung von Gegenständen soll dann logischerweise über IR oder Ultraschall funktionieren.
Würde dieser Gedanke schon in die richtige Richtung gehen?

Und dann geht das weiter:

Ich will ja nicht gleich zu hoch greifen (was ich wohl gerade mache) aber man könnte dann die 0 und 1 auf einem Touchscreen ausgeben. Nun kann man Feld 10 anklicken und der Robo soll dort hinfahren.

Nun wäre ja noch das Problem einen Gegenstand genau Orten zu können, dazu Folgendes:

Der Gegenstand hat einen Transponder, der Robo logischerweise einen Reader. Jetzt kann man die Reichweite des Readres ja ziemlich gering halten und der Robo fährt so lange im besagten Feld hin und her, bis er den Chip gefunden hat.

Puhh, das war jetzt ganz schön viel.
Ich hoffe ihr schreibt mir ein paar Meinungen dazu, vor allem zum Prinzip der Kartierung, das andere ist ja ersteinmal zweitrangig.
Wäre die Kartierung nach dem Prinzip machbar und gibt es schon irgendwo Infos, wo solche oder ähnliche Kartierungen schon vorgenommen wurden?

mfg

[uwegw]

Hört sich durchaus machbar an. Du brauchst dazu auf jeden Fall eine Wegsteckenmessung per Encoderscheiben an den Rädern, um die gefahrene Strecke genau zu messen.

[i_make_it]

Ein teureres aber dafür ziemlich genaues system zur Wegstrecken bestimmung ist im Roboter einen gedachten Würfel zu legen und an den Flächenmittelpunkten 2-Achs Beschleunigungssensoren anzubringen deren Messachsen parallel zu den Kanten der Flächen sind auf dem er sitzt.
Eigentlich kann der Gedachte Körper auch von dem Seitenverhältnis 1:1:1 des Würfels abweichende Mase haben, dann müssen die Werte der Sensoren halt entsprechend des Strahlensatz ins Verhältniss zueinander gesetzt werden.


Mit dieser Anordnung der 6 Sensoren nimmst du 12 Werte Paralell auf und kannst jede beliebige translatorische und rotatorische Beschleunigung erfassen.
Da sich mit der Beschleunigung über die Zeit die Geschwindigkeit und die zurückgelegte Strecke ermitteln lässt, hast du also somit ein Trägheitsnavigationssystem das alle Probleme wie Schlupf der Räder und schwieriges Gelände umgeht. Bei drehbewegungen deren Mittelpunkt außerhalb des Roboters liegt, hast du in jeder Raumebene mindestens 2 Sensoren die der selben kartesichen Achse zugeordnet sind und durch Strahlensatz lässt sich der Mittelpunkt der Drehung finden.

Die Zellen der Karte würde ich kleiner als den Roboter machen (etwa 1/4 der kleinsten Ausdehnung) sonnst kann es sein das deine Karte eine geschlossene Umzäunung anzeigt obwohl eine Öffnung existiert die groß genug für den Roboter ist.
Da die Karte das Räumliche Gedächtniss deines Roboters darstellt, könnt der Roboter so im Kartiermodus eine Lücke Passieren, aber danach nicht mehr wiederfinden da innerhalb der Zelle ein Hinderniss existiert.

[Spyro08]

Also danke für die Antworten.
Mit schwierigen Gelände habe ich eigentlich kein Problem, da der Robo nur im Haus fahren soll.
Wenn ich Schrittmotoren verwende, bräuchte ich ja eigentlich keine Encoderscheibe, weil ich ja weis um wie viel Schritte und damit Grad und damit wie viel Weg der Roboter zurückgelegt hat. Da ich ja außerdem die Ausgangsposition habe müsste ich mir das an dem Roboter doch eigentlich sparen könne, oder gibt es da noch was, was ich nicht bedacht habe?
Das mit der Feldgröße stimmt, diese müsste wohl kliner als der Robo sein.

das mit dem Würfel bräuchte ich ja im Prinzip ja nicht, wenn ich die Wegstreckenmessung über die Anzahl der Schritte des Motors bestimme.

[i_make_it]

Schlupf und ggf. den Verlust eines Schrittes wirst du nicht feststellen können. Im Gedankenmodell des Robis fährt dieser gradeaus, in der Realität macht er dann eine Kurve. Zusammen mit Rundungsfehlern eventueller Fernsensoren, kann ein Grader Flur so auch mal zur krummen Banane werden.
Schau mal bei
http://www.mapsnrobots.de/slam.html
vorbei, da sieht man schön genau das Problem.

[Spyro08]

Also irgendwie verstehe ich das aber nicht so richtig.
das Encoderrad ist ja im Prinzip auch an der Welle des Motors befestigt und die dreht sich ja eigentlich immer wenn es auch in der Software dreht.
Den Schlupf/Schrittverlust hat man dann doch trotzdem noch nicht bemerkt, mit dem Encoderrad merkt man ja nicht das die Welle sich zwar dreht, aber die Räder nur durchdrehen und der Roboter damit auf der Stelle bleibt.

[i_make_it]

Wie man sehen kann hat dieser Roboter anscheinend einen Hang nach rechts, wodurch die eigentlich graden Wände gebogen kartiert wurden.
Bild hier  
Eine Möglichkeit wäre die eingehenden Daten der Fernsensoren über die Zeit zu sich selbst abzugleichen.
Wenn also ein Fernsensor als Polarkoordinaten ein 80cm langes grades Wandstück erkennt, kann man ca. 20cm weiter das nächste gemessenene Teilstück mit 60cm Überlappung an die vorherige Messung anreihen.

Mann kann auch die selbe Strecke in umgekehrte Richung nochmal kartieren und aus den beiden Karten eine Differenzkarte bilden.

Bild hier  
Da dieses Projekt von Mathematikern und Informatikern stammt,
hat man den Schwerpunkt auf die Fehlerkorrektur mit mathematischen Mitteln gelegt.
D.h. Wenn alle Fehlerminimierungsstrategieen bei der Datenerfassung nicht ausreichend sind, kommt diese Korrektur zum tragen.

Ich habe die Seite nur als Beispiel gegeben, da man schön die möglichen Fehler sehen kann. Natürlich kann man auch versuchen solche Mechanismen zu implementieren.

[Avalerde]

Noch ne Idee die man z.B. für die Entfernungsbestimmung anwenden könne:
Du synchronisiertst per Funk den Roboter mit dem Ziel. Das Ziel sagt dann über Funk ständig: "ich sende jetzt" und sendet im selben Moment ein Ultraschallsignal aus. Der Roboter misst die Verzögerung bis das Ultraschallsignal bei ihm ankommt und ermittelt daraus die Entfernung.

Das ganze kann man auch variieren, z.B. statt Ultraschall mit IR oder UV-Lichtimpulsen. Da könnte der Roboter dann durch die Funksynchonisation die Lichtimpulse rausfiltern die vom "seinem" Ziel(-Sender) kommen und in Kombination mit nem beweglichen, richtungsabhängigen Lichtsensor die Richtung zum Ziel bestimmen (wenn er z.B. auf dem Flur steht uns sich entscheiden muss in welchem Zimmer der Zielsender steht (geht natürlich nur wenn die Zimmertür auf ist)).

[i_make_it]

Sync mit Lichtgeschwindigkeit und Messung mit Schallgeschwindigkeit würde gehen der Laufzeitfehler durch die Ausbreitung des Funksignals ist vernachlässigbar.
Aber Sync mit Lichtgeschwindigkeit und Messung mit Lichtgeschwindigkeit und beides in die selbe Richtung. Da kommt immer als ermittelte Entfernung NULL raus.
Bsp. A sendet einen Sync, da Entfernung A-B unbekannt ist, ist auch die Signallaufzeit unbekannt.
Nach 10ms sendet A das Messignal.

Bei B kommt also ein Sync Signal an und 10ms später ein Messignal.
Informationsgehalt für die Entfernungsbestimmung keiner!

Das ist eigentlich die selbe Falle in die ich getappt bin mit dem DCF77 Signal.
Die Propagation des Referenzsignals bringt ein proportional zur Entfernung wachsendes Delta zwichen A und B.
Abhilfe wären Atomuhren wie bei den GPS Sateliten.

Was geht ist Wenn A ein Signal aussendet und B dieses möglichst ohne Durchlaufverzögerung wieder sendet. hintendrann hängt B halt seine Unique ID. Damit kann man was Anfangen.

A hat als Daten dann:
Timestamp Sendung
Timestamp Empfang
Target-ID

Das entspricht einer Laufzeitmessung mit aktiver Reflektion.
Allerdings bei Signalausbreitung mit Lichtgeschwindigkeit, wird eine Durchlaufverzögerung von 1ns einen Fehler von

300.000km/s
300.000m/ms
300.000mm/Mikro/s
300 mm/ns

ca.150mm in der ermittelten Entfernung ergeben.
Das ist bei einem System das über mehrere Kilometer misst vernachlässigbar. In einem Zimmer mit einem Treppenabgang steht Roby dann aber schon fast zwei Stufen weiter unten, falls er dann überhaupt noch steht und nicht schon rolle rückwärts probt.
Auch das verfehlen einer Tür um 5cm (er denkt halt 10cm Abstand sind genug) bei Voller Fahrt dürfte nicht grade prickelnd sein.

Ein weiteres Handicap ist das der Roby auf eine funktionierende Infrastruktur mit aktiven Barken angewiesen ist. Was einer Autonomie entgegensteht.

Meine Philosophie ist einen Roby möglichst autonom und mit verschiedensten Sensoren für die selbe Aufgabe auszustatten.
Sprich Entfernungsmessung mit UltraSchall und positionsbestimmenden LED Reflektoren, usw.