Hallo,
Dafür gibt es den Befehl "Trigger". Z.B.:
Trigger when distance=100 delay=0 do ausgang1=true
Um das auf der Hälfte vom Weg zumachen kannst du dir ja über Pythagoras die Länge ausrechnen, halbieren und mit distance vergleichen.
Gruss
lambert
I tried it with your commands. I think the position we get back are correct. It is A+20 and B+0. But all values (A, B, C) are affected. Because there are many ways to describe one position. If you calculate the (rotation) matrix you will see that your new position is the result of A=A+20 and B=B+0.
Are you driving in the base- or the tool-coordinate-system?
What are the values on Q and W?
- eine rotationsmatrix aus den drei elementaren matritzen zusammenmultiplizieren
- diese gesamtmatrix beschreibt nun die drehun, mit dieser lassen sich vektoren in ein neues koord. drehen
Ich würde sagen: Ja.
- dann 3 Vektoren der koordinatenachsen mit der gesammt- rot- matrix um die angezeigten eulerwinkel drehen..
- dann die 3 entstandenen vektoren nutzen um die winkel im neuen koord.sys auszurechnen..das sind dann die festen winkel?
Das verstehe ich nicht ganz. Nach deinen ersten zwei Schritten hast du ja eine Matrix die dir die Orientierung deines neuen Koordinatensystems beschreibt. Was willst du nun machen?
nur wie zurücktransformieren in eulerwinkel, muss ich nochmal überlegen...
Bei der Formel von "R" siehst du ja oben rechts, dass da ein einzelnes "-sin(Teta y)" steht. Damit hast du schonmal "A". Dann kannst du durch einsetzen in "cos(Teta y)*cos(Teta z)" und "cos(Teta x)*cos(Teta y)" die anderen beiden Winkel ausrechnen.
Ähhmmmm,... haben die Quaternion wirklich etwas damit zu tun? Ich habe dashier gerade bei Wikipedia nachgelesen:
"Die Quaternionen entstehen aus den reellen Zahlen durch Hinzufügung dreier neuer Zahlen i, j und k. So ergibt sich in Analogie zu den Komplexen Zahlen ein vierdimensionales Zahlensystem mit einem eindimensionalen Realteil und einem dreidimensionalen Imaginärteil, der auch Vektoranteil genannt wird."
Ich würde sagen Quaternion sind eine weitere Darstellungsform neben der Rotationsmatrix.
- ich hab doch vom Robo drei Winkel, aus diesen muss ich ja einen, oder gar 2 Vektoren machen (weil ein Vekt reicht ja nicht aus, weil die drehung um ihn selbst nicht erfasst ist), welche ich dann mit der Gesammt-Drehmatrix multipliziere...dafür muss ich eine funktion schreiben, mit der ich winkel zu vektor machen kann..
Ist schon etwas länger her bei mir, aber ich glaube du suchst das hier: http://kos.informatik.uni-osna…wnload/diplom/node26.html
Da ist beschrieben wie du die Eulerwinkel einsetzt um die Rotationsmatrix zu bekommen.
Ich würde mich neben dem Visionsystem vor allem mit IMUs auseinandersetzten. Bei einer so sicherheitskritischen Anwendung würde ich mich nicht allein auf ein Visionsystem verlassen.
Die PMD-Kameras finde ich vom Prinzip her auch ziemlich cool. Aber die haben eine unterirdische Auflösung. Da ist ja das maximum 204x204, oder? Wenn du damit einen Bereich von 50x50cm abdecken willst hast du ja gerade mal eine Auflösung von 2,45mm/Pixel. Also hat man eine Messunsicherheit von ca. 1,2mm (und das nur von der Kamera). Wenn du mit der Kamera überhaupt einen so großen Abstand vom Objekt haben darfst.
Urmel: Würde mich auch interessieren. Wie weit darf man denn mit den Kameras vom Messobjekt entfernt sein?
Also wenn die Anwendung keine Echtzeit erfordert würde ich die KRL-XML erfordern. Die ist ziemlich einfach zu programmieren und kosten nicht so viel wie die RSI-XML. Damit übernehmen wir auch die Daten von einer Sensorauswerteinheit.
QuoteAngeblich werden bei nicht absolutgenaue Roboter mit Nennlast Abweichungen bis zu 10 mm Abweichung gemessen (KUKA verwendet Metris-Kameras als Meßsystem). Absolutgenaue Roboter sollten dann laut der Daumenregel maximale Abweichungen von 1 mm haben, oder?
Zumindest würde das erklären warum sie es nicht in die Datenblätter schreiben. 
Dieser Fehler ist dann aber immer gleich, oder? Also wenn ich dem Roboter sage fahre zu Position (5,5,5) fährt er z.B. zu (4,5,5). Dafür fährt er dann anstatt (8,8,8) auch auf (7,8,8), oder?
QuoteTeach den Punkt ZIELPOS doch einfach.
So wie ich das verstehe möchte er flexibel auf die jeweilige Position reagieren. Wenn er den Punkt teacht müsste er bei jeder neuen Palette Punkt P5 und Zielpos neu teachen.
Hast du die Variable denn deklariert?
Ansonsten kannst du auch an der Stelle wo der Fehler auftritt und der Roboter nicht mehr weiter fährt in dem Variablen-Menü mal die Variable $POS_ACT abfragen. Dann weißt du wenigstens ob damit alles in Ordnung ist.
Ich dachte, dass HAs nur besser in der Wiederholgenauigkeit wären, und in der absoluten Position keine Verbesserung bringen. Kuka gibt die absolut Positionstoleranz auch nie an. Mir wurde bei einem Anruf sogar mal gesagt, dass es die nicht gibt (also das ist wohl blödsinn gewesen). Aber es wird in den Datenblätern auch nicht erwähnt. Aber laut Datenblättern bringt der HA auch nur 0,05mm Verbesserung gegenüber dem Standard.
QuoteDen Fehler der Roboterpositionsgeber rausrechnen? Diese sind doch dynamisch und daher nicht immer konstant oder?
Ja, hast recht. Ich hatte kurz mal überlegt ob man den Fehler rausbekommt wenn man die Abweichung als normal verteilt annimmt. Aber das wäre vielleicht etwas gewagt.
Kann man den Strahlenmittelpunkt nicht einfach rausfinden in dem man den Flächenschwerpunkt auf einem Fotosensor berechnet?
Oh. Das hört sich gut an. Dann kann man die Berechnung auch automatisieren. Ich würde es aber trotzdem mit meinem Vorschlag kombinieren. Man müsste sich mal überlegen ob man damit nicht auch den Fehler rausrechnen kann, den die Roboter-Positiongeber verursachen. Habt ihr einen HA-Roboter?
Ja, Herr Hochholzer hat Recht. Denn eigentlich ist es so einfach das man die Drehungen hintereinander ausführt. Eine richtige Matrixtransformation bräuchtest du eigentlich nur wenn du die Koordinaten der Greiferkoordinatensystem-Ursprünge bzgl. deines Flanschkoordinatensystems wüsstest und dieses auch noch verschoben wäre.
Die Frage zielt ja nicht darauf ab wie man von absoluten Winkeln auf Euler-Winkel kommt, oder? Also so was wie: Ich sehe das die Z-Achse-2 gegebnüber Z-Achse-1 um 45° verdreht ist und das die Y-Achse-2 gegenüber der Y-Achse-1 um 30° verdreht ist. Ich würde sagen die Winkel könnte man nicht einfach eingeben. Die müsste man erst in Euler-Winkel umrechnen.
Du weißt aber doch um wieviel Grad die Achsen gedreht sind. Warum gibst du nicht ganau das bei deinem Toolvermessen ein? Ich schätze ich verstehe es immer noch falsch. Welche Koordinaten bzgl. welcher Koordinatensysteme kennst du denn?
Ich habs noch nicht ganz verstanden. Du willst das Greiferkoordinatensystem und den TCP bestimmen. Der Ursprüngliche TCP befindet sich ja im Mittelpunkt der Flanschplatte. Möchtest du nun wissen wie du dieses Koordinatensystem in eines der Greiferkoordinatensysteme transformierst?
