Roboterarm mit einem Kinect Sensor V2 steuern.

[Unregistriert]

Danke i_make_it schonmal für die Antwort.

Wir machen eine Fortbildung zum staatlich geprüften Techniker für Elektrotechnik mit der Fachrichtung Energietechnik und Prozessautomatisierung.
Das Thema der Facharbeit mussten wir uns selber überlegen.
Um es mal mit den schwammigen Aussagen unserer Lehrer zu sagen: Wir müssen das Rad nicht neu erfinden. Allerdings einfach nur ein komplett fertiges Programm zu benutzen wird wohl nicht ausreichen und entspricht auch nicht unseren Vorstellungen.
Die Note für die Facharbeit wird im Zeugnis seperat aufgeführt und fließt in kein Fach mit hinein. Um so mehr wir dabei selber entwickeln bzw. verbessern um so besser wird die Note ^^
Den Roboterarm müssen wir auch nicht selbst entwerfen und wir können auch auf schon bestehende Programmcodes zurückgreifen.
Momentan überlegen wir, ob wir unsere Arbeit aufteilen und einer sich um den Kinect-Sensor kümmert und der Andere um den Roboterarm.
Ab Februar haben wir 1 Tag in der Woche komplett für die Facharbeit frei. Neben der Schule haben wir das Glück, dass wir nicht noch Geld verdienen müssen und somit einen Großteil unserer Freizeit dafür nutzen können. Dabei wäre es sicherlich realistisch nochmal 10-20 h / Woche aufbringen zu können.

Momentan sieht die Planung folgendermaßen aus:
1. Kinect-Sensor am PC anschließen (mit dem V2 relativ schnell erledigt)
2. die Daten des Sensors auswerten (hier stecken wir gerade fest)
3. die Daten zum Weitersenden umwandeln
4. die Daten an einen Microcontroller (wobei ich noch überlege einen Raspberry Pi anstelle des Microcontrollers zu nehmen) übermitteln
5. mit dem Microcontroller den Roboter ansteuern
6. wenn noch Zeit über ist möchte ich neben dem Folgemodus auch einen Modus zum selbstständigen Wiederholen hinzufügen (quasi einen Bewegungsablauf speichern und selbstständig wiederholen)

Zu Schritt 2:
Meines erachtens brauchen wir dabei "nur" die Daten von der Skeletontracking-Funktion, aber ich erkenne in den Beispielprogrammen nicht wo die Achsen der Joints berechnet werden, dazu müsste ich mich vermutlich noch ein wenig mehr mit der API oder mit dem grundliegenden Verständnis von C# bzw. Programmen beschäftigen, mir fehlt irgendwie eine vernünftige Übersicht wo die wichtigsten Variablen dafür enthalten sind. Am schönsten wäre es eine Art x,y,z, Koordinate der Hand geliefert zu bekommen, ich denke damit könnte man gut weiterarbeiten.

[i_make_it]

Am schönsten wäre es eine Art x,y,z, Koordinate der Hand geliefert zu bekommen, ich denke damit könnte man gut weiterarbeiten.

Ganz so einfach ist es leider nicht.

Schau dir mal die Links an. (den ersten mit dem Buch habe ich drin, da es nur 9€ kostet)

https://www.dpunkt.de/buecher/4140.html

https://www.uni-trier.de/fileadmin/u...40/csharp4.pdf

http://research.microsoft.com/pubs/1...ecognition.pdf

http://research.microsoft.com/en-us/projects/handpose/

http://research.microsoft.com/apps/p...aspx?id=238453

[Nielsemann]

Vielen dank für die ganzen Links schonmal. Bin das alles mal überflogen. Sind schonmal paar gute Sachen dabei. Für die PDF der Uni-Trier brauche ich wohl noch ein wenig länger

Das Buch zum Kinect-Sensor vom dpunkt-Verlag behandelt ja noch den älteren Sensor der X-Box 360, sind denn Befehle einfach auf den neuen Sensor zu übertragen ?

Zum Thema raspberry, macht es überhaupt Sinn, in Anbetracht der kurzen Zeit sich damit noch zu befassen ?

Und kannst du / bzw. jemand Anderes zum Kauf des Arexx Metall-Roboterarm RA1-PRO raten ?

[malthy]

Hey,

wenn die inverse Kinematik für den Arm steht, ihr Eurem Roboterarm also x-, y- und z-Koordinate des TCP sagen könnt und er diese dann anfährt, ist die Sache - zumindest in der rudimentärsten Form - eigentlich nicht so schwierig. Ich habe nur relativ kurz mal mit der Kinect rumgespielt, aber die x-, y- und z-Koordinate z.B. des Handgelenkes bekommt man ohne große Umwege in physikalischen Einheiten aus dem Skeleton-Tracking. Im einfachsten Falle steckt man diese direkt in die IK. An dieser Stelle kann man die Dinge natürlich verfeinern, aber im Prinzip macht das System dann schon, was Du oben beschrieben hast. Mach Dir aber keine Illusionen über die Genauigkeit des Skeleton-Trackings der Kinect, oben in dem Video verwenden sie eine Leap Motion, das ist etwas anderes! Ich habe nur mit der ersten Kinect gearbeitet, ob die zweite (anderes physikalisches Sensorprinzip) deutlich genauer ist, weiß ich nicht.

Ich habe sowas ähnliches mal auf die Schnelle mit meinem Delta-Roboter gemacht, in dem folgenden kleinen Video sieht man wie "gut" (= schlecht) das geht. Ich habe die Koordinaten deutlich gefiltert, deswegen hat das System einen ziemlichen Lag, sonst wäre die Sache zu unruhig (verrauscht) geworden. (Sorry für die stellenweise miese Videoqualität.)



Gruß
Malte

[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