Archiv verlassen und diese Seite im Standarddesign anzeigen : Zwei Roboterarme mit Kollisionserkennung
Hallo Leute, meine Projektidee sieht wie folgt aus, ist verdammt Ehrgeizig und in Anbetracht des fehlenden Knowhows (bis jetzt!) verdammt gewagt.
Ich möchte gerne Zwei Roboterarme tanzen lassen und einen PC die Kollisionserkennung durchführen lassen um im Notfall das komplette System anzuhalten. Vielleicht bastel ich auch im laufe der Jahre nochmal ne komplette Produktionsstraße mit Hochregallager, aber das wird noch ein langer Weg sein.
Zur verwendung kommen erstmal zwei Quickshot SVI 2000 (das Ding aus den 80ern zur Steuerung an damaligen 8-Bit rechnern vorgesehen).
Was ich bisher gemacht habe:
ASURO gebaut und ein wenig programmiert.
8-Kanal Relaiskarte (von Pollin) gelötet.
Optokoppler Steuerplatine für den Qucikshot gebaut.
Anfangs wollte ich die Relaiskarte zur Stuerung des Quickshots zweckentfremden um diesen über den PC zu steuern. Hab ich damals auch gemacht, aber die Relaikarte hat ja schonmal zwei Relais zu wenig um alle 5 Achsen des Quickshot zu bewegen (es sei denn, man tüftelt und bastelt nen muxer).
Hatte dann irgendwann die Optokopler Schaltung im Inet gefunden und diese dann verwendet.
Die Stuerung verlief bisher über die parapin Bibliothek (bin reiner Linuxer). Im Grunde nix weiteres als "Strom liegt an Pin an, kein Strom liegt an Pin an". Also keine digitale Ein-/Ausgabe.
Jetzt möchte ich den Arm aber noch mit einer Positionsbestimmung ausrüsten. Die Gelenk-Achsen werden dafür Potis bekommen. Für die Drehachse (dort gestaltet sich die anbringung des Potis schwieriger) habe ich nen guten Tip bekommen. Einen Wiederstandsdraht um die Grundplatte legen und einen Schleifer auf dem drehbaren Bereich befestigen. Quasi ein selbstgebautes Poti. Für das drehbare Handgelenk und den Greifer habe ich noch keine Idee. Warscheinlich werde ich den Greifer einfach mit zwei Tastern ausstatten und das Handgelenk mit der Odemetrie (die lichtschranken) des ASURO.
Die Idee ist jetzt, dass mir diese neuen Sensoren immer einen digitalen Zahlenwert liefern, über den ich am PC den Zustand bestimmen kann. Es soll hier also wenig Intelligenz in die Mikroprocessor Steuerung implementiert werden. Ich studiere halt angewnadte und kiene technishe Informatik und bin dementsprechend schlecht in der E-Technik unterwegs. Ausserdem bin ich ein besserer Nachbastler als Entwickler von Schaltungen.
Und da setzt es jetzt erstmal an:
Wie erzeuge ich aus dem Potistrom jetzt ein Digitales Signal und wie greife ich dieses am Computer ab.
Die Funktionsweise von nem Poti ist klar. Ich lege ne spannung an (zB. 5V) und schaue dann, wieviel am anderen Ende noch ankommt. Jenachdem, wie präzise so ein Teil nun werden kann, sollte mir das Poti am ende einen Digitalen wert zwischen 0-255 (oder, wenn's hinhaut 0-65535) liefern. Wie erzeuge ich jetzt diesen wert und an welcher Stelle im Rechner lese ich ihn ein? Optimal wäre natürlich auch noch eine Kalibrierung.
Was ich wie gesagt bisher schon gemacht habe, war das Arbeiten mit der parapin Lib, die aber im Prinzip nichts anderes macht, als verschiedene Pins am Parallelport ein oder aus zu schalten. Welcher Port bietet sich an um kontinuierlich Daten zu empfangen? Schließlich sind die Roboterarme ja hinterher in Bewegung.
Wie müsste eine Schaltung aussehen, die in kurzen Intervallen immer den Poti abzastet, dessen Wert in einen digitalen umwandelt und diesen dann sendet.
Ich dachte da vielleicht an eine kleine Schaltung (erstmal nur für einen Poti zum üben) mit einem ATiny, die dann zwei Knöpfe bekommt, um den Poti zu Kalibrieren. Darüber sollte man dem Microprozessor dann die min und die max Stellung des Potis eingeben können.
Bin ich da auf dem Holzweg, oder haut soetwas hin und wenn ja, wie fange ich da am besten an (Tutorials, fertige Schaltungen, Bausätze, Lernbaukästen)?
021aet04
11.07.2009, 14:31
Einen Analogwert kannst du mit einem Analog Digital Converter (ADC) wandeln. Du köntest es auch mit einem Drehgeber (mit Impulsausgang oder Inkremental) arbeiten. Wie schnell sollen sich die Arme bewegen? Je schneller sich die Arme bewegen, desto schneller muss die Datenübretragung und Berechnung sein. Ich würde alles mit µC berechnen und nur die Vorgabe über den PC. Speziell dann, wenn du das Hochregal realisieren willst. Not aus würde ich immer einbauen, man kann nie wissen. Als erstes würde ich mir genau überlegen, wie du das realisieren willst. Rein mit µC, Sollwertvorgabe über PC und Berechnung mit µC, Vorgabe und berechnung über PC. Wenn du µCs verwenden willst musst du dir überlegen, welchen du nimmst (Atmega, PIC,... ). Danach richtet sich die Tutorials, etc. Es gibt sicher fertige Schaltungen. Du musst dir aauch überlegen, welche Antriebe du nimmst (Schrittmotor, BLDC, DC, Asynchronmaschine,...). Ich hoffe, dass es dir etwas hilft. Sonst viel Spaß und Erfolg bei diesem Projekt
MfG Hannes
Meine IDee sieht eigentlich vor, dass der Computer ein 3D Modell (natürlich wesentlich gröber) in form von Vektoren vorhält und anhand des übermittelten Wertes bestimmen kann, um wieviel Grad eine Achse gerade gedreht wird. Nehme ich also Beispielweise die Werte 0-255 und kann einen Arm von Position 0Grad auf Position 90Grad fahren, dann weiß der Rechner, dass Beim Wert 128 (poti auf mittelstellung) der Arm auf 45Grad steht.
Normalerweise werden die Qucikshots von alten Quickshot Joysticks gesteuert. Die Stuerplatine macht im Grunde nix anderes als Den Strom an den Moter entweder links rum, oder rechtrum oder garnicht abzugeben.
Quasi, Steuerknüppel nach Links, Schalter schliest Stromkreis + | - am Motor, Steuerknüppel nach rechts, Schalter schließt Stromkreis - | + am Motor. Nichts anderes macht momentan die Parapinlib. Diese Schaltet Strom auf die Pins des Parallelports, der dann wiederum über die Optokoppler die entsprechenden Stromkreise für die Motordrehrichtung schließt.
Mit Notaus meinte ich eigentlich nur, dass der rechner die beiden arme zufällig bewegen soll und dabei aber immer deren Position überwachen soll. Für den Fall, dass die arme sich in die Quere kommen, soll er das System anhalten.
Später werde ich die Arme warscheinlich über die serielle Schnittstelle steuern müssen (oder über USB, falls es da schon Schaltungen gibt). Bis dahin ist aber noch ein langer Weg und ich muss erstmal das System begreifen.
Also lieber erstmal einfach anfangen und irgendwie einen Potiewert digitalisieren und abfragen.
Lässt sich soetwas zB. mit nem einfachen max232 erreichen, den ich dann per Programm abfrage? Ich würde dann quasi den aktuellen Wert einlesen, den Drehimpuls über parapin erteilen , lesen, lesen, lesen und wenn der gewünschte Wert erreicht ist, die Drehimpuls wieder stoppen.
Jango1987
13.07.2009, 19:30
Hi, ich würde das wie mein vorredner auch machen (name unmerkbar).. also du gibst über deinen Computer die Befehle an einen µController, und der macht den rest.
zB. sagst du dem µC also in regelmäßigen intervallen welchen wert welches gelenk haben soll und der µC guckt nun permanent, ob der Wert (den er kinderleicht über seinen Analog-Input bestimmt) kleiner oder größer ist als das soll und steuert die entsprechenden Relais an, um den Wert zu erreichen.
weil bis du die daten digitalisiert und an deinen rechner übergeben hast und der gemerkt hat, dass er den wert erreicht hat, die daten wieder zurücksendet bist du schon zu weit "gefahren".
also eine reine Executive seitens des µC. Alo wenn keine daten vom Computer mehr kommen, fährt er auch die letzte befohlene Position an und hält diese.
Ich habe ja keine ahnung wie langsam der Arm werden soll.. aber Relais sind ein bisschen träge im Pegelwechsel.. denke da eher an Leistungselektronik...
zu der Außlösung: Die meisten µC haben einen Analoginput mit 10Bit.. also Werte von 0-1023
gibt aber auch 16-Bit
Hoffe ich konnte helfen..
Gruß Jango
Matthias1979
13.07.2009, 21:40
Den µC kann man maximal als Schnittstelle zwischen PC und Hardware nutzen.
Der PC "entscheidet" was getan werden soll und sagt dem µC welcher Motor wie lange oder wohin drehen soll.
BurningBen
13.07.2009, 21:52
Das stimmt so nicht, der PC kann auch einfach nen Sollwert vorgeben, und der µC regelt so nach, das der Arm diesen Sollwert auch einhält
Matthias1979
13.07.2009, 23:16
Und was stimmt an meiner Ausage nicht?
Der PC "entscheidet", der µC führt aus.
Jango1987
13.07.2009, 23:24
@ matthias : was an deiner aussage nicht stimmt ist: der PC muss nicht sagen was gemacht wird und wie lange der motor wohin gedreht wird, sondern die winkel vorgeben.. er muss nur sagen, wo die reise hingeht, nicht WIE.
Sogar weiter: man gibt dem µC nur die Karthesischen Koordinaten und er errechnet die winkel und wie lange er welchen motor wohin ansteuert selbst..
der µC kann WEIT aus mehr als nur als Schnittstelle agieren. wie bauen andere leute roboter nur mit µC, ohne PC ?? wenn es nur eine schnittstelle ist?
Gruß Jango
Matthias1979
13.07.2009, 23:42
Der PC "entscheidet", der µC führt aus.
Es geht nicht darum das der PC sagt welcher Motor wie lange dreht, sondern das der PC entscheidet was getan wird und der Controller das ausführt.
Es geht nicht darum ob er Controller irgendwas berechnen soll, sondern das er nicht alles berechnet.
Ich bin eigendlich davon ausgegangen das hier jeder weiß das der Controller auch selbst Dinge wie Kennlinien, Position, ..., berechnen darf. ^^
Jango1987
13.07.2009, 23:44
"Der PC "entscheidet" was getan werden soll und sagt dem µC welcher Motor wie lange oder wohin drehen soll."
deine worte 8-[
Matthias1979
13.07.2009, 23:50
Noch ein Zitat von mir:
Ich bin eigendlich davon ausgegangen das hier jeder weiß das der Controller auch selbst Dinge wie Kennlinien, Position, ..., berechnen darf.
Jango1987
13.07.2009, 23:53
ok, ich sehe schon, du bist ziemlich überzeugt von deiner meinung.. wie auch immer.. ich denke wir haben den Tread schon genug zugespammt..
Im nachfolgenden nur noch neue Beträge und nicht geschriebenes auf die Goldwaage gelegt..
Gruß Jango
Also zurück zum Thema.
Hallo roto,
zu deiner Frage mit dem Poti:
Potis in dem Zusammenhang selbst zu bauen ist Unsinn. Ein Poti ist ein Verschleissteil und man sollte es unkompliziert austauschen können. Man verwendet ein Massenprodukt.
Die Andere Frage ist ja , ob man überhaupt ein Poti verwenden sollte:
Im ganzen RC Bereich werden Potis als Feedbackgeber verwendet und sind für Spielereien in dieser Grössenordnung gut geeignet. Sinnvoll sind die Potis dabei nur, wenn man direkt die analoge Grösse weiterverarbeitet.
In einem Roboterarm, der als Vorstufe für grössere Geräte gebaut wird, sind Potis zu unzuverlässig und zu ungenau. Da sollten digitale Drehhgeber verwendet werden. Zweiter Gesichtspunkt: Wenn man die Potispannung ohnehin digitalisieren müsste, dann sollte man sowieso das Poti sein lassen und gleich einen digitalen Geber verwenden.
grüsse,
Hannes
@ Mathias:
Der PC "entscheidet" was getan werden soll und sagt dem µC welcher Motor wie lange oder wohin drehen soll.
Das ist nur eine von vielen Möglichkeiten. Und oft ist das sogar eine sehr ungünstige. Besser ist oft: Der PC entscheidet, welche Winkel er vor gibt und der MC entscheidet über die Ansteuerung der Motoren.
Du unterscheidest zu Grob zwischen "Entscheiden" und "Ausführen". So kommt man nicht weit.
In Wirklichkeit geht es bei solchen Aufgabenstellungen um hierarchisch geschichtete Entscheidungen. Und es ist von vielen Gesichtspunkten abhängig, wo die einzelnen Ebenen implementiert werden sollen.
Jango1987
14.07.2009, 10:50
@vohopri:
Ich bin ganz deiner Meinung wegen den Potis.. wenn er das sowieso Digital verwerten will, dann lieber einen drehgeber..
@rotober:
einen Drehgeber kannst du ganz einfach aus einer Kugel-Maus ausbauen.. die dinger sind kinderleicht anzuzapfen.
Oder schonmal an Schrittmotoren gedacht? da brauchst du überhaupt kein Feedback vom Arm, weil du dir sicher sein kannst, dass er die Sollposition "anfährt".
Zur Herachie: Da du Informatiker bist, verstehst du sicher die Vorteile eine Kompizierte Anweisung einfach in eine Funktion zu packen, und wenn diese Optimiert ist, braucht man sie ja nur noch X-mal aufrufen. Das selbe mit µC. Sie übernehmen einen mehr oder weniger großen Teil deiner Aufgabe, um den du dich nicht mehr kümmern musst, hast dus einmal optimiert.
Gruß Jango
MeckPommER
14.07.2009, 11:13
... Oder schonmal an Schrittmotoren gedacht? da brauchst du überhaupt kein Feedback vom Arm, weil du dir sicher sein kannst, dass er die Sollposition "anfährt".
Sicherheit aus der Glaskugel ;-)
Schrittmotore liefern dir keine Start- oder Absolutposition. Man kann nur hoffen, das die relativen Bewegungen auch ausgeführt werden und wenn sie Schritte verlieren hast du auch keine Ahnung mehr, wen oder was der Motor grade anfährt. Drehst du nen Schrittmotor zu schnell, zu abrupt oder mit ungünstiger Drehzahl, kann man sich nur sicher sein, das er nie an irgendeiner Sollposition ankommt.
Gruß MeckPommER
Jango1987
14.07.2009, 11:26
Hmm.. da hast du recht.. aber gleiches gilt für digitale Drehgeber.. da hat man auch keine Absolute Referenz. Geht ein Takt verloren, merkt man das auch nicht. Es sei denn, man benutzt eine Codierscheibe..
also bei all diesen relativen Systemen muss man die Position am anfang bestimmen.. weil: Saft Aus-Saft An hat man keine ahnung welchen winkel jetzt das teil hat.
Und da kommen wieder die Analogen Potis ins spiel: Da weiß man das immer recht genau.. Ich meine bei Gleitschichtpotis und einem 10-Bit Analog-Input ist das schon ne Auflösung von ca. 0,264° / bei 16-bit schon 0,00412°
Die Spannungstabilisierung der Referenzspannung ist natürlich eine andere Geschichte..
Ferner: wenn man Drehgeber benutzt braucht man sicher auch Endschalter.
Gruß Jango O:)
021aet04
14.07.2009, 12:14
Drehgeber sind sehr zuverlässig. Wenn die Anlage eingeschalten wird fährt sie auf eine bestimmte Position (Nullposition). Danach weiß sie immer wo der Arm steht. Zusätzlich würde ich immer Not Aus Endschalter einbauen. Ein Poti kann genauso ausfallen wie ein Drehgeber. Der DG braucht immer eine bestimte Anfangsposition, außer Absolutwertgeber. Wenn man ein mehrgängiges Poti (z.B. 10Gang) einsetzt erhöht man auch die Genauigkeit
Zitat von Jango
Hi, ich würde das wie mein vorredner auch machen (name unmerkbar)..
Ich heiße Hannes
Hallo Leute, da hat sich ja einiges getan.
Ich weiß nicht, wieviele von Euch den Quickshot SVI 2000 noch kennen. Das ist das absolute Analogding. Im Grunde nicht geeignet, wenn man was professionelles machen will. Hat eben nur die analogmotoren und wird standartmäßig mit vier Batereien betrieben, von denen je zwei einen +/- und einen -/+ Stromkreis bilden. Soll der Arm nach rechts drehen, wird an dem Motor dern +/- Stromkreis geschlossen, soll er nach links drehen, wird der -/+ geschlossen.
Die Geschwindigkeit ist auch nicht die größte.
Das ganze muss auch nicht supergenau und auf die Millisekunde stimmen.
Jetzt mal angenommen, ich habe einen einigermaßen zeitgemäßen Rechner, der mit Vektorrechnung keine großen Probleme hat, dann sollte ja die reine Kontrolle, ob eine Kollision stattfindet nicht allzuviel Zeit in Anspruch nehmen (werde das wohl mal simulieren um die Laufzeit eines solchen Programmes zu testen).
Was benutzen denn die meisten Standart Atmels (mega8, mega16, mega32) für Kommunikationsgeschwindigkeiten mit der Seriellen (oder auch USB)? Wenn ich mal von 9600 ausgehe und diese dann noch auf 4800 halbiere (wegen Kommunikation in beide Richtungen) dann komme ich immer noch auf 600 Byteworte pro sekunde. Selbst wenn der Overhead 90% ausmachen sollte bleiben immer noch 6 Byteworte für 6 Werte zwischen 0 und 255, die in jeder zehntel Sekunde übertragen werden können. Und eine zehntel Sekunde wäre als Verzögerung vollkommen vertretbar.
Ich möchte halt ungerne gleich den Überindustrieroboterpark bauen sondern einfach in die Materie einsteigen. Und dafür reicht mir für den Anfang eigentlich schon vollkommen aus, einen Potiowert irgendwie zu digitalisieren und über seriell oder usb in ein Programm einzulesen.
Der Schwerpunkt liegt bei mir auch eigentlich in der Überwachung des ganzen über den PC, da ich nicht glaube, dass ein Microprozessor in der Lage sein wird, das System dreidimensional zu überwachen und Kollisionen zu erkennen, der PC wiederum sollte damit keine großen Schwierigkeiten haben.
Um nochmal auf die Potis im eigenbau zurück zu kommen. Es gibt beim Quickshot für die Drehachse leider keine Möglichkeit dort irgendetwie ein standart Drehpoti zu befestigen, da alle Achsdurchmesser, an denen Abnahmemöglichkeiten bestünden, mindestend 7cm betragen. Da sich die Achse um ca. 300Grad drehen lässt, müsste ich entweder ein zigmal überdrehbares Poti haben, oder eine Mehrfachübersetzung ranbasteln. Da fehlt mir aber einfach das Handwerkliche Geschick. Deshalb ja die (geklaute) Idde mit dem Wiederstandsdraht, der um die Achse gelegt wird und dem Schleifer, der an der Achse befestigt wird und simit über den Draht fährt.
Um später geschwindigkeit zu sparen würde ich vielleicht sogar für jedes Poti eine eigene ATiny13 Schaltung basteln, die den Potiwert digitalisiert und fan einen einen größeren mega(8, 16, 32) weiterreicht, der am Ende mit dem Rechner kommuniziert und nur noch im millisekundentakt die Werte übermittelt. Nur, wie und wo ansetzen?
pro poti eine µC ist doch nen bisl overkill....
nimm nen µC mit 3 ADC wenn du drei potis hast. dann hast de alles in einem und viel eleganter. ich würde auch dem µC nur die koordinaten geben udn der µC rechner den rest.... schau dir nen hexabot an der rechner auhc im 3 dimensionalem raum.
Hab da grad zufällig nen Video gefunden.
http://www.i-motor.de/qs_roboarm_demo.mpg
Matthias1979
16.07.2009, 12:39
Roboterarme gibts allen Formen und Farben zu kaufen.
Wie sieht dein Budget aus?
Die zwei Quickshots habe ich bereits. Es muss auch nicht gleich ne Kuka sein (obwohls natürlich geil wäre). Ich möchte ansich einfach nur gerne günstig (wenn auch damit nicht optimal) in die ganze Elektronik, MikroController Materie einsteigen und dafür braucht es kein Super präziser Arm sein. Wichtig ist mir nachwievor, dass ich lerne, die Schnittstellen zur Laufzeit mit dem Rechner abzufragen, berechnungen anzustellen und wiederum eine Reaktion auszulösen. Das ganze muss nicht zwingend millisekunndengenaue Realtime sein. Es muss höchtens im 1/4 bin 1/10 Sekundenbereich liegen. Deshlab halte ich auch noch so sehr an den Potis und der übermittlung eines Digitalwertes fest. Mehr soll mein Kontroller erstmal nicht zu tun habe. Potistellung abfragen und in einen Wert zwischen 0-255 umwandeln und an serielle (oder USB) Schnittstelle übergeben.
Matthias1979
16.07.2009, 14:23
Potis werden für diesen Fall zu ungenau sein.
Dazu hilft die Geometrie.
Längen der Arme und Winkel der Gelenke sind vorgegeben. Damit kann man die Position der Spitze bzw. des Greifers berechnen und mit XYZ-Koordinaten zurückgeben.
Je ungenauer die zurückgegebenen Winkel sind, desto mehr weicht die mathematische Position der Spitze von der reellen Position ab.
256 Inkremente/Umdrehung sind ungenauer als 1024.
http://www.youtube.com/watch?v=sjzlalz3J38
Der Quickshot mit Potis. Diese genauigkeit würde mir vollkommen ausreichen. 1024 statt 256 Schritte ist auch ok, aber wie gesagt, Genauigkeit ist nicht mein derzeitiges Problem. Das wird sich in späteren Projekten noch ändern. Ich möchte nur endlich mit der Elektronik anfangen und das vorhanden Spielzeug nutzen und ein wenig aufwerten.
ich hab da gerade etwas gefunden was dich vllt als poti-ersatz interessieren könnte ;-)
http://www.lenord.de/de/produkte/sensorline/01absolut/Agel235/promotion/nonius/
021aet04
17.07.2009, 09:49
Die sind sicher nicht schlecht, aber wo steht der Preis? Die sind sicher nicht ganz billig. Ich würde normale Drehgeber verwenden. Die haben ein um 90° versetztes Signal (A, B). Die sind auch billiger (glaube ich)
Matthias1979
17.07.2009, 10:55
Bevor du an die Elektronik gehst, schreib erstmal ein Programm, das deine Arme visualisiert. Wenn du später die Winkel aus den Armen ausliest, hast du gleich die passende Visualisierung.
Bin ich grad dran. Spiel momentan noch nen bischen mit Blender rum (muss das auch erstmal noch richtig durchschauen) und wollte mich anschließend mal an die inverse Kinematik machen. Hab also noch bischen Theorie vor mir.
Wenn mir nochmal so ein super Angebote wie diese beiden hier über den Weg laufen
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX:IT&item=260444151952
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&ssPageName=STRK:MEWAX:IT&item=260444152481
werde ich wohl auch ne Garage anmieten. Dann macht die Kollisionserkennung bestimmt gleich doppelt so viel Spaß (oh man, die Teile können bestimmt töten).
Leider muss ich das Projekt nun doch aus Zeitmangel wieder aufgeben und gebe daher die beiden Quickshot her. Wenn also interesse besteht:
http://cgi.ebay.de/Quickshot-SVI-2000-Robotarm-Roboterarm_W0QQitemZ120468279506QQcmdZViewItemQQpt ZSpielzeugroboter?hash=item1c0c7810d2&_trksid=p3286.c0.m14
http://cgi.ebay.de/Quickshot-SVI-2000-Robotarm-Roboterarm_W0QQitemZ120468274533QQcmdZViewItemQQpt ZSpielzeugroboter?hash=item1c0c77fd65&_trksid=p3286.c0.m14
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.