Positionsbestimmung von Asuro

[julien]

Hallo! Ich stehe vor einem Problem. Und zwar:
Ich möchte die Koordinaten ermitteln, in denen sich der Asuro vom Startpunkt aus (X=0; Y=0) befindet. Ich habe folgendes Programm zur Bestimmung des zurückgelegten Weges des linken- und rechten Rades per Odometrie geschrieben:


//Dieses Programm dient zur Ermittlung des zurückgelegten Weges des linken und rechten Rades.
//zusammengestellt und umgeschrieben von julien

#include "asuro.h"

int main(void)
{
unsigned int Rmin = 1024, Rmax = 0, Lmin = 1024, Lmax = 0, Rmitte = 512, Lmitte = 512, data[2];
unsigned int wegr=0, wegl=0;
unsigned char flagl=FALSE, flagr=FALSE;
Init();
MotorDir(FWD,FWD);
MotorSpeed(100,125);
while(1) {
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;
wegl++;
}
if ((data[0] > Lmitte) && (flagl == FALSE)) {
flagl = TRUE;
wegl++;
}
if ((data[1] < Rmitte) && (flagr == TRUE)) {
flagr = FALSE;
wegr++;
}
if ((data[1] > Rmitte) && (flagr == FALSE)) {
flagr = TRUE;
wegr++;
}
SerWrite("WL: ",4);
PrintInt(wegl); //Ausgabe Weg linkes Rad
SerWrite("WR: ",4);
PrintInt(wegr); //Ausgabe Weg rechtes Rad);
SerWrite("/r/n",2);
}
return 0;
}

Dieses Programm kann man bestimmt noch vielseitig dafür einsetzen (natürlich nur mit ein paar Änderungen). Zum Bestimmen der Koordinaten bräuchte man z.B. noch den Winkel, in dem sich Asuro relativ zum Ausgangspunkt befindet und Formeln, um die Koordinaten zu bestimmen. Naja, ich glaube, dass das nicht so einfach sein wird aber es währe auf jeden Fall mal einen Versuch wert (und nützlich währe es für viele Zwecke auch noch [z.B. virtuelle Landkarte]). Ich würde mich auf Lösungsvorschläge freuen.

MfG julien

[womb@t]

schon beim drehen treten ungenauigkeiten auf, das sieht man zb bei dem wettbewerb ein haus vom nikolaus zu malen!
Das mit koordinaten zu machen wir schwer werden

[pebisoft]

ein compassmocul cmps03 brauchst du unter anderem, ist ein sehr guter sensor. kann ich für die positionsbestimmung zusätzlich empfehlen. die anderen sachen die hier teilweise im forum genannt werden sind ungenau (steppmotor-wegstreckenmessung, irbake , die ir-bake ist immer ein guter ausgangspunkt oder anfahrpunkt um neu zu beginnen, ist aber nicht für die richtungsbestimmung geeignet).
die virtuelle karte ist auch nicht so einfach. ist zur zeit auch mein thema.
dazu setze ich ein : ir-bake im raum plus 2x je ein tsop1736 in einer filmdose mit einem 1mm senkrechten schlitz auf dem robby vorn rechts und links montiert, 2x ultra srf04 je auf servo 180grad schwenkbar, compassmodul cmps03 und cmucam2. klappt ganz gut. du siehst aber auch, was man alles für sensoren braucht um diesen traum einigermassen zu verwirklichen. und diese sensoren kann der kleine nicht alle verdauen, sei es gewichtsmässig nicht und pinanzahlmässig nicht.
mfg pebisoft

[Winne]

hi,

ich bin ebenfalls dabei eine Virtuellekarte zu "zeichen". Die Auswertung bei der Odometrie ist im Augenblick der Schwerpunkt. Mit einem Testprogramm versuch ich einen Weg zu finden, wo die Odometrie halbwegs funktioniert.
Falls interesse besteht kann ich das Programm posten. Die Beschreibung müsste ich aber erstmal überarbeiten.

Gruss Winne

[julien]

Ja, das mit der Odometrie hab ich ja schon in den Griff bekommen (geht bei jedem Umgebungslicht [siehe obriges Programm]). Bloß das mit der virtuellen Landkarte fehlt mir, wie man das realisieren kann. Währe schön, wenn du mir da weiterhelfen könntest.

[Winne]

Hier ist ein Link, der einen interessanten Ansatz liefert.

http://www.mindrobots.de/public/algorithms/sosmar.pdf

Gruss winne

[pebisoft]

das wird der asuro nicht verkraften. da baut euch man eine gössere plattform und verwendet dafür die erworbenen kenntnisse vom asuro.
mfg pebisoft

[julien]

Ich meine ja nur mit Hilfe der Odometrie. Mein Programm oben macht das doch ziemlich genau. Man müsste nur mit den Wegstrecken der Räder die Position bestimmen können, bloß mir fällt da kein Algorithmus für eine einfache zweidimensionale virtuelle Karte ein. Weiß jemand, wie das geht?
MfG julien

[julien]

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);
}

[Rakke]

Hei Julien,

Posistionsbestimmung über Odo interessiert mich auch. Eine Odo habe ich noch nie geschrieben, ich stelle es mir ungefähr so vor: Position vom Asuro ist darstellbar als x,y,phi (Verdrehung)

Odo_li und Odo_re vergleichen
wenn gleich: Stückchen gradaus gefahren, also letzte Position verschieben, Verdrehung gleich halten
wenn unterschiedlich: Bogen gefahren; Radius und Mittelpunkt des Bogens ermitteln, letzten Punkt verschieben, Verdrehung aktualisieren


Zugegeben etwas theoretisch - habs halt noch nicht gemacht. Ich schätze, die Tücke liegt im Detail: die Rechnerei stinkt förmlich nach trigonometrischen Funktionen ((arc-)sin, cos, tan), das wird den kleinen Asuro-Prozessor ganz schön fordern.

Es sei denn... jemand hat eine bessere Idee? Habe noch nicht in den Weiten des Internets geforscht.

Was soll denn eigentlich 'rein in deine Karte? Der Link von Winne zeigt jedenfalls mal, was man mit geschickten Karten alles erledigen kann...Respekt!

Gruß Rakke

[julien]

Hallo! Schön, dass es doch noch welche gibt, die sich dafür interessieren :-)
Ich dachte da an eine virtuelle Karte, wo alle x- und y-Koordinaten aller Hindernisse stehen. Er soll dann nicht mehr in die Nähe dieser Objekte fahren. Diese soll dann evtl. z.B. im Hyperterminal ausgegeben werden (frag mich aber nicht, wie).
MfG julien

[Vogon]

Schön, dass es doch noch welche gibt, die sich dafür interessieren.

Und ob es noch welche gibt dies interessieren ! :-s
Ich geb ja zu, das ich bisher zu faul war damit anzufangen. :oops:
Aber es ist schön, das es jetzt jemand versucht. :cheesy:

[julien]

Wie viel schluckt der Speicher von Asuro denn überhaupt? Die .hex-Datei ist ca. 11KB groß (wegen der math.h)

[Vogon]

Ich habe schon Programme mit 90 Pages geladen.
Die Länge der .hex sagt nur indirekt etwas über die wirkliche Programmlänge aus. Die Datei wird erst von einem Loader in das ausführbare Programm umgebaut und im Speicher abgelegt.
http://ece.wpi.edu/courses/ee4801/suppnotes/hex/hexfile.html

[Solarisfx]

Ich interessiere mich auch für dieses Problem, da ich ja etwas ähnliches benötige um die, in meinem Thread beschriebenen, Szenarien erfüllen zu können.

Falls der Speicher bzw die Rechenkapazität nicht ausreicht könnte man evtl einen anderen Prozessor inclusive Speicher dem Prozessor des Asuro vorschalten - also Coprozessor sozusagen. Da ließe sich sicherlich etwas basteln ;)

[julien]

Aber der Speicher von Asuro wird schon ausreichen. Immerhin sind 7KB eine ganze Menge (für Text/Code zumindest). Aber nun stellt sich noch die Frage zum Berechnen der aktuellen Position, ausgehend von der Startposition (0,0). Ich brauche doch "nur" die X-und Y-Werte.

[Rakke]

Hei,

habe grad bei einer schnellen Googlei zwei Grundlagenseiten gefunden:
http://www-ti.informatik.uni-tuebingen.de/~ihlenbur/studienarbeit/studienarbeit.pdf
und
http://fbim.fh-regensburg.de/~saj39122/Diplomarbeiten/ReschReif/quellen/diplomarbeit.pdf

In beiden wird die Grundlage für die Odometrie dargestellt, in der ersten anschaulicher (meine Meinung ...). Jetzt geh' ich mal zum Sport und überleg, wie wir dem armen Asuro die sin und cos ersparen können.

Alaaf!
Rakke

[stochri]

Zum warmmachen könntet Ihr ja ma. das Haus vom Nikolaus fahren.
Die Grundidee ist dort, nach mehren gefahrenen Wegstrecken und Drehungen des Roboters wieder am Ausgangspunkt anzukommen. Und sowas ist denke ich mal die Voraussetzung für eure Positionsbestimmung.
Wenn man einen Stift an den Roboter bastelt, kann man auch gleich sehen, welchen Weg er fährt.

https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=10291&highlight=haus+vom+nikolaus

Gruss,
stochri

[julien]

Naja, das mit dem Haus vom Nikolaus ist zwar schön und gut, aber das bringt uns nichts, um die X-und Y Koordinaten relativ zur Startposition zu bestimmen. Ich habe mir da mal etwas anderes einfallen lassen (siehe Bild).

[Solarisfx]

evtl könnte man die Qualität der Odometrie erhöhen, indem man die Schwarz-Weiß-Markierungen auf den Rädern erweitert. Sozusagen aus 4 z.B. 8 macht. Dies wird auch in der Asuro Anleitung angedeutet.

[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.

Hallo Rob_ert,
wenn das alles so "klar" wäre, hätte Julien bestimmt nicht versucht in seinem Programm über 2.000 Byte Variablenspeicher im RAM des ATmega8 Mikrocontrollers anzulegen. Aber das ist mir schon mehrfach hier im Forum aufgefallen. Da machen sich Leute Gedanken über die komplexesten Mikrocontroller-Software-Lösungen, besitzen aber kein, zur Programmierung des verwendeten Mikrocontrollers unbedingt erforderliches, Basiswissen. Dein Spruch "Etwas Inlineassambler zur Optimierung der Platznutzung dürfte aber angebracht sein..." bestätigt genau das von mir in diesem Beitrag gesagte. Welcher Zusammenhang besteht denn zwischen Inline-Assembler-Programmierung und der Größe des dem Software-Entwickler zur Verfügung stehenden RAM zur Speicherung von Variablen?! Siehst du, genau das meine ich. Also erst den Kopf einschalten und genau überlegen!
Was machst du denn mit deiner im RAM abgelegten "Umgebungskarte" wenn die Versorgungs-Spannung für den Mikrocontroller ausgeschaltet wird?! Willst du etwa jedesmal beim Programmstart dein "Zimmer" neu vermessen? Bevor man also ein solches Programm schreibt, sollte man sich überlegen, wo speicher ich die Daten meiner Karte und wieviel Speicher steht mir dafür zur Verfügung ( EEPROM, Flash ...). Deshalb muss man auch das Basiswissen über den verwendeten Mikrocontroller besitzen! Z.B. kann der ATmega8 auch Daten im Programm-Flash speichern (Bootloader). Aber anscheinend ist das für dich ja alles kein Problem. Dann zeig uns doch mal ein Beispielprogramm von dir, wie man das Problem von Julien lösen könnte!

Gruß, Peter

[julien]

Hi! Um die Genauigkeit der Odometrie zu erhöhen, könnte man das so modifizieren, wie das auf http://asuro.pytalhost.de/pmwiki/pmwiki.php?n=Main.OdometrieModifikation beschrieben wird.

Ich möchte das so haben, dass wenn Asuro irgendwo gegenfährt (Fahrstrecke zufällig gewählt), er nicht beim nächsten mal wieder in die Nähe des Objekts (Umkreis: ca. 20cm?) fährt sondern gleich weiß, dass dort was ist und ausweicht.
Ich müsste bloß erstmal ein Beispielprogramm haben, womit man die x- und y-Koordinate auf einem Zweidimensionalen Feld mithilfe der Odometrie ermitteln kann. Der Nullpunkt sollte dort sein, wo der Roboter das erste mal gegenfährt.

MfG julien

[McKay]

Hallo zusammen

Ich möchte auch gerne etwas zu diesem Thema beitragen.

Da ich jedoch meinen Asuro noch gar nicht habe und auch neu in dieser Materie bin, bitte ich aber um Nachsicht, falls ich in die falsch Richtung denke.

Ich sehe, dass der Asuro relativ begrenzte Fähigkeiten hat und somit die Positionsbestimmung mittels selbsterzeugter Karte schon eine hohe Herausforderung für diese einfache Hardwareplattform darstellt.

Ich stimme zu, dass man hierbei sinnvollerweise nur die Odometrie auswertet, auch wenn sich dadurch Ungenauigkeiten zB. durch Schlupf ergeben.

1KB RAM sind sehr knapp für eine solche Anwendung, da hier noch der Stack abgeht, so dass man für die Karte deutlich weniger als 1KB hat, was entweder eine grobe Rasterkarte oder eine simple Vektorkarte ergibt.

Als Alternative könnte eine PC-seitige Unterstützung des Asuro erfolgen, so dass der Asuro lediglich die gemessene Odometrie an den PC übermittelt und dieser alle Berechnungen und Auswertungen macht und somit der PC letztendlich den Asuro steuert.

Dies bedingt aber eine unterbruchsfreie Kommunikation zwischen PC und Asuro (kontinuierlicher Sichtkontakt) und es ist zu berücksichtigen, dass die Informationen nur mit 2400 Baud übertragen werden können und entsprechend knapp gehalten werden sollten. Aber insbesondere der kontinuierliche Sichtkontakt kann nicht sichergestellt werden wegen den zu erwartenden Hindernissen (zB. Tischbeine) in der zu erforschenden Umgebung, so dass der Asuro eine begrenzte Zeit auch ohne Komumikation auskommen muss, also eine entsprechende Eigenintelligenz benötigt (zB. Daten sammeln und später übermitteln und ggf. zum letzten Kommunikationspunkt zurückkehren)

Für solche Erkundungsmissionen sollte der Asuro aber generell mehr Sensoren haben.
Mein Vorschlag wäre, hierfür die 6 Kontaktsensoren auf 2 zu reduzieren und die restlichen 4 Signaleingänge für andere Sensoren zu verwenden.

Für eine zuverlässige Kollisionserkennung reichen 2 Kontaktsensoren.
Vor die Schalter K2 und K5 (die welche direkt nach vorne gerichtet sind) wird eine federgelagerte gerade Stosstange montiert.
Bei einem Frontalzusammenstoss werden beide Kontakte (K2 & K5) ausgelöst.
Bei einem Hinderniss auf der linken Seite, wird nur K2 ausgelöst und auf der rechten Seite nur K5. Somit wird eine Kollision zuverlässig erkannt und wir haben nun 4 Signaleingänge zur weiteren Verwendung.

Diese 4 Signalleitungen könnte man für Frühwarnsensoren einsetzen, so dass ein Hindernis erkannt werden kann, bevor es kracht.
Hierfür eignen sich Ultraschallsensoren, aber da wir nur Schaltsignaleingänge haben (1 oder 0), müsste hier eine fixe Distanz eingestellt werden, bei der ein Hindernis angezeigt wird (zB. 10cm)

Die Ultraschallsensoren ordnet man so an, dass 2 direkt nach vorne gerichtet sind (ähnlich wie Autoscheinwerfer) und je einer nach links und nach rechts, so dass der Asuro erkennen kann, ob er überhaupt nach links oder rechts abbiegen kann. Die seitlichen Ultraschallsensoren werden hierfür im vorderen Bereich montiert, so dass bei der Erkennung, dass kein seitliches Hindernis mehr vorhanden ist, der Asuro noch eine Fahrzeuglänge weiterfahren muss, bevor er dann die Richtung ändern kann.

Hierbei sei auf das Programm "AI-Wars The Insect Mind" hingewiesen, wo man einen Kampf-Käfer programmiert und ähnliche Scantechniken zum Einsatz kommen.

Interessant wäre beispielsweise auch eine Kantenerkennung, so dass der Asuro, bei entsprechender Programmierung, nicht mehr die Treppe runterfällt.

Hierfür könnte man die Linienfolgeeinheit umbauen. Die Fähigkeit einer Linie zu folgen ist zwar ganz nett, aber zu erkennen wenn man auf einen Abgrund zufährt, ist doch etwas wichtiger.
Die entsprechenden Tiefensensoren müssten soweit links und rechts aussen positieniert werden, so dass der Asuro gefahrlos an einer Kante entlangfahren kann, ohne herunterzufallen.
Wenn nur ein Tiefensensor anspricht, kann der Asuro einfach seine Fahrtrichtung anpassen (stoppen, Richtung korrigieren bis Tiefensensor nicht mehr anspricht und weiterfahren) und wenn beide Tiefensensoren ansprechen gilt Alarmstufe rot (stopp, in zufällige Richtung drehen, bis beide Tiefensensoren nicht mehr ansprechen und weiterfahren).

Da die Liniensensoren offenbar abgestufte Signalwerte erfassen können, wäre es wohl sinvoller, diese für distanzmessende Ultraschallsensoren zu verwenden und die einfachere Kantenerkennung (Boden oder kein Boden) über die Kontaktsignaleingänge zu machen.

Sobalb wir eine Distanzmessung durchführen können, kann der Asuro beim Start einfach mal eine 360° Drehung machen und mit den gemessenen Distanzinformationen bereits schon seine erste Karte erstellen.

Mit einer solchen Sensorenausstattung sollte der Asuro fähig sein, seine Umgebung gefahrlos zu erforschen und zu kartografieren.

[Pitchriddick]

Wieso stürtzt bei mir WinAVR Studio 4 ab, wenn ich beispielsweise math.h oder std.lib einsetze ?

Help

[ogni42]

Ist irgendein Release-Problem. Neuestes AVRStudio (SP 4) und neueste WinAVR verwenden. Dann sollte das gehen.