Positionsbestimmung von Asuro

[Vogon]

Ich habe auf meinem Asuro schon Scheiben mit 12 Feldern. (6*S+6*W) Mehr wird ohne Umbau der Optischen Teile nicht gehen.

Im Buch "Mehr Spaß mit ASURO Band I" ist ein Umbauvorschlag. Die Leuchtdioden und Fototransistoren beim Motorritzel einlöten und die Geberscheibe auf das Motorritzel kleben. Dadurch erhält man fünfmal mehr Impulse pro Reifenumdrehung.

[Rakke]

A propos Odometrie - da würde ich vorschlagen, die weja/stochri-asuro.c zu verwenden - die "mit dem Interrupt". Da bekämen wir wohl zumindest die Tix sauber geliefert. Hardwareseitig werde ich zunächst mal mit dem Original-Asuro-Setup starten.

Alaaf,
Rakke

[No5]

Ich hab jetzt ein Programm geschrieben. Das war ein Haufen Arbeit. Ich hoffe, dass es vom Prinzip her funktionieren würde. Ich weiß nicht, woran der Fehler liegt. Die Status LED flackert nur, daher behaupte ich, dass da ein Fehler im Programm sein muss.

#include "asuro.h"
#include <math.h>
int main(void){
	float w=0,r=0,puls=1;
	unsigned int obj=0, objx[500], objy[500], Rmin = 1024, Rmax = 0, Lmin = 1024, Lmax = 0, Rmitte = 512, Lmitte = 512, data[2], wegr=0, wegl=0, richt=1, x=0, y=0, i=0; 
    unsigned char flagl=FALSE, flagr=FALSE, eingetr=FALSE;
	Init();
   DDRD |= (1 << DDD1);      // Port D1 als Ausgang 
   PORTD &= ~(1 << PD1);      // PD1 auf LOW 
   puls = 1;
	while(1){
	      if (PIND & (1 << PD0)){
         StatusLED(GREEN);   // kein Hindernis
		 } else {
		if(eingetr==FALSE){
		objx[obj]=x;
		objy[obj]=y;
		obj++;
		eingetr=TRUE;
		}
		richt=2;
		StatusLED(RED);      // Hindernis erkannt
		}
   puls = 1.02 * puls;      // Pulsbreite wird um 2% erhöht 
   if (puls > 10){
   if (PIND & (1 << PD0)){ richt=1; eingetr=FALSE; }
   puls = 1; }
   OCR2 = 255 - (int)(puls);
	if(richt==0) MotorDir(BREAK,BREAK);
    if(richt==1) MotorDir(FWD,FWD);
    if(richt==2) MotorDir(BREAK,FWD);
    MotorSpeed(150,150);
	
	for(i=0;i<=obj;i++){
	if((x<=objx[i]+10) && (y<=objy[i]+10)) richt=2;
	}
//-----------------------Schritte zählen-----------------------------------
	  OdometrieData(data); // 0. links, 1. rechts
        // max links
        if (data[0] > Lmax)
            Lmax += (data[0] - Lmax) / 2; 
        // min links 
        if (data[0] < Lmin)
            Lmin -= (Lmin - data[0]) / 2;
        // max rechts
        if (data[1] > Rmax)
            Rmax += (data[1] - Rmax) / 2;
        // min rechts
        if (data[1] < Rmin)
            Rmin -= (Rmin - data[1]) / 2;
         Rmitte=(Rmax+Rmin)/2;
         Lmitte=(Lmin+Lmax)/2;
      if ((data[0] < Lmitte) && (flagl == TRUE)) {
      flagl = FALSE;
      }
      if ((data[0] > Lmitte) && (flagl == FALSE)) {
      flagl = TRUE;
      wegl++;
      }
      if ((data[1] < Rmitte) && (flagr == TRUE)) {
      flagr = FALSE;
      }
      if ((data[1] > Rmitte) && (flagr == FALSE)) {
      flagr = TRUE;
      wegr++;
      }
//------------------------------------------------------------------------
//------------------------POSITIONSBESTIMMUNG-----------------------------
w=1.607143*(wegl-wegr); //winkel
r=((wegl+wegr)/2)*w;
x=(int)(r*cos(w));
y=(int)(r*sin(w));

	}
	return(0);
}

@Julien
Also bei mir funktioniert das Programm hab es mal getestet. Allerdings weiß ich nicht ob es richtig ist.
Mein Asuro dreht sich in einem relativ großen Radius nach rechts trifft er auf ein Hinderniss bleibt sein rechter motor stehen und er dreht nur noch nach links. Wenn er ein Hinderniss erkennt blinkt die Status Led rot aber er ändert sein verhalten nicht mehr. Hoffe es konnte Dir etwas weiterhelfen.
Gruß Dom

[blade]

Die Positionsbestimmung hinkt etwas mit den bisher genannten Vorschlägen. Denn wenn der Untergrund z.B. glatt ist drehen sich die Räder, aber er fährt trozdem nicht den Weg den er soll. Und nun ist der angestrebte Weg schon nicht mehr richtig! Ich arbeite mich gerade in die Thematik, falls ich falsch liege bitte verbessern!

[DLArts]

Die Positionsbestimmung mit unkorrigierten Odometriedaten ist in der Tat sehr ungenau, wenn man nicht gerade eine in einer gut gewählten Testumgebung fährt.

Das hängt mit meheren Problemen der Odometrie zusammen :

1) Man geht in der Regel von 2D-Koordinaten aus, die reale Welt ist aber nunmal 3D. Das Problem ist nun, das in den allermeisten Bodenbelägen kleine Unebenheiten sind, kleine Dellen oder Hügel, und schon stimmt der wirklich gefahrene Weg nicht mit dem angeblich gefahrenen Weg überein.

2) Selbst bei einem absolut planen Untergrund, kommt es vor, das Räder z.B. durchdrehen. Bei Teppich als Untergrund, kann es passieren dass der Roboter durch Muster im Teppich leicht abgelenkt wird etc.
Das sind zumeist recht kleine Fehler aber die addieren sich schnell auf und die angenommene Position weicht schnell von der tatsächlichen Position ab.

3) Letzendlich machen die Odometriesensoren natürlich auch kleine Messfehler, selbst bei absolut perfekten Testbedingungen, die sich auch im Laufe der Zeit aufaddieren.

Um also mit Hilfe Odometrie gute Positionsbestimmungen zu gewinnen, muss man die Odometrie korrigieren.
Dies kann auf unterschiedlichste Weisen geschehen. Am besten man hat natürlich eine Karte vorgegeben und man kann den aktuellen Scan von z.B. Laser-Scans oder Ultraschall-Scans in die Karte einpassen und gucken wo diese am ehesten zutreffen.
Wenn man keine Karte hat, kann man den aktuellen Scan mit einigen wenigen voherigen Scanns vergleichen und versuchen den Fehler zu schätzen. Ist aber alles relativ aufwändig und benötigt viel Rechenzeit, um es in Echtzeit berechnen zu können.

[julien]

Ok, dann wird das mit den Odometriesensoren wohl doch nichts. Was könnte man noch verwenden, um eine sogenannte "virtuelle Karte" im Speicher des Roboters erstellen lassen zu können?

[Rob_ert]

Hi,

ich würde die Odometrie noch nicht ganz aufgeben. Richtig gute Ergebnisse wirst Du aber nur erzielen können, wenn Du die Odometrie mit anderen Daten korrigierst.

Die teure Methode wäre andere Sensoren (Kompassmodul) einzubauen und die Daten gegeneinander abzugleichen.

Preiswerter: Du lässt den Roboter fahren bis er einen bestimmbaren Punkt erreicht (z.B. bis er an ein Hindernis stösst). Diesen Punkt nimmst Du als Nullpunkt. Von da aus fährst Du los und erstellst per Odometrie Deine Karte.
Und nun der Trick: Um die Probleme der Odometrie zu umgehen fährst DU nun kurze Strecken und anschliessend wieder zum Ausgangspunkt zurück. Jede Strecke fährst Du mehrfach und jede neue Strecke ist nah an der vorherigen. Ergebnis: Bei den mehrfachen Fahrten werden sich die Ungenauigkeiten der Odometrie immer verschieden auswirken. Du must also den Durchschnitt der einzelnen Messungen nehmen und hast dann eine recht genaue und korrekte Umgebungskarte.

Etwas Rechenarbeit aber schaffbar.

Übrigens vermute ich, dass es für den kleinen Prozessor einfacher wird, wenn Du die Richtung nicht als Winkel angibst um dann mit Winkelfunktionen zu arbeiten, sondern lieber als ein normierten (in x/y-Anteil zerlegten) Vektor und dann mit Vektorrechnung drangehst. Ist mathematisch das gleiche, aber für den Prozessor sollte es wesentlich schneller zu rechnen sein.

Ihr solltet euch, bevor ihr ein solches Programm schreibt, über die vorhandene Hardware sprich vorhandenen Speichermöglichkeiten ein paar Gedanken machen. Wo soll den der im ASURO vorhandene ATmega8 Mikrocontroller bitte eure Datenmengen abspeichern?

float w= 4 Byte
r= 4 Byte
puls= 4 Byte

unsigned int obj= 2 Byte
objx[500] = 1000 Byte
objy[500] = 1000 Byte
Rmin = 2 Byte
Rmax = 2 Byte
Lmin = 2 Byte
Lmax = 2 Byte
Rmitte = 2 Byte
Lmitte = 2 Byte
data[2] = 4 Byte
wegr= 2 Byte
wegl= 2 Byte
richt= 2 Byte
x= 2 Byte
y= 2 Byte
i= 2 Byte

Summe: 2.042 Byte!!!!

Der ATmega8 verfügt über 1K Byte RAM. Variable werden bekanntlich im RAM gespeichert. Zusätzlich ist bei der Vergabe von RAM-Speicher zu berücksichtigen, dass der Mikroprozessor im Mikrocontroller zur Speicherung von Rücksprungadressen usw. einen s.g. Stack-Bereich im RAM benötigt! Also erst Kopf einschalten, rechnen dann schreiben!

Gruß, Peter

Na ist doch klar, dass man mit dem kleinen Prozessor keine bunten 3D-Landschaften abspeichern kann. Aber unter einer Umgebungskarte musst Du ja nicht gleich das Verstehen, was der Mensch sich in seinem Kopf bildet. Hier reicht als "Umgebungskarte" doch ein Verzeichnis der Hindernisse, also Punkte und Linien an denen der Roboter anstößt. Für diese Punkte reicht es die x und y Koordinbate zu speichern. Bei einigermaßen passender Genauigkeit also vier Byte pro Geländepunkt. Bei Linien (Wände) käme noch die Richtung und Länge hinzu.

Mit anderen Worten: Der Speicher kann durchaus reichen um ein Zimmer zu kartographieren.
Etwas Inlineassambler zur Optimierung der Platznutzung dürfte aber angebracht sein.

[Rob_ert]

Sorry, vergaß mich einzuloggen. Letzter Beitrag ist von mir.