-
-
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
-
Hi! Um die Genauigkeit der Odometrie zu erhöhen, könnte man das so modifizieren, wie das auf http://asuro.pytalhost.de/pmwiki/pmw...ieModifikation 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
-
Neuer Benutzer
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.
-
Neuer Benutzer
Öfters hier
Wieso stürtzt bei mir WinAVR Studio 4 ab, wenn ich beispielsweise math.h oder std.lib einsetze ?
Help
-
Erfahrener Benutzer
Roboter Genie
Ist irgendein Release-Problem. Neuestes AVRStudio (SP 4) und neueste WinAVR verwenden. Dann sollte das gehen.
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
-
Foren-Regeln
Lesezeichen