Roboterarm mit einem Kinect Sensor V2 steuern.

[Nielsemann]

Hallo Malte, dein Video kannte ich bereits, tolle Sache. Ursprünglich wollten wir auch einen Deltabot nutzen. Was bei dem neuen Sensor auf jeden Fall relativ einfach gemacht wurde ist das der Sensor jetzt Hand.Open und Hand.Closed erkennt und man damit relativ leicht das "Greifen" realisieren kann. Wenn ich so etwas wie "kurz mal rumgespielt" und "auf die schnelle" lese werde ich direkt neidisch, bzw. komme mir echt blöd vor Die inverse Kinematik von der du sprichst ist ja für den Roboter, damit er weiß wo er hin soll, oder ? Ich hatte gehofft, dass man da, für einen fertigen Roboterarm, im Netz ein paar brauchbare Quellcodes findet und nutzen kann und sich dann daran orientieren könnte.

[malthy]

Hi,

Was bei dem neuen Sensor auf jeden Fall relativ einfach gemacht wurde ist das der Sensor jetzt Hand.Open und Hand.Closed erkennt und man damit relativ leicht das "Greifen" realisieren kann.

okay, kann durchaus sein dass die neue Kinect besser ist, da habe ich keine Erfahrung.

Wenn ich so etwas wie "kurz mal rumgespielt" und "auf die schnelle" lese werde ich direkt neidisch, bzw. komme mir echt blöd vor

Sorry wenn's überheblich klang, so war es bestimmt nicht gemeint. Ich wollte nur zum Ausdruck bringen, dass das was ich da gebastelt habe wirklich nur die erste Annährung an das Thema ist und ich nun wirklich nicht behaupten möchte, dass das der Weisheit letzter Schluss ist - alles andere ...

Die inverse Kinematik von der du sprichst ist ja für den Roboter, damit er weiß wo er hin soll, oder ?

Korrekt. Du sagst dem System wo es - typischerweise der TCP/Endeffektor - in einem definierten Koordinatensystem hin soll, über die IK wird dann berechnet wie die einzelnen Freiheitsgrade des Systems einzustellen sind, damit die "Hand" (oder was auch immer) des Roboters auch tatsächlich da landet. Selbst bei relativ einfachen Kinematiken kommt es relativ schnell zu Mehrdeutigkeiten, d.h. mehreren Möglichkeiten eine Koordinate des TCPs zu erreichen. Das ist zwar praktisch wertvoll, macht die Sache aber mathematisch u. U. etwas haarig.

Ich hatte gehofft, dass man da, für einen fertigen Roboterarm, im Netz ein paar brauchbare Quellcodes findet und nutzen kann und sich dann daran orientieren könnte.

Das kann durchaus sein. Wenn Ihr wißt dass Ihr die IK nicht selbst machen wollt, würde ich an Eurer Stelle direkt bei der Auswahl eines Arms schon darauf achten, dass eine IK verfügbar ist. Das ist mal das mindestete was Ihr für das Projekt braucht.

Gruß
Malte

[Nielsemann]

Moin zusammen.
Wir haben uns jetzt mitlerweile einen kleinen Roboterarm von Arexx gekauft (den RA1-PRO) und haben auch ein paar Handkoordinaten mit dem Kinectsensor aus einem von uns etwas angepassten C#-Beispielprogramm auslesen können, die wir jetzt zu einfachen Bewegungen, wie oben, unten, links drehen, rechts drehen, Greifer auf und Greifer zu weiterverarbeiten wollen. Den Roboter mit Hilfe des Microcontrollers zu bewegen funktioniert soweit auch einigermaßen. Mit inverser Kinematik mussten wir uns bis jetzt noch nicht auseinandersetzen, da wir dem Microcontroller nur einfache Befehle wie servo_x auf Position_xxx mit Geschwindigkeit_xx mitteilen können. Nun stehen wir vor dem Problem, wie wir die Daten vom PC, quasi in Echtzeit am besten an den Microcontroller des Roboters übermitteln. Am liebsten wäre mir per USB. Hab aber im Moment keinen Plan wie ich das in C# reinprogrammieren kann. Habt ihr vielleicht Vorschläge (einfache) ?
@ Malte - welche Daten vom Kinectsensor hast du für die Steuerung verwendet ? Und wie hast du die Daten an deinen Roboter übermittelt ?
Ps.: Sry für die langen Schachtelsätze...

[malthy]

Hi,

@ Malte - welche Daten vom Kinectsensor hast du für die Steuerung verwendet ? Und wie hast du die Daten an deinen Roboter übermittelt ?
Ps.: Sry für die langen Schachtelsätze...

Ich hab den Code auf die Schnelle nicht gefunden, deswegen nur aus der Erinnerung: das Skeleton Tracking gibt entweder eine 3D-Koordinate für die Hand oder zumindest für das Handgelenk aus. Die hab ich genommen, elementweise Tiefpass-gefiltert (vermutlich einfacher IIR Filter) und dann direkt an den Delta weitergegeben. Der Delta hing per UART (RS232) am Rechner. COM Ports sind in den meisten Programmiersprachen problemlos zugänglich, so auch in C#. Was man als "Echtzeit" bezeichnet, ist eine Definitionsfrage. Mit RS232 erreicht man auf modernen Rechnern unter Windows und Linux (nicht RT) meiner Erfahrung nach kein besseres Timing als mit einem virtuellen COM Port über USB. Im normalen Betrieb kommen da ohne weiteres mal bis zu 20 ms Latenz zustande. Da USB nur gepollt wird (und die serielle Schnittstelle anscheinend auch, das weiß ich aber nicht sicher), kann es bei einem System, das viel zu tun hat, auch zu größeren Latenzen kommen. Die 20 ms sind für eine Anwendung wie Deine (und meine damals auch) aber durchaus verkraftbar, würde ich behaupten.

Gruß
Malte