Zitierenok, 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
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.
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:
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.Der PC "entscheidet" was getan werden soll und sagt dem µC welcher Motor wie lange oder wohin drehen soll.
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.
@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
Sicherheit aus der GlaskugelZitat von Jango1987
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
Mein Hexapod im Detail auf www.vreal.de
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
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 JangoIch heiße HannesHi, ich würde das wie mein vorredner auch machen (name unmerkbar)..
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
Berechtigungen
Lesezeichen