Zitierenja aber genau ist zwar alles schön und gut, aber vorsicht ist besser als nachsicht ^^
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“)
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
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.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
hmm entweder ich drück mich am laufenden Band falsch aus oder verwirre die Leute hier nur zunehmendDrei ungelenkte Achsen haben zwar einen hervorragenden Geradeauslauf, der Drehwinkel bei Kurvenfahrt hat aber eine große Streuung. Hier braucht es dann eine andere Sensorik..
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
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...
Das klingt rustikal!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...
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 Umdrehungdas 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/CL...tics-mobot.pdf
(Das alle Roboterfreunde kennen sollten)
Berechtigungen
Lesezeichen