Hey Leute, Folgende Aufgabe: Roboterarm ähnlich dem menschlichen Arm. (Stichwort: BIOROB) 1. Welche Motoren könnte man für die Gelenke verwenden? Diese sollten nicht zu schwer sein, aber trotzdem sehr genau. Servomotoren oder Schrittmotoren sind oft zu schwach oder werden sehr teuer. 2. Gesteuert werden soll das Projekt über einen Mikrocontroller. Welche Anforderungen sind an einen solchen Mikrocontroller gestellt? evtl. PWM Ausgänge? 3. Mit welchen Sensoren ist eine hohe Positioniergenauigkeit realisirbar? Inkrementalgeber werden ab 1000 Schritten/Umdrehung sehr teuer. Könnten G-Sensoren benutzt werden? wie sieht deren Genauigkeit aus? Oder hat jemand eine Idee für ein anderes Sensorkonzept? Die Formulierung ist zwar nicht sehr gut, aber es ist auch schon spät. Würde mich über jeden Kommentar oder auch nur jeden kleinsten Tipp/Erfahrung bedanken. Mfg
Peter Pan schrieb: > 1. Welche Motoren könnte man für die Gelenke verwenden? Diese sollten > nicht zu schwer sein, aber trotzdem sehr genau. > Servomotoren oder Schrittmotoren sind oft zu schwach oder werden sehr > teuer. Servos aus dem Industriebereich. Im Idealfall AC-Servos. Ein guter Anfang fürs Hobby wären bürstenbehaftete (!) DC-Motoren und ein Hobbycontroller wie der UHU-Servocontroller http://www.uhu-servo.de/ Schrittmotoren sind zu schwach und erfüllen im Allgemeinen nicht die physikalischen Anforderungen. Eine Möglichkeit wären aber auch Schrittmotoren mit einem Getriebe oder besser ein Harmonic Drive. Aber da haben wir dann schonwieder die 1k€ Marke für eine Achse deutlich überschritten. Hast dir mal überlegt wieviele Achsen du brauchst. Peter Pan schrieb: > 2. Gesteuert werden soll das Projekt über einen Mikrocontroller. > Welche Anforderungen sind an einen solchen Mikrocontroller gestellt? > evtl. PWM Ausgänge? Das kommt darauf an was der Mikrocontroller erledigen soll. Die Bewegungen in den Achsen sind so und so derart komplex, dass das mit Sicherheit ein Computer machen wird. Ein Mikrocontroller dient vielleicht noch zur Umsetzung PC-USB-Servotreiber um die Servotreiber vom PC aus ansteuern zu können. Das können 8bitter (AVR, PIC18, ...) sehr gut. Peter Pan schrieb: > 3. Mit welchen Sensoren ist eine hohe Positioniergenauigkeit > realisirbar? > Inkrementalgeber werden ab 1000 Schritten/Umdrehung sehr teuer. Die Positionierung bekommt man aus den Serovs raus. Die isnd allesamt natürlich mit entsprechenden Encoderscheiben versehen. Alternativ kann man sich aus Tintenstrahldruckern billige Enocer holen. Die haben meist >5000 Striche und sind auf ebay für 1€ zu bekommen. > Könnten G-Sensoren benutzt werden? wie sieht deren Genauigkeit aus? Nein sind völlig verrauscht und Beschleunigungssensoren nehmen wie der Name schon sagt Beschleunigungen auf und dazu gehört bei einem dyn. System nicht nur die Erdbeschleunigung. Völliger Unsinn. > Oder hat jemand eine Idee für ein anderes Sensorkonzept? Nein. Im Allgemeinen macht deine Art der Fragenstellung nicht den Eindruck, als ob du nötiges Vorwissen zum Projekt hast. Sei mir nicht böse aber ich fürchte sowas sprengt den Hobbykostenrahmen. Ich würde mir als Einstieg (wenn es auch Murks ist) einen Roboterarm aus Modellbauservos zusammenbauen. Das ist schon Arbeit genug und ein guter Einstieg in die Mikrocontrollerwelt. http://www.mikrocontroller.net/articles/AVR-Tutorial http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial http://www.mikrocontroller.net/articles/Modellbauservo_Ansteuerung Also einfach nur einen Konverter USB <> Servos und dann am PC eine entsprechende Software erstellen. Die ist nämlich der eigentliche Gag der Sache und erfordert sehr gute mathematische Kenntnisse. Das ist genug Arbeit für ein Hobbyprojet und ein halbes Jahr.
Wie groß soll denn dein Robot werden? Schwerindustrie oder Feinmechanik? Welche Genauigkeit ist erforderlich? Für Kleingeräte und lernmdelle gibt es im Modellbau inzwischen speziell geformte Robot-Servos. Die werden wie alle Modellbauservos per PWM gesteuert ... es gibt sogar eine Version mit RS232 und Positionsrückmelung. http://www.robonova.de/store/product.php?productid=16185&cat=4&page=1
Hey, ich habe die Aufgabenstellung nicht genau formuliert: -Projekt für mehrere Leute -wie menschlicher Arm: Schulter, Ellenbogen, Handgelenk -möglichst leicht (ca. 10Nm an der Mittelpunkt (Schultergelenk)) -der Arm soll 800mm Radius haben -Positioniergenauigkeit: 1cm -eventuell mit Umlenkrollen wie beim BioRob-Projekt http://www.biorob.de/ -ein Mikrocontroller wäre vorhanden (Atmega32), Frage ist nur welche Anforderungen an diesen gestellt werden? Zu den Servos: die sind meiner Meinung nach sehr teuer oder zu ungenau. Das ganze soll die 1k€ Grenze nicht überschreiten Zu den Sensoren: Das mit den Druckerinkrementalgebern ist wohl die einzige Möglichkeit günstig an Inkrementalgeber zu kommen. Der Arm kann ruhig sehr langsam fahren, so dass auch die G-Sensoren in den Sinn kamen Es geht eher um die hohe Präzision in dem System. Danke für die schnellen Antworten!
Aha. Peter Pan schrieb: > -wie menschlicher Arm: Schulter, Ellenbogen, Handgelenk Oha. Lies mal hier: http://prof.beuth-hochschule.de/fileadmin/user/linnemann/PDF-Dateien/Robotertechnik/Roboter_Technik_Vorlesung_Teil_02.pdf Zitat: • Freiheitsgrad f einer menschlichen Hand ist 6, der Bewegungsfreiheitsgrad F ist 22 • Freiheitsgrad f eines menschlichen Arms ) incl. Schulter ist 6, Bewegungsfreiheitsgrad F ist 7 Das macht dann für eine Hand incl. Schulter bis Finger 22 + 7 = 29 Motorachsen. Ohne die Finger sind es immerhin nur noch 2 + 7 = 9 Motoren. Immerhin. Peter Pan schrieb: > -ein Mikrocontroller wäre vorhanden (Atmega32), Frage ist nur welche > Anforderungen an diesen gestellt werden? Wie soll man so eine Frage beantworten. Ihr habt keine Ahnung was für Motoren ihr verwendet, ergo ihr wisst nicht wie man deren Treiber ansteuert weil ihr den Treibertyp nicht kennt. Also kann man nichts über die Ansteuerung sagen und darum auch nichts über die Anforderungen an den Mikrocontroller. Der Mikrocontroller muss nur Signale vom PC "übersetzen" und den Motortreiber ansteuern. Berechnen tut alles der PC. 9 Achsen sind kein Kinderspiel. Peter Pan schrieb: > Der Arm kann ruhig sehr langsam fahren, so dass auch die G-Sensoren in > den Sinn kamen Das ist wie ein Chirurg der mit der Kettensäge einen Blinddarm entfernt.
Also gedacht sind folgende Motoren: -Torso -Schulter -Ellenbogen -Handgelenk jeweils nur als "Drehgelenk" Das man die Frage mit dem Mikrocontroller nicht so einfach beantworten kann ist mir bewusst. Da dies unser erster Roboter ist, war die Frage eher allgemein bezogen. Soll heißen das wir noch garkeine Idee und Erfahrungen zu allen Bauteilen haben. Die Auswahl an Motoren ist sehr groß, jedoch wissen wir nicht welche sich für eine solche Entwicklung am besten eignen. Zudem kommen die Sensoren, alle die uns ins Auge gefallen sind waren entweder viel zu ungenau, oder kosten 250€ (Inkrementalgeber 1000Schritte)
K. D. schrieb: > Peter Pan schrieb: >> Der Arm kann ruhig sehr langsam fahren, so dass auch die G-Sensoren in >> den Sinn kamen > > Das ist wie ein Chirurg der mit der Kettensäge einen Blinddarm entfernt. der hier war unsere Idee: http://www.mikrocontroller.net/articles/BMA020#Speicheraufteilung
Tu dir selbst einen Gefallen und vergiss endlich mal die Beschleunigungssensoren! Ich vesteh überhaupt nicht, welchen Narren die Leute immer an diesen Beschleunigungssensoren gefressen haben! Als ob die der Stein der Weisen wären. Überleg dir lieber ein Konzept, wie du zb mit einem Getriebe und Übersetzung billige Encoderscheiben einsetzen kannst oder wie du zb mit einem Poti als Spannungsteiler die Rückmeldung realisieren kannst.
Peter Pan schrieb: > http://www.mikrocontroller.net/articles/BMA020#Spe... 10bit Auflösung bei minimal +-2g ? Schon malgerechnet um wieviel sich der Robotarm abwinkelt, wenn er sich ganz vorne um 1 cm bewegt? Das ist niemals mit den Sensoren zu detektieren. Hat ja auch seinen Grund, warum alle Welt Encoder benutzt, robust, störarm, billig. Aber zurück zu Arm, ich würde da so rangehen: - gewünschte Belastbarkeit, Funktionsumfang definieren - ausrechnen der dafür notwendigen Drehmomente (Eigengewicht der Konstruktion nicht vergessen) - gewünschte Geschwindigkeit und Beschleunigung festlegen - Wenns billig sein soll (und das wird so ein Arm mit 80cm Aktionsradius nicht) DC-Motoren und Getriebe auswählen, am besten als Einheit kaufen, sonst gibts zuviel Getriebespiel, ultimativ wäre hier ja ein industrieller Servoantrieb. - Die Motoren legen dann den Motortreiber fest, die Spannungsversorgung und die Ansteuerungsmöglichkeiten per uC. Und dann sieht man weiter.
Floh schrieb: > Hat ja auch seinen Grund, warum alle Welt Encoder benutzt, robust, > störarm, billig. Danke erstmal. Genau das ist unser Problem, dass die Encoder in der gewünschten Auflösung nicht mehr billig sind. Es sei denn wir zerlegen alte Drucker? Eine ähnliche Vorgehensweise haben wir auch genutzt. Uns fehlt nur die Erfahrung mit den Bauteilen, weil dies unser bislang erstes Projekt ist. Unser größtes Problem sind halt die Sensoren, da kaum einer die gewünschte Genauigkeit bei 800mm Radius erfüllen kann.
Peter Pan schrieb: > Unser größtes Problem sind halt die Sensoren, da kaum einer die > gewünschte Genauigkeit bei 800mm Radius erfüllen kann. Nimm eine billige Encoderscheibe und montiere sie nicht auf die Gelenkachse, sondern auf die Motorachse. Dadurch wird die Auflösung mit der Getriebestufe vervielfacht. Gibt viele Motoren, die man mit integrierten Encodern kaufen kann. (Bühler, Maxonmotors, Faulhaber ...)
Floh schrieb: > Peter Pan schrieb: >> Unser größtes Problem sind halt die Sensoren, da kaum einer die >> gewünschte Genauigkeit bei 800mm Radius erfüllen kann. > > Nimm eine billige Encoderscheibe und montiere sie nicht auf die > Gelenkachse, sondern auf die Motorachse. Dadurch wird die Auflösung mit > der Getriebestufe vervielfacht. Gibt viele Motoren, die man mit > integrierten Encodern kaufen kann. > (Bühler, Maxonmotors, Faulhaber ...) Da das Vorbild ein menschlicher, nachgiebiger Arm (siehe Vorbild: BIOROB) ist, würde eine Auswertung der Motoren mit integrierten Encodern nicht funktionieren.
Peter Pan schrieb: > > Da das Vorbild ein menschlicher, nachgiebiger Arm (siehe Vorbild: > BIOROB) ist, würde eine Auswertung der Motoren mit integrierten Encodern > nicht funktionieren. Irgendwie hab ich das Gefühl, dass ihr unter 'elastisch' etwas völlig anderes versteht, als der Hersteller des Biorob. Schau dir die Videos auf http://www.biorob.de/download/videos.html an. Der Robot ist genauso aus Metallröhren aufgebaut, ich schätze mal Alu. Von "biegsamen" Armen kann da keine Rede sein. Selbstverständlich funktionieren da Motoren mit Encodern. Letzten Endes geht es nur darum, festzustellen, wie weit der Motor aktuell das Gelenk verdreht hat. Die 'Elastizität' von der der Hersteller spricht, kann auch dadurch realisiert sein, dass die Stromaufnahme der Motoren überwacht wird und die Elektronik die Motoren 'freigibt', sobald es bemerkt, dass die Motoren zuviel Strom ziehen und daher offenbar gegen ein Hinderniss gestossen sind.
Warum versuchst du es nicht erst mal mit einer einfachen Lösung. Die Ansteuerung wird noch anspruchsvoll genug, dagegen sind deine Hardwareprobleme einfach. Hier hast du ein gutes Beispiel, wie du es am einfachsten lösen könntest. http://www.jtronics.de/modellbau/roboterarm.html
Karl Heinz Buchegger schrieb: > Die 'Elastizität' von der der Hersteller spricht, kann auch dadurch > realisiert sein, dass die Stromaufnahme der Motoren überwacht wird und > die Elektronik die Motoren 'freigibt', sobald es bemerkt, dass die > Motoren zuviel Strom ziehen und daher offenbar gegen ein Hinderniss > gestossen sind. genau so ist es.
Martin J. schrieb: > Karl Heinz Buchegger schrieb: >> Die 'Elastizität' von der der Hersteller spricht, kann auch dadurch >> realisiert sein, dass die Stromaufnahme der Motoren überwacht wird und >> die Elektronik die Motoren 'freigibt', sobald es bemerkt, dass die >> Motoren zuviel Strom ziehen und daher offenbar gegen ein Hinderniss >> gestossen sind. > > genau so ist es. Hab noch ein wenig auf der Seite geschmökeret. Der Hersteller spricht auch von eine passiven Kollisionsvorsorge. Ich schätze mal, dass die Rohre eine gewisse Biegsamkeit mitbringen, was ja auch im Kollisionsfall durchaus erwünscht ist, wenn die ganze Konstruktion ein wenig nachgibt. Ob die die Encoder in den Gelenken sitzen haben, oder an den Motoren kann man auf den Bildern und/oder Videos nicht zweifelsfrei erkennen. Würde mich aber nicht wundern, wenn die in den Gelenken sitzen. Auf den Videos sieht man den Robot leider nie größere Gewichte hantieren, immer nur Kleinteile, bei denen sich keine oder kaum eine Durchbiegung ergibt. Alles in allem hätte ich gesagt: Peter Pan sollte sich erst mal an einem klassischen Puma-Robot versuchen. Die Mathematik dahinter ist schon anspruchsvoll genug, auch ohne dass man eine evetuelle Durchbiegung herausrechnen und bei der Positionierung berücksichtigen muss.
Peter Pan schrieb: > Genau das ist unser Problem, dass die Encoder in der gewünschten > Auflösung nicht mehr billig sind. Das kommt darauf an. Ich habe gerade in der Bucht 2 absolute Drehgeber in Industriequalität mit SSI Interface für Stück unter 20 Euro inkl. Versand ersteigert. Beide (ein Sick Stegmann und ein Heidenhain) haben 4096 Schritte pro Umdrehung und können 4095 Drehungen erfassen. Das SSI Interface ist bei beiden praktisch identisch (und zum Glück kein EnDat) und easy per AVR auszuwerten. Allerdings sind sie recht gross.
Peter Pan schrieb: > Inkrementalgeber werden ab 1000 Schritten/Umdrehung sehr teuer Du kannst sie parallel mit 45 Grad Winkelversatz auf die Welle setzen, um die Auflösung zu erhöhen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.