Archiv verlassen und diese Seite im Standarddesign anzeigen : zurückgelegten Weg berechnen
Hallo, ich bin ja zur Zeit immer ncoh dabei, den GPS gesteuerten Rasenmäher durchzuplanen - da ich aber von der Mechanischen Seite her recht wenig erfahrungen habe, einen Roboter zu bauen, wollte ich gern einen TestBot bauen, mit dem ich dann später einzelne Sensoren/module testen möchte.
Da ich aber zu Anfang weder GPS noch einen Kompass oä. einbaue, ist es wichtig für mich, die drehungen und die zurückgelegte Strecke zu berechnen.
Erst habe ich gedacht es würde reichen, die steps des Schrittmotors mitzuzählen, aber wie ich gesehen habe ist dies eine sehr ungünstige Methode, da die Reifen bei zumindest recht leichten Bots extrem schnell schlupf bekommen und so die drehungen und die zurückgelegte Strecke sehr ungenau werden.
Die zweite Idee war, einfach 2 Räder nur mitlaufen zu lassen, so das ich diesen dann die schritte zähle, aber ich glaube hier wird das problem genauso bestehen, da die Reifen ja nicht unbedingt immer mitdrehen, sondern evtl. über den Boden geschleift werden, ohne das sie sich drehen.
Daher ist meine frage, wie oder wo kann ich am besten herausfinden wie
weit ich nun tatsächlich gefahren bin?
(oder sollte man beide Methoden benutzen, um einen Mittelwert daraus zu bilden)?
Die Idee, die nicht angetriebenen Räder zu messen dürfte bessere Ergebnisse bringen. Damit vermeidet man wenigstens den möglichen Antriebsschlupf.
Ich vermute aber, die eigentliche Herausforderung liegt darin, eine Radaufhängung zu bauen, bei der ein Radschlupf (egal ob angetrieben oder nicht) kaum auftritt. Solange man eine Konstruktion hat, bei der immer mal wieder ein Rad frei in der Luft hängt, kann man keine sinnvolle Odometrie erwarten.
ja da hast du recht, die Aufhängung wird schon ein sehr großes Problem sein...
da muss cih in der tat nocheinmal ran, das problem ist aber eine Aufhängung zu konstruieren, die ersteinmal gefedert, und pro Seite 3 Räder hält, die darüber hinaus auch noch angetrieben sind :)
der Roboter soll ja erstmal nur in einem kleinem Zimmer testläufe absolvieren von daher müssen die ergebnisse nicht gerade zu exakt sein, aber exakt genug, um das verhalten des Roboters analysieren zu können sprich wenn ich dem Bot sage er soll sich um 90° drehen, das er sich dann nicht unbedingt in einem Rahmen von 60-120 Grad dreht je nach dem wie der Untergrund ist ) :) - ich hoffe ihr versteht mich wie ich das meine :)
Drei Räder pro Seite, das klingt nach Kurvenfahrt wie beim Kettenfahrzeug.
Sowas ist für Odometrie immer ungünstig, besser ist es, wenn auch bei Kurvenfahrt kein Gleiten, sondern nur Rollen stattfindet, das ist aber bei 6 Rädern eine ziemlich aufwändige Sache.
Das Problem beim Gleiten ist, daß man nie weiß, welches Rad früher zu rutschen anfängt, speziell bei einem inhomogenen Untergrund wie Rasen. Das ist dann prinzipbedingt schlecht geeignet für eine Odometrie, man sollte sich dann auf andere Sensorik verlassen - außer man fährt nur geradeaus ;-)
ja genau, der Roboter soll nachmöglichkeit sich so drehen, wie ein Kettenfahrzeug, wobei ich dir recht geben muss, das einige Reifen wohl über den Untergrund geschliffen werden. Wie gesagt die Lösung soll einfach sein - und es sollten einfache dinge zu sehen sein, das er sich halt korrekt dreht usw. und das auch nur auf einem sehr begrenzten Testrahmen von ca. 2x2m.
Ich möchte halt nur nach möglichkeit das verhalten des Bots sehen mit den Motoren und dem Gewicht (das Gewicht beträgt wahrscheinlich über 50 Kg (40 Kg nur für die Akkus)). Daher ist es auch sehr wichtig, das der Bot vernünftig abbremst usw. damit der Bot nicht bei anderen Testfahrten einfach mal auf die Idee kommt, einen mal umzuschubsen so allá da war ein Hindernis? ^^ Das sind so die wichtigsten Funktionen, die ich halt erstmal test möchte dann ^^. Später geht es dann weiter auf GPS und Kompass damit wären dann die Reifensensoren hinfällig aber halt ganz zum anfang für die ersten primitivsten tests finde ich dann GPS und Kompass ein wenig für overfused vor allem weil cih glaube, das ich ncoh sehr viele Stunden Programmierarbeit leisten darf, wenn ich die Module realisieren möchte :)
Hubert.G
23.02.2009, 15:57
Ich habe einen gekauften Rasenmäher, der fährt auf den ersten Blick konfus in der Gegend herum. Tut es aber tatsächlich nicht. Er fährt das Rasenstück in parallelen Linien ab, indem er sich jedesmal wenn er ansteht ein Stück zur Seite dreht, kurz anfährt und wieder zurückdreht, sodas er etwas versetzt aber parallel zur vorherigen Fahrtstrecke wieder zurückfährt. Wenn das Ende des Rasenstücks erreicht ist, dreht er um etwa 30° und fährt weiter.
Das geht besser und genauer als mit Positionierung zu fahren, da man in diesem Fall die Ungenauigkeiten mit einrechnen muss. Es nützt ja nichts wenn man schnell fertig ist und irgendwo in der Mitte ein schmaler Streifen Gras stehen bleibt.
hi
wenn dein test bot noch nich auf graß fährt kannst du pos von ner Maus geben lassen.
mfg thomas
kermitderfrosch
28.02.2009, 00:30
hi,
ich stehe vor ähnlichen Problemen wie Du.
Eins vorweg, ob GPS oder sonstwas an Sensorik, es bleibt ungenau,
auch beim Rasenmähen :)
Nimm einfach Beschleunigungssensoren, gibts auch hier im Shop.
Mußt Du halt zweimal integrieren (oh ja, haben wir in der Schule oder Studium gelernt ;) ) und so hast Du den zurückgelegten Weg
Deines Rasenmähers. Soweit die Theorie... Ich selbst habe noch keine Erfahrung mit diesen Sensoren, wäre Klasse wenn wir uns austauschen könnten und andere hier Ihre Erfahrung mitteilen.
Gruß
Jörg
Habe zufällig etwas Erfahrung (Diplomarbeit) mit deinem Problem.
Radgebundene Odometrie Messungen bei inhomogenen und unebenen Untergrund ist stark fehleranfällig. Deswegen war meine Lösung damals eine Optische Odometrie zu verwenden.
Meine Erfahrungen damit sind sehr gut!
Du kannst du kannst die nicht triviale Aufgabe von der Komplexität einschränken in dem du mit aktiven Markern arbeiten so wie bei der Wii (Spielekonsole) und ein fertiges Kameramodul verwendest (CMUcam3).
Also mein Vorschlag ist mach es Optisch!
Gruß
Der Melchi
ich glaub ich habe mich falsch ausgedrückt :) der Bot soll in dem Stadium einfach erstmal nur Hindernissen ausweichen und abbremsen er soll nicht navigieren und erst recht keinen Rasenmähen, es sollen erstmal Sicherheitstechniken usw. programmiert und getestet werden so das der Bot der wahrscheinlich fast 50 Kg wenn nciht noch mehr wiegt keinem einfach in die Hackenfährt :)
An: Kermit klar können wir uns da mal ein wenig zusammenschließen zu zweit bekommt man meist mehr gebacken als einer allein bzw. einige dinge schneller hin :) am besten ist du gibts mir ma deine E-Mail Adresse, damit wir uns besser austauschen können :)
Eh…. Ja also „ist es wichtig für mich, die Drehungen und die zurückgelegte Strecke zu berechnen“ ist schon anders zu verstehen als „der Bot soll in dem Stadium einfach erstmal nur Hindernissen ausweichen und abbremsen“ :o)
Ja ja.. die Kommunikation!! Eine Welt voller Missverständnisse ;-)
Für dein Basisstadium „Sicherheit“ denke ich spontan an die guten alten Sensoren wie Ultraschall und Infrarot.
Hindernis erkannt Hindernis gebannt! <-- Feritg!
ja aber genau ist zwar alles schön und gut, aber vorsicht ist besser als nachsicht ^^
Hallo!
@ BjoernC!
Ich hätte eine Idee, die vielleich interessant für dich wäre. Ich meine eine optische PC Maus mit verstärkter Beleuchtung. Ein eifacher Test hat bei mir ergeben, dass solche Maus nur Bewegungen in zwei senkrechten Achsen verarbeitet und beim Drehen, bewegt sich der Mauscursor auf dem Bildschirm nicht.
MfG
ja wahrscheinlich würde ich die Maus dann ganz vorne am Bot anbringen der Bot wird geschätzte 50 cm Lang werden evtl. noch ein bissl größer wegen dem Mähwerk usw. von daher gäbe es durchaus Verschiebungen in X und Y Richtung.
Das problem mit den Reifen vll. sollte ich einfach mal erklären warum cih diese Frage hier herein gestellt habe:
das Problem war folgendes im Rahmen der Vorlesungen mussten wir einen Roboter (fischertechnik) mit einem PC steuern (via USB) das problem war, das die Räder Schlupfhatten, und der Bot so einige Befehle "geschluckt" hatte ohne das wir es software mäßig irgendwie mitbekommen haben. Wir mussten daher den Lauf des Bots irsinnig oft wiederholen - und spaß gemacht hatte es auch nciht - da jeder Lauf zT. beachtliche Abweichungen zum letzten Lauf hatte. Richtig frustrierend war dann das man im Log liest, das der Bot rückwärts gefahren ist, aber es in der realität nicht gemacht hat, zumindestens nicht merklich :).
Daher auch meine Frage, wie man sowas nach möglichkeit leicht in den Griff bekommen kann :) - denn wir konnten nur anhand der Analyse des Logs feststellen, das der Bot richtig gefahren ist...
das problem war, das die Räder Schlupfhatten, und der Bot so einige Befehle "geschluckt" hatte ohne das wir es software mäßig irgendwie mitbekommen haben. Wir mussten daher den Lauf des Bots irsinnig oft wiederholen - und spaß gemacht hatte es auch nciht - da jeder Lauf zT. beachtliche Abweichungen zum letzten Lauf hatte. Richtig frustrierend war dann das man im Log liest, das der Bot rückwärts gefahren ist, aber es in der realität nicht gemacht hat, zumindestens nicht merklich
Das kann man nachvollziehen. Ein wesentlicher Faktor für eine brauchbare Navigation anhand von Raddrehzahlsensoren ist, dass das Räder- bzw. Antriebskonzept auch in Kurvenfahrt schlupffreies Abrollen der Räder ermöglicht. Drei ungelenkte Achsen haben zwar einen hervorragenden Geradeauslauf, der Drehwinkel bei Kurvenfahrt hat aber eine große Streuung. Hier braucht es dann eine andere Sensorik.
Drei ungelenkte Achsen haben zwar einen hervorragenden Geradeauslauf, der Drehwinkel bei Kurvenfahrt hat aber eine große Streuung. Hier braucht es dann eine andere Sensorik. hmm entweder ich drück mich am laufenden Band falsch aus oder verwirre die Leute hier nur zunehmend ;).
Also der Bot mit den 3 Antriebsachsen ist weder fertig noch sind irgendwelche Teile vorhanden dafür naja ok 1 Motor ist zumindest da :).
Den Bot, den ich meinte hat 1 Antriebsachse und dreht sich aber so ähnlich wie sich mein Bot später drehen soll. damit der Bot nicht einfach umkippt hat er hinten so ein Rad, das sich halt in alle 3 Richtungen drehen kann (wie bei einem Einkaufswagen).
hier mal ein kleines Video dazu, vielleicht versteht ihr das so besser was ich genau meine, recht spät (kurz vor Ende) des Videos seht ihr, das der Bot sich nicht wirklich um 90° dreht und die Abweichung schon sehr beträchtlich ist.
Und genau da ist mein problem ich möchte bei den Testfahren (mit dem noch nicht fertigen Bot) erstmal keine Abweichungen von +- 30° haben :) es muss nicht perfekt sein sollte sich halt in einem berreich von ca. 5% halten da der Raum nicht sonderlich groß ist für die Testfahrten (ca (5x5)m ).
http://www.supload.com/vid/ROBOcop/130056352/mov/
PS: das video zeigt nur, ein Beispiel, warum ich diese Frage gestellt habe, der Bot steht in keinerlei zusammenhang mit meinem Bot oder ähnliches es war lediglich eine Programmieraufgabe seitens der FH
Hallo BjörnC,
das mit den drei ungelenkten Achsen hattest Du vorher schon mal erwähnt gehabt, daher das kleine Mißverständnis.
Was den kleinen Bot im Video betrifft, der könnte durchaus genauer sein. Den mechanischen Aufbau kann ich nicht beurteilen (die Auflösung des Video ist zu gering). Folgende Vermutungen habe ich bezüglich der ungenauen Drehung:
1. Motoren werden nicht per Rampe beschleunigt sondern nur ein/ausgeschaltet. Durch das hohe Drehmoment nach dem Schalten ergibt sich Schlupf an den Rädern.
2. Die Impulse des Inkrementalgebers werden nicht korrekt gezählt z.B. wegen mechanischen Ungenauigkeiten, ungünstiger elektrischer Anpassung des Fototransistors, Störimpulse über Betriebsspannung und was es da sonst noch für Möglichkeiten gibt. Wenn so ein Fehler sporadisch auftritt kann man da ziemlich lange suchen bis man ihn hat.
naja die impulse wurden naja komisch gezählt:
man nehme das kleinste Zahnrad aus dem F-Technik Satz (4 Zähne) , dann verbindet man einfach die Antriebsachse mit dem Zahnrad und nimmt dann einen Schalter der genau in die Nut der Zahnräder passt, so wurden die Drehungen gezählt ;).
Aber das ding wurdew ja so von der FH so gestellt...
naja die impulse wurden naja komisch gezählt:
man nehme das kleinste Zahnrad aus dem F-Technik Satz (4 Zähne) , dann verbindet man einfach die Antriebsachse mit dem Zahnrad und nimmt dann einen Schalter der genau in die Nut der Zahnräder passt, so wurden die Drehungen gezählt .
Aber das ding wurdew ja so von der FH so gestellt...
Das klingt rustikal!
Wenn das nur 4 Impulse pro Antriebsradumdrehung sind, ist ja die Auflösung auch viel zu schlecht. Manchmal ist es ja auch ganz lehrreich, wenn man sieht, wie es nicht geht.
Kürzlich hatten wir eine schon eine Diskussion um den Themenkreis, Du hast es wahrscheinlich selbst gesehen:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=45741
Das andere Extrem, eine extrem hohe Auflösung. Irgendwo dazwischen ist dann die anzustrebende Lösung, die zuverlässig und genau funktioniert.
OK 4 Zähne sind 8 Flanken pro Umdrehung :-) das kommt dem „alten“ Encoder von Xaver schon recht dicht. Nur hatte der 8 Flanken pro Umdrehung am Motor und nicht am Rad.
Seine bzw. auch meine (denn das ist ein gemeinsames Projekt von Xaver und mir) „neuen“ Encoder mit 144 Flanken (36 Zähne *kicher*) sind doch nicht zuviel!! :-)
Mittelwerte bilden um ein paar Schwankungen, bedingt durch den Eigenbau, zu glätten und es bleibt nicht viel übrig! (leicht übertrieben)
Und wie schon einmal erwähnt sind bei gekauften Motoren gerne auch mal 1000 Flanken pro Umdrehung drin. Da sind wir mit unseren 144 Flanken doch sehr human. <-- Meinung
Zurück zum Thema:
Ich stimme ranke zu, das es bei den 4 Zähnen die Auflösung zu gering ist.
Ist es eventuell möglich ein größeres Zahnrad mit mehr Zähnen zu verwenden. Oder ein weiters Zahnrad leichtem Versatz und eigenen Schalter. Für solche Laborübungen habe ich gute Erfahrungen mit einem Externen Tracking-System gemacht. Sonst hat man in seinem Navigationsalgo gleich eine Fehlerkette mit drin. Ich schweife ab…
Du hast gesagt das das 3. Rad (Stützrad) wie bei einem Einkaufswagen aufgebaut ist. Das kann auch eine Fehlerquelle sein. Denn dieses beeinflusst die Drehung. Dieses wird besonders gut in diesem Dokument klart.
http://web.cecs.pdx.edu/~mperkows/CLASS_479/S2006/kinematics-mobot.pdf
(Das alle Roboterfreunde kennen sollten)
habe jetzt nicht alles gelesen, aber nehm doch zur wegvermessung räder mit Spikes (Nägel) dran, die haben keinen Schlupf und lüften den Rasen ;)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.