Archiv verlassen und diese Seite im Standarddesign anzeigen : Suche C-Control Quellcode für Roboter Navigation
Hi Leute,
hat es von euch schon mal jemand geschafft die Navigation eines Bot´s so zu programmieren das er nu wirklich in einem Zimmer mit vielen Möbeln nirgends hängen bleibt? Bei mir gibt es immer Stellen wo er links und rechts auf ein Hinderniss trifft und dann irgendwie in der Falle sitzt.
Ich nutze die üblichen Sensoren mehrere IS471 vorne und an der Seite.
Wäre schön wenn mal jemand etwas dokumentierten Code dazu postet. Kann ja jeder dann entsprechend anpassen.
Die Aufgabe wäre, das der Bot in etwa die Zimmermaße berechnet!
Hi!
Quellcode für´s C-Control kann ich dir leider nicht anbieten. Ich habe allerdings ein kleines Programm in Delphi geschrieben, das einen Roboter simuliert, der Hindernissen ausweicht. Du kannst dabei die Reichweite der Sensoren und deren Winkel einstellen. Die Navigation basiert auf dem A*-Algorithmus. Ich will selber mit dem Roboterbau anfangen und hab deshalb erstmal ein Programm geschrieben, um zu schauen, wie die Sensoren aussehen müssen etc. Sag einfach bescheid, wenn´s dich interessiert.
Gruß,
miho
Mich interessiert es brennend! Ich baue grade an einer Kollisionserkennung und dem Ausweichen von Hindernissen. Allerdings würde mir eine beschreibung in Worten oder Pseudo-Code ebenfalls reichen, da ich Delphi nicht kann :)
Oh ja, interessiert mich auch. Könntest Du es vielleicht hier als Anhang posten?
Hi!
Ja, das ist immer so ne Sache, wenn man die Programmiersprache net beherrscht, dann ist es immer schwierig was zu verstehen. Es gibt ein sehr einfaches englisches Tutorial zu dem Thema. Hier der Link:
www.policyalmanac.org/games/aStarTutorial.htm.
So jetzt zum Programm:
Ziel ist es eine Robotersteuerung für den PC zu realisieren. Da ich vorhabe einen größeren Roboter zu bauen, pack ich da gleich ein Notebook mit rein. Da die meisten Roboter nur über IR etc. und weniger per Kamera "sehen", werden oft sehr einfache Suchalgorithmen verwendet. Nachteil bei komplizierteren wie A* usw. ist, dass immer eine Karte der Umgebung vorhanden sein muss. Nicht immer ist man in der Lage seinem Roboter die Info´zu liefern. Meine Wohnung ist z.B. ein einziges Chaos und dafür eine Karte anzufertigen stell ich mir ziemlich schwierig vor*g*
Ich will also eine Steuerung realisieren, bei der der Roboter sich die Karte selbst erstellt und auch Änderungen in der Umgebung registriert. Soweit ist mein Programm aber noch nicht. Man sollte es ohne Probleme an eine Motorsteuerung anschliessen können. Die müsste nur Befehle wie "drehe nach links/rechts" und "fahre geradeaus" verstehen. Die Karte würde dann proportional zur Umgebung angefertigt. Also eine genaue Positionserkennung entfällt dann (weitestgehend).
Mit der Elektronik kenne ich mich aber noch gar nicht aus. Hat da jemand Vorschläge?
Ein paar Erklärungen:
Zum Starten der Simulation einfach auf "Start" klicken.
Mit der rechten Maustaste könnt ihr Ziele angeben (Warcraft-like). Es können auch mehrere Ziele angegeben werden.
Mit der linken Maustaste lässt sich der Roboter positionieren.
Die zwei Linien am Roboter sollen IR-Sensoren sein.
Der Rest ist ziemlich selbsterklärend.
Ich beschäftige mich erst seit ein paar Tagen mit dem Thema und das Programm ist dementsprechend noch nix besonderes und auch "buggy". Falls ihr Fragen habt, fragt! Verbesserungsvorschläge sind immer willkommen!
Schaut´s euch einfach mal an :)
Gruß,
miho
P.S: Hab grad gemerkt, dass ich das Proggy nicht anhängen kann, da es 278 KB groß ist (gezippt) :( Was mache ich jetzt? Gibts da noch andere Möglichkeiten (bin ganz neu hier im Forum)?
So große Datenmengen können derzeit nur Moderatoren und Supporter anhängen! Bei Mitgliedern geht glaub nur 70 KB derzeit.
Wenn Du möchtest das ich Prg. in den DOwnload Bereich stelle kannst Du Datei aber an mich webmaster@roboternetz.de senden.
Gruß Frank
Yeah, hoffentlich is das Programm bald aufm Server!
Datei ist nu auch im Download Bereich
@HiTech: Also ob sich der A* mit dem C-Control realisieren lässt, weiss ich nicht. Ich kenn mich mit Mikrocontrollern zwar (noch) null aus, aber soweit ich weiss, ist das C-Control ziemlich langsam. Das läuft doch mit Interpreter, oder?
Naja langsam ist relativ.
Ja sie läuft mit Interpreter. Dadurch ist aber die Programmierung (gerade für Einsteiger) einfach.
Kommt darauf an, was du machen willst.
Für einen langsamen Roboter reicht sie alle mal.
AUßerdem kann man sie ja ohne größeren Aufwand von 4 auf 10MHz übertakten (hat Conrad ja selber gemacht).
Dann ist sie auch für echtzeitanwendungen ganz gut gerüstet.
@ACU:Das war nur(!) auf den A*-Algorithmus bezogen. Der braucht nämlich relativ viel Rechenkapazität.
Ich kenne mich mit diesem A*-Alogrithmus nicht aus.
Ich werde mich wohl mal informieren.
Wenn man viel Rechenkapazität und Speicherkapatzität braucht, kann man die CC1 natürlich vergessen.
Die kann man mit vielen Abfragen schon ganz schön ins schwitzen bringen.
Mit dem 24 Byte der C-Controll wird man da wohl nicht hinkommen, da man im Prinzip eine Art Karte im RAM ablegen muss....
Hi!
Ich hab mein Proggy mal ein bischen verbessert und die Simulation etwas den Realbedingungen angepasst. Der Roboter erstellt jetzt selbständig die Karte. Man kann die interne Karte mit "interne Karte löschen" zurücksetzen oder auch automatisch erstellen lassen über "int. Karte von Vorlage". Ausserdem hab ich noch ne Funktion integriert, die überprüft, ob der Roboter sich immer im Kreis dreht oder über die selben Stellen fährt. In diesem Fall wird eine neue Wegsuche gestartet. Was man machen müsste, um das Programm für einen realen Roboter zu verwenden wäre folgendes:
1. Die Prozeduren "move_straight_on","move_right" und "move_left" so erweitern, dass ein entsprechender Befehl an eine vorhandene Motorsteuerung geht.
2. Die Funktionen "sensory_organ", "sensory_organ_right" und "sensory_organ_left" so ändern, dass statt der Bitmapkarte der Zustand der realen Sensoren abgefragt wird und als Booleanwert der Funktion überwiesen wird.
3. Die Parameter für die Geschwindigkeit des Roboters mit der Motorsteuerung abgleichen. Daraus ergibt sich der Massstab der Karte.
Also im Wesentlichen nur ein bissl Code dranhängen.
Wie gesagt, ich hab leider noch keine Ahnung von der Motorsteuerung, aber ich fänd´s klasse wenn das mal jemand ausprobieren würde :D
Gruß,
miho
Ach ja, die neue Version gibt´s hier:http://www.michaelhoffer.de/Programmierung/AI-simu/A.I.-Simu.zip
Im Downloadbereich ist nu auch aktueller Link auf Deine Datei! Somit mußt Du nur neue Version auf deinem Server legen damit diese auch hier geladen werden kann
@Frank: Cool, das vereinfacht das ganze ziemlich :) .
Der Bot sollte mittels US/IR Sensoren eine Karte seiner Umwelt erstellen können, r=50cm etwa. Das wäre insofern praktisch, da er dann nicht mittels Trial'n'Error immer erst ne menge wege probieren muss, sondern die unmittelbare umgebung sieht. einer nen vorschlag zur realisierung? ;)
Das wäre natürlich ideal! Aber ich denke, da gibt´s noch einige Probleme zu lösen. 50 cm sind nicht viel. Der Roboter kann also nur ganz nahe Objekte erkennen. Zur Wegplanung brauchts aber auch Objekte, die möglicherweise weiter weg sind. Die können nämlich die Wegplanung deutlich beeinflussen und das Ergebnis wäre von dem "normalen" Trial 'n Error kaum zu unterscheiden.
Trotzdem, eine Möglichkeit wäre vielleicht einen Sensor wie ne Art Radar um 360° zu drehen und dadurch einen Rundumblick zu haben. Wenn es realisierbar wäre, vielleicht 80cm - 1m Reichweite hinzubekommen, dann könnte man damit vielleicht was erreichen.
Es gibt noch ne Möglichkeit für alle, die C/C++ programmieren (zu denen gehör ich leider nicht :( ). Vielleicht wird das ganze ein bischen Off-Top, aber egal. Für Bildverarbeitung und Objekterkennung gibt´s eine Open-Source-Bibliothek von Intel (OpenCV). Damit kann man so ziemlich alles machen, von einfacher Bildmanipulation über 2D-Objekterkennung bis hin zu 3D-Bilderfassung.
Gruß,
miho
Ich kann schon fortgeschrittenes C++, aber ich hab hier nicht die nötige HW :(
So eine Art Radar war auch mein gedanke. 4 US Sensoren, je 90° Winkel. Dann dieses "Radar" einfach immer 90° hin- und herbewegen (Servo etc) und für jeden Punkt schauen, ob US anspricht oder nicht.
Ahh ja, man sollte natürlich jeweils 2US Sensoren so wie "Augen" anordnen, um irgendwie die Tiefe zu erhalten. Macht schon 8x US :)
Als zweites Problem kommt dann natürlich noch die Genauigkeit der Steuerung, der Bewegungen. Das ist in der Theorie immer recht gut zu lösen, aber in der Praxis sieht es manchmal anders aus. Selbst mit Schrittmotoren hat man manchmal das Problem das nicht registrierte kleine Hindernisse (Bodenwölbung oder Teppichrand) die Positionsgenauigkeit erheblich reduziert.
Zudem muß hat glaube eine Karte nur dann ein Nutzen wenn der Roboter genügend Raum hat. Ich denke bei einem recht zugestellten Zimmer wo er sich kaum bewegen kann, da wird es auch mit Karte schwierig.
Wenn du eine gute Distanzgenauigkeit garantieren kannst und du wirklich die Tiefe jedes Punktes hast bei einer super Auflösung und und und...
Ich will aber nicht derjenige sein, der das programmiert :D
@gast: Prinzipiell ist, finde ich, die Navigation nach Karte ziemlich sinnvoll. Gerade wenn der Roboter sich durch ein Chaos von Objekten wurschteln soll, gibt´s, denke ich, kaum eine Alternative.
Entscheidend ist die Auflösung, mit der die Karte erstellt wird. So kommt es auch nicht auf ein paar Ungenauigkeiten der Sensoren an. Die Auflösung muss also mit der Genauigkeit der Hardware abgeglichen werden. Das klappt zumindest ganz gut, wenn der Roboter seine Umgebung selbst erkundschaftet wie in meinem Proggy. Natürlich ist der Roboter in diesem Fall kein Kartographie-experte, aber es funktioniert.
Kann man so ne Karte irgendwie visuell darstellen? Würde mich mal interessieren wie Dein Zimmer von Deinem Bot dann gesehen wird.
Problem ist halt wie gesagt (Beitrag war von mir, hatte wieder vergessen mich einzuloggen), das die Steuergenauigkeit in der Praxis nicht immer so einfach ist
Wie schmieden halt die grundlegenden Pläne zum Bau des ersten Terminators ;)
Aber so eine Art "3D-Bild" durch auswertung zweier US-Sensoren im Abstand von 5-10cm würde mich reizen! Interesse, irgendwer hier? :D
Also ich in jedem Fall!!! Wie gesagt, hab von der Hardware net so den Plan, aber mich interessierts!! Wär ja schon der Hammer so´n Roboter mit 3D-Blick :D !!!
Hab auch keinen Plan :D
Ich wüsste nichtmal, wie ich z.B. aus den Bildern zweier GameBoy-Cams die Tiefeninformationen errechnen kann. Zu solchen dingen sind bots atm wohl nicht fähig :)
@Frank: Also die Darstellung besteht in meinem Proggy aus den Schwarz gestreiften Rechtecken. Das Programm zeichnet in einer virtuellen Bitmap einen schwarzen Kreis, wenn der Sensor einen Impuls abgibt. Da werden also die Sensorimpulse 1 zu 1 übertragen. Dann wird daraus ein Bild mit niedriger Auflösung.Das ist die Karte, wie sie die K.I. "sieht". Wie du siehst, ist die Auflösung mit 32x20 sehr niedrig. Aber genau darin liegt die Stärke des ganzen. Selbst wenn der Sensor z.B. ein 5cm breites Stück in der Wand nicht als Hindernis erkennt, wird der Roboter nicht versuchen durch die Wand zu fahren. Diese Löcher werden also gestopft. Das gilt auch für Objekte, in denen wirklich Löcher sind. Wenn jetzt der Weg total versperrt ist, weil die Auflösung so niedrig gewählt wurde, dass nahe beieinanderliegende Objekte als eines angesehen werden, dann wird die Wegplanung über A* abgeschaltet. Dann sind nur noch die "Reflexe" des Roboters aktiv, die ihn da raus manövrieren. Am besten ist es denke ich, wenn man zwischen verschiedenen Leveln unterscheidet. Das ist ja beim Menschen auch so. Wir planen eine Bewegung, aber plötzlich kommt ein Reflex dazwischen und die Bewegung wird abgebrochen und eine neue eingeleitet.
Ach ja, das Proggy hab ich mal geupdatet. Jetzt sollte es ein paar weniger Laufzeitfehler etc. geben. Ich denke die PRoblematik kann man sich ganz gut klarmachen, wenn man mit den Werten etwas rumspielt (Rasterauflösung etc.).
@wizzard: dann bin ich ja beruhigt*g* Ich bin mir allerdings nicht sicher, ob eine 3D-Erkennung mit zwei Kamerabildern nicht leichter wäre. Da hat man nämlich noch Farbwerte, die man vergleichen kann.
Klingt ja alles recht überzeugend und einfach! Aber nur am Screen! Ich will erst mal den Roboter am Boden fahren sehen ;-) Wenn das so halbwegs nach dem Plan funktioniert - dann alle Achtung!
Das ist jedenfalls mein Ziel! Ob ich´s erreiche, weiss ich nicht, aber ich bin halt von Natur aus Optimist :D
Nebirosh
10.12.2003, 07:24
zum post von miho und dem chaotischen zustand der behausung. wenn ein roboter in einer sich verändernden umwelt zurechkommen soll ( muss ) helfen feste karten ansich nur wenig. klar die schrankwand wird man nicht alle 2 tage umstellen aber zum beispiel stühle oder den tisch. ich tendiere zu flexiblen karten, ähnlich einem schachbrett, wobei die feldgröße in etwa den grundmaßen des roboters entsprechen. stellt der roboter nun beim ersten anfahren eines feldes fest das es durch irgendetwas belegt ist wird dieses feld mit einer 1 belegt. beim nächsten durchgang wird dieses feld nicht angefahren sondern erst beim 3 durchgang. ist es wieder belegt wird das feld mit einer 2 versehen und erst wieder im 4. darauffolgenden durchgang versuchen das feld anzufahren. sozusagen bildes sich damit eine landkarte in einer grauwertskala ab. eine erweiterung wäre sicherlich noch jeweil in einem feld zu speichern von welcher kante aus versucht wurde das feld anzufahren
Nebirosh
10.12.2003, 07:37
und gleich noch einer hinterher, 3D sicht mit zwei kameras deren winkel zueinander zur entfernungsbestimmung herangezogen werden. das prinzip des laserpointers dürfte jedem klar sein, der laser beleuchtet ein object, die kameras versuche nun diesen punkt genau in den mittelpunkt ihres bildes zu bekommen ( schuldigung wenn das laienhaft klingt aber es soll jeder verstehen können ) nun kann ein prozessor errechnen wie weit dieser punkt von den "augen" des roboters entfernt ist ( einfache geomoetrie ) mit einem schnellen algorithmus ließe sich damit bestimmt ein 3D bild der umgebung abbilden, und eine KI entscheiden ob der weg frei ist oder nicht. was die fehlertoleranz anbelangt kann man mittlerweile mit 3-5° je kamera getrost rechnen.
@Nebirosh:Die Idee mit der flexiblen Karte ist gut. Ich werd mal drüber nachdenken.
Ihr macht euch alle zu viel Arbeit, das gibt es doch alles schon fertig, sucht mal im Web nach 'Rossum Project', da gibt es alles was das Herz begehrt, inklusive Simulator und auch viel Dokumentation zum Thema Karte erstellen.
Gruss,
Andre
Nebirosh
10.12.2003, 13:42
ich münze mal andre´s antwort auf den simulator und nicht auf die karte oder den laser. für den Gast der meine Idee aufgegriffen hat, mit der CC - unit ist das aber kaum möglich das müsste man schon mit mehreren micro controlern oder prozessoren und einer menge NVRAM realisieren. ich werde mal nen script dazu schreiben und hier zum download bereitstellen, sollte so mitte nächster woche vorliegen
Das suchen könnt ihr Euch sparen:
http://rossum.sourceforge.net/forums.html
Vielleicht trägt es jemand in Linkbereich ein
Vor allem den aktuellen Simulator unter http://rossum.sourceforge.net/papers/Localization/index.html muss man in Aktion gesehen haben.
Gruss
Andre
Ach, und wo ich sowieso gerade in meiner Linksammlung stöbere, nochwas zum Thema Kartenerstellung:
http://www.cs.washington.edu/ai/Mobile_Robotics/projects/mapping/
Sehr interessante Dokumente und die 3 AVIs sind erste Sahne.
Gruss
Andre
Nebirosh
11.12.2003, 13:25
also brauche ich kein script hier hochladen, oder wollt ihr doch ?
Nein poste nur dein Script, je mehr unabhängige Infos desto besser. Man kann sich dann immer das beste aus allem heraussuchen
Matthias
30.12.2003, 11:48
Weiss jemand wie man ne optische maus ansteuert? Damit hätte man nähmlich nen super Streckensensor, da räder ja durchrutschen können sind sensoren die mit diesen arbeiten Ungenau. Der roboter könnte zuerstmal im Zimmer alle wände abfahren und so eine Karte erstellten. Diese Karte speichert er dann auf nem externen E²prom ab wodurch die daten auch nach nem Neustart zur verfügung stehen. Als µC würde ich die CC2 vorschlagen, da diese schnell ist und über Multitasking und nem grossem Speicher verfügt. Zur Hindernisserkennung würden, wie schon vorgeschlagen, US-Sensoren super sein. Letztlich müsste man nurnoch ein Grafikdisplay, ne LED-Matrix oder ein VB-programm zum anzeigen der Zimmerkarte einbinden. Beitouren durch das Zimmer würden dem roboter dann immermehr Details auffallen, welche er dann in den E²prom nachträgt.
Matthias
Ahh ja, man sollte natürlich jeweils 2US Sensoren so wie "Augen" anordnen, um irgendwie die Tiefe zu erhalten. Macht schon 8x US :)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.