Offline Programmierung

Guten Tag

Ich Arbeite im Bereich der Biomechanik und wir haben seit neuem einen KUKA Quantec mit RSI (RobotSensorInterface) / FTC (ForceTorqueControl). Wir arbeiten im Bereich Forschung und Entwicklung und wollen mit dem Roboter gezielte Bewegungen von Gelenkstrukturen (Knie, Wirbelsäule, Schulter etc.) durchführen und dabei diverse Daten aufzeichnen (Kräfte, Momente, Bewegungsumfang etc.)
In der Praxis wir das schon häufig gemacht. Beispielsweise werden Tests an Knien mit Industrierobotern durchgeführt, wobei das vom Roboter geführte Knie auf dem PassivePath bewegt wird..sprich es wird eine kraft- und momentengeregelte Bahn gefahren, bei dem das Knie möglichst wenig "Belastung" spürt.

Ich habe nun zum Einstieg den Kurs Roboterprogrammierung 1 besucht und dabei schnell gemerkt, das wir mit dem vermittelten Stoff nur sehr beschränkt arbeiten können, da wir sehr viel mit Date aus Bewegungsanalysen arbeiten werden. Mit den Inline-Formularen und allgemein der Bedienung am SmartPad kommen wir da schnell an die Grenzen. Daher stellt sich die Frage, ob wir mit WorkVisual oder einer anderen Offline-Programmierungssoftware glücklich werden.

Ziel ist es grundsätzlich, das wir die Programmierung direkt am PC mittels der Inputs aus anderer Software schreiben können. Danach sollen die Programme per Ethernet an die Steuerung geschickt werden. Optimal wäre auch eine Schnittstelle um Sensordaten "live" während einem Programmablauf am PC ausgeben zu können. Eine virtuelle Umgeben ala Robot Studio braucht es nicht zwingend. Leider finde ich zu WorkVisual nur sehr wenig Informationen...daher wäre ich froh wenn mir jemand der damit arbeitet etwas zu den Möglichkeiten der Software sagen könnte.

Gäbe es denn ein Softwaretool mit welchen wir in diesem Bereich etwas sinnvolles Anfangen können? Oder kommen wir nicht drum rum unsere Tools selbst zu Programmieren?

Momenten finde ich es allgemein sehr schwierig mit dem ganzen System (FTCtrl, RSI etc.) zu arbeiten, da die Dokumentationen teils sehr zu wünschen übrig lassen. Learning by doing ist angesagt aber das ist alles andere als effizient und ohne Hilfestellung für mich meist nicht zu bewältigen.

Zitat von Twister

Hallo dene,

für mich hört sich das an als ob ihr einen anderen Roboter benötigt.
Ihr wollt immerhin dass der Roboter direkt im Kontakt mit dem Menschen ist.

Da hast du was falsch verstanden. Wir bewegen nicht direkt das Knie eines lebenden Menschen, sondern Kadaverpräparate oder künstliche Kniemodelle. Also der Roboter ist nicht mit Menschen direkt in Kontakt.

Zitat von marvin42

Alternativ, so machen das auch andere, kann man RSI aktivieren, den Roboter mit einem Nullsatz in die Regelung schicken, und dann die Maschine quasi per RSI "fernsteuern" - dh. der Roboter selbst schaltet nur die Antriebe ein, ihr sendet dann über Ethernet entsprechende Sensor-Korrekturen und bewegt so den Roboter von außen - aber VORSICHT : in diesem Fall werden ggf. Filter etc. umgangen, dh. eure Software muß auch entsprechende Beschleunigungs- und Bremsrampen berechnen, sonst steckt der Roboter schneller im Tisch oder Boden als ihr gucken könnt...

Ich denke in diese Richtung sollte es schlussendlich gehen. Jedoch scheinen hier die Unterlagen von KUKA nur sehr schmal auszufallen. Ich habe letzte Woche jedenfalls mal versucht die Ethernet-Schnittstelle zum laufen zu kriegen und bin hier schon gescheitert. Das Problem ist, ich sehe nicht mal wo das Problem genau liegen könnte. Anpingen funktioniert jedenfalls schonmal nicht obwohl ich mich bereits mit der Vergabe der Korrekten IP und Subnetmask beschäftigt habe.

Mir ist auch noch die Software OrangeEdit in die Hände gefallen, welche grundsätzlich auch interessant aussieht...jedenfalls fürs erste. Aber auch da fehlt jegliche Dokumentation. Habe mal kurz Versucht ein im OrangeEdit erstellte Routine auf die KRC4 zu laden und auszuführen, doch beim ersten Bewegungssatz läuft der Robi mir in einen Softwareendschalter, obwohl er sich keinen Millimeter von der Home-Position bewegt hat.

Naja da Frag ich mich einwenig. Habe mir einen netten Punkt von Hand im Arbeitsraum angefahren und die Koordinaten / Orientierungen notiert und dann direkt in OrangeEdit übertragen....Tool und Base natürlich berücksichtigt! In OrangeEdit selbst habe ich drauf geachtet, dass der Bewegungsbefehl aus der richten Softwareversion genommen wird, da dies anscheinend auch zu Problemen führen kann. Die SAK zur Home-Position macht er anstandslos, jedoch wir der nächste Punkt nicht angefahren. Relativbewegungen funktionieren hingegen einwandfrei.

Quittiermeldung: "Unerreichbarer Punkt Softwareendschalter +A2"

Danke für den Hinweis...hatte diese 2 Begriffe noch im Kopf aber im Grundkurs wurde da ein eher grosser Bogen drum gemacht, da es für die meisten Anwendungen ja nicht relevant ist. Natürlich nicht so bei uns. Trotzdem bin ich etwas verwundert, da die Distanz und Achskonfiguration zwischen Home und meinem Testpunkt nicht sehr abenteuerlich sind und ich einen Softwareendschalter daher nicht erwartet habe.

Nun habe ich auch die Status und Turnwerte nach dem Handverfahren mal ausgelesen und in der OrangeEdit Routine berücksichtigt. Interessant ist, dass er mir jetzt die A4 beginnt zu drehen, obwohl es nicht nötig ist. Kann mir momentan nicht vorstellen das ich so effizient programmieren kann, wenn ich jedesmal noch die einzelnen Bit's für S und T setzen muss.

Ja ich komme halt aus der Home Position, welche in einer Handsingularität steht, was ich persönlich immer noch nicht verstehe wieso das standardmässig von Kuka so gegeben ist. Klar kann die Home umprogrammieren aber trotzdem frag ich mich, wieso man diese Stellung gewählt hat.

Ich denke ich werde einfach mal einwenig rumspielen. Vielleicht werd ich mal noch schlau aus dem Problem aber schön ist jetzt mal, das die offline programmierten Routinen grundsätzlich laufen. Dafür schon mal ein herzliches Dankeschön

Beruhigt mich insofern, das meine Überlegung schon richtig ist. Aber verstehs schon, das solche Dinge immer schwierig sind einfach so von heute auf morgen umzustellen. Werde aber wohl unsere Home demnach umprogrammieren, damit wenigstens bei uns sich dieser Standard durchsetzt.

Zitat von dene

Ich habe letzte Woche jedenfalls mal versucht die Ethernet-Schnittstelle zum laufen zu kriegen und bin hier schon gescheitert. Das Problem ist, ich sehe nicht mal wo das Problem genau liegen könnte. Anpingen funktioniert jedenfalls schonmal nicht obwohl ich mich bereits mit der Vergabe der Korrekten IP und Subnetmask beschäftigt habe.

Inzwischen habe ich einen Fehler gefunden, warum selbst Pingen vom Laptop aus nicht funktioniert hat. Der X66 war am eingang KONI und nicht am KLI angeschlossen, da dort der Kraft-Momenten-Sensor eingesetzt war. Da ich diesen aber für die grundsätzliche Kommunikation von Laptop und KRC nicht brauche habe ich das ganze umgesteckt und siehe da, ich kann vom Laptop aus das RSI-Netzwerk pingen.
Problem ist auf die andere Seite. Wenn ich versuche den Laptop vom smartPad (Windowsoberfläche!) zu pingen, erhalte ich keine Antwort bzw. die Meldung "Request timed out". Woran kann das nun liegen? Zur Sicherheit habe ich auch mal die Firewall sowie WLan ausgeschaltet aber das hilft nichts und sollte auf den Pingtest sowieso keinen Einfluss haben. Im Anhang sehr ihr die Meldung im Testserverprogramm aus dem Ethernet-Beispiel, welches mit dem RSI geliefert wird.

Und noch eine Frage zum Testserverprogramm....sehe ich das richtig, das ich mit den Buttons (X,Y,Z,A,B,C) bei erfolgreicher Verbindung den Robi fernsteuern kann? Irgendwie ist mir noch nicht so wirklich klar, was mein "Sensor" ist. Bin etwas vorsichtig mit ausprobiere, da ich nicht die ganze Bude aufgrund einer unvorhergesehener Bewegung zerlegen will