Beiträge von dene

Hallo Zusammen,

Inzwischen steht das Netzwerk etwa so wie ich mir das vorgestellt habe. Ich habe volle Kommunikation zwischen externem Laptop, KRC und ATI. Das Ethernet Beispiel, welches mit RSI geliefert wurde hat auch geklappt.

Nun wollte ich als nächsten Schritt die Kraft- und Momentendaten des Sensors an den externen Laptop übertragen, die wir in der späteren Anwendung eine Live Visualisierung dieser Daten benötigen. Dazu wollte ich den Testserver missbrauchen, und durch die Definition eines neuen Datenflusses in RSI Visual Shell die XML-Packete an den Testserver senden.

Dazu habe ich folgenden Datenfluss definiert:

Die Ethernet Config sieht wie folgt aus:

Und zum Schluss der gestartete Server:

Für das Programm habe ich den Inhalt des Ethernet.src genommen und einfach die Config-Datei beim Erstellen des RSI Objektes angepasst. Alle nötigen Files wurden wie gewohnt im SensorInferace-Ordner auf der KRC abgelegt, doch leider kommt so beim erstellen des RSI-Objektes ein Fehler.

Sieht jemand per Ferndiagnose, wo das Problem liegen könnte?

EDIT: Wieder ein Erfolg...die Sensordaten werden nun auf den Testserver übertragen! Problem war die XML-Struktur in der Ethernet_Config. Es waren zwingend die Tags für die Received-Elements einzutragen, auch wenn ich nur eine Abfrage mache. Erstelle ich in der XML-Config leere Gruppen für die Received-Elements funktioniert alles so wie gewünscht.

UPDATE:
Es ist geschafft! Wiedermal war das Problem wohl das naheliegenste, welches man sich überhaupt vorstellen kann. Die Windows-Firewall hat mir die Datenpackete vom Laptop an die KRC geblockt! Nun bekomme ich eine saubere Kommunikation von Roboter und Laptop, der Testserver zeigt mir gesendete und empfangene Daten und ich kann inkrementell Verfahren....jedenfalls hat sich der KUKA kurz bewegt. Die Bewegungen sind aber enorm abrupt sodass ich mich hier nicht traue extrem rumzuspielen =)

Wie dem auf sei, die Verbindung steht und es scheint zu funktionieren. Hoffe das vielleicht auch andere von den hier beschriebenen Problemen profitieren können.

UPDATE:
Ich habe mal den Datenfluss mit Wireshark getrackt und es scheint so, als ob von der Robotersteuerung Datenpackete gesendet werden, jedoch keine Antwort vom externen PC an die KRC gesendet wird. Dies kann ich auch dem Logfile entnehmen was dann jeweils zu einem "RSITimeout" führt.

Ich hoffe wirklich jemand kann mir da etwas helfen, da ich gerne etwas vorankommen würde.

UPDATE:
Kleiner Fortschritt...die Serverapplikation läuft nachdem ich mal einige Updates (unter anderem .Netframe 3.5) auf dem externen Laptop installiert und mit dem Kartenindex rumgespielt habe.

Nun bekomme ich vom TestServer die IP des Laptops, trage die im EthernetConfig.xml ein und der TestServer meldet "Server ready to receive and send UDP packets". Gemäss Manual sollten ja nun sensorgeführte Bewegungen aus den Beispieldatein (Source-Files) möglich sein.

Starte ich nun beispielsweise das "RSI_Ethernet.src" komme ich bis zum Satz 31:

ret = RSI_MOVECORR()

gefolgt von folgenden Fehlern

"Signalfluss (running): Objekt EHTERNET1 liefert Fehler RSITimeout"
"Stopp durch $CORRECTION-Funktionalität (Reset oder Satzanwahl erforderlich)".

Und was nun?

Verstehe ich das Richtig, das mir der TestServer durch die Buttons (X,Y,Z,A,B,C) die relativen Korrekturwerte, also die sensorgeführte Bewegung, steuert und durch den Satz RSI_MOVECORR() die Bewegung ausgeführt werden sollte? Was sollte mir der TestServer im Anzeigefeld anzeigen?

Hallo Zusammen

Ich kämpfe ziemlich mit der Inbetriebnahme des RSI Ethernet, um die KRC mit einem externen PC verbinden zu können. Finde das ganze sehr unübersichtlich und irgendwie blicke ich da nicht ganz durch. Ich habe einige Zeit mit Pingtests verbracht bis ich dann endlich mal das Hauptproblem gefunden habe....die X66 ging nicht auf die KLI, da diese nach der Inbetriebnahme der FTCtrl besetzt war. Da momentan das FTCtrl und der Sensor nicht verwendet wird habe ich die X66 mit der KLI verbunden und den Laptop direkt verbunden. Folgende Einstellungen habe ich vor mir:

Roboterseitig:

virtual5 (virtual)
Adresstyp: Feste IP-Adresse
IP-Adresse: 172.31.1.2
Subnet: 255.255.255.0
Windows-Schnittstelle: ja

virtual6 (RSI)
Adresstyp: Gemischte IP-adresse
IP-Adresse: 192.168.1.2
Subnet: 255.255.255.0
Windows-Schnittstelle: nein

Laptopseitig:
IP-Adresse: 192.168.1.1
Subnet: 255.255.255.0

Vom Laptop aus kann ich das virtual6 (RSI) pingen.
Vom Laptop aus kann ich das virtual5 (virtual) nicht pingen.
Vom SmartPad aus kann ich den Laptop nicht pingen.

Testserver (aus dem Beispiel) läuft nicht, wobei ich im EthernetConfig.xml die IP-Adresse des Laptops eingetragen habe. Port steht auf 49152. Kartenindex bin ich mir nicht wirklich sicher, wie ich den rausbekommen soll.

Momentan habe ich vorallem Probleme zu verstehen, wie die 2 Netzwerke auf der KRC zusammenhängen und welches für die Ethernet-Verbindung überhaupt interessant ist. Das virtual5 ist soviel ich verstehe das der KLI, also das der Steuerung. Das virtual6 ist somit das Netzwerk des RSI.

Ich hoffe jemand von euch kann da einwenig Licht ins Dunkle bringen, sodass ich wenigstens mal den Testserver zum laufen bring. Anschliessend sollen Positions- und Sensordaten des Kraft-Momenten-Sensors online an den Laptop übermittelt und dargestellt werden. Dies wird wohl mit einem eigenen Programm realisiert, wobei ich da noch unschlüssig bin, wie wir das umsetzten wollen (Matlab, Phyton, C#). Für Anregungen bin ich offen =)

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

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.

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

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.

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"

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.

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.

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.