Roboterarm mit einem Kinect Sensor V2 steuern.

[Nielsemann]

Hallo liebe Community,

mein Name ist Niels und ich befinde mich gerade in einer Fortbildung zum Techniker. Am Ende (Abgabetermin ist im Mai 2016) muss ich eine Facharbeit abgeben. Ich habe vor (mit einem Klassenkameraden zusammen) einen Roboterarm mit Hilfe eines Kinect-Sensors zu steuern. Da wir aber relativ schnell bemerkt haben, dass unsere Kenntnisse im Bereich Programmieren doch sehr begrenzt sind und eine intensive Internetrecherche uns auch nur sehr langsam bis garnicht vorran bringt dachte ich mir ich such mal ein Internetforum, was uns vielleicht weiterhelfen kann. (ja wir sind ein wenig verzweifelt )

Nachdem wir mitlerweile den Kinect-Sensor, mit Hilfe des Adapters von Microsoft, an einen Windows-PC angeschlossen bekommen haben und die Beispielprogramme des SDK2.0 durchprobiert haben, sind wir jetzt an den Punkt angekommen, an dem wir rausfinden wollen, wie wir die Daten von dem Sensor in einem Programm (wir arbeiten momentan mit Visual-Studio 2015) erfassen können und an einen Roboter weitergeben können. Unsere Kenntnisse in C# und C sind gefühlt auf Anfängerniveau ^^ . Außerdem wissen wir noch nicht genau welchen Roboterarm wir benutzen sollten. Wir finden den Arexx Metall-Roboterarm RA1-PRO ganz gut ( https://www.conrad.de/de/arexx-metal...omSuggest=true ), sind aber offen für alle Vorschläge. Preislich sollte es sich aber auf etwa diesem Level abspielen.

Fertig sollte das Ganze dann in etwa so: https://www.youtube.com/watch?v=VGpHEU82JuM aussehen

Was haltet ihr von diesem Vorhaben ?

Wir sind für alle Tipps und Informationsquellen (möglichst in deustcher oder englischer Sprache), dankbar.

Ps.: Ich hoffe der Post ist im richtigen Bereich gelandet.

MFG, Niels.

[i_make_it]

Zuerst würde mich mal interessieren was für ein Techniker.
Also ich zum Beispiel bin unter anderem staatlich geprüfter Techniker Fachrichtung Maschinenbau, SPS Techniker nach VDMA-ZVEI und ReFa Techniker.
Die ersten beiden gehen zumindest entfernt in den Bereich Robotik.
Trotzdem könnte ich das mit dem da gelernten nicht.

Und aus der Beschreibung geht ja hervor das die C# Fähigkeiten in den Anfängen stecken.
Also in in maximal 140 Tagen, objektorientierte Programmierung in C# erlernen, Bilderverarbeitung und Objekterkennung, Inverse Kinnematik, und noch ein paar andere Kleinigkeiten.
Das ist mutig.

Bei meinem staatlichen Techniker waren alle Projektaufgaben vorgegeben und das Abschlußprojekt floss mit 25% in die schriftliche Note ein.
Sollte das mit der Note bei euch auch so sein, würde ich das Risiko einer 6 scheuen und ein Projekt wählen wo ich zumindest die Werkzeuge schon behersche.

Das 7Bot Team besteht übrigens aus 7 Personen und der Schwerpunkt der Entwicklung lag auf der Software.
Deren Kickstarter Projekt hat meines Wissens begonnen nachdem die schon 4 Prototypen gebaut hatten und ihre Software schon funktionierte. Wie viele von den 7 programmiert haben weis ich nicht auch nicht wie viele Mannstunden da rein gingen. Nur beim Tennisball balancieren haben die geschrieben das alle 7 drann waren und eine Menge Überstunden geschoben haben.

Ich empfehle, macht mal einen groben Projektplan () welche Tasks sind zu erledigen) und wieviel Zeit neben Weiterbildung, Hausaufgaben und was noch so ansteht überhaupt zur Verfügung steht. Wenn man auf der Grundlage dann das Projektthema wechseln will weil die Zeit nicht reicht, sollte das auch positiv bewertet werden, da man frühzeitig eine Aufgaben und Resourcenplanung durchgeführt hat und erkannt hat das es da ein Problem gibt.

[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