Beiträge von FelixKA

...und wieder mal ein kleines Update!!!

ES FUNKTIONIERT!!!

Mein Programm, das ein Array mit vorgegebenen Zielpunkten der Reihe nach abfährt und dabei ein Hindernis, das durch mehrere überlagerte kubische Hindernisräume beschrieben wird, berücksichtigt, hat nun also in etwa folgende Struktur:

main(): hier gibt es eine FOR-Schleife, die nacheinander die einzelnen Zielpunkte auf Erreichbarkeit ( -> nicht in einem der Hindernisräume) überprüft und sie dann als Parameter an eine reine anfahr-Funktion übergibt.

ir_func(): dann gibt es eine Interrupt-Routine, die anspringt, sobald einer der TEIL-Hindernisräume verletzt wurde (mit §CYCFLAG als OR-Verknüpfung über alle WS.STATEs). Hier wird die anfahr-Bewegung abgebrochen, es wird eine Variable "mussausweichen" auf TRUE gesetzt, die Nummer des verletzten TEIL-Hindernisraums wird speichert und der Roboter fährt wieder ein kleines Stückchen zurück, damit der Hindernisraum wieder frei ist (-> Interrupt wieder scharf). Danach springt er nach main() zurück.

Innerhalb der main-FOR-Schleife gibt es dann eine WHILE (mussausweichen==TRUE) -Schleife. In dieser wird die Unterfunktion ausweichen() aufgerufen, die mit hilfe der Hindernisraumnummer, $POS_ACT und dem aktuellen Zielpunkt eine ausweich-Bewegung (parallel entlang der Hindernisbegrenzungen bis aktueller Zielpunkt erreicht) berechnet und diese Ausweichpunkte abfährt. Diese kann nun wieder vom Interrupt unterbrochen werden, solange, bis der aktuelle Zielpunkt erreicht wurde und "mussausweichen" nicht mehr auf TRUE gesetzt ist.

Nun habe ich aber schon wieder weitere Anreize zur Verbesserung:

Punkt1:
Wie im letzten Post bereits erwähnt sind die mathematischen Berechnungen und Bedingungen in KRL ziemlich kompliziert auszudrücken. Deshalb würde ich diese gerne zum Beispiel in ein externes Programm auf dem KR_C-Steuerungsrechner auslagern, der dann praktisch alles berechnet und nur die fertigen Anfahrpunkte als Parameter an das KRL-Programm übergibt, bzw im Falle einer Kollision entsprechende Signale sowie evtl zusätzliche Variablen von diesem abfrägt/empfängt.
In der Dokumentation habe ich etwas über den Automatik Extern - Betrieb gelesen. Wäre so etwas damit möglich. Oder gibt es vielleicht noch ander Möglichkeiten bzw Tips hierzu.

Punkt2:
Bisher werden Kollisionen nur bezüglich des TCP bzw. des gewählten Werkzeugkoordinatensystems erkannt. Dabei kann es passieren, das zwar nicht das Werkzeug, dafür aber der Roboterarm in den Hindernisraum hineinragt.
Gibt es Möglichkeiten (Modellierung des Arms o.ä) um auch dies zu berücksichtigen?

Für jede Antwort von euch bin ich dankbar!!!

Schöne Grüße
Felix

Hallo,

ich habe ein paar Fragen zum Thema "Interrupts":

- Kann ich als Auslösekriterium für einen Interrupt etwas von der Form 'VAR1 OR VAR2 OR ... OR VARN' - also zusammengesetzte Boolsche Ausdrücke - verwenden?

- Wie kann ich es anstellen, das nieder- oder gleichpriore Interrupts sich gegenseitig unterbrechen können, OHNE dass der bisherige Interrupt (und evtl. von diesem aufgerufene Unterfunktionen) beendet werden?
Beispiel:
gegeben Interrupt1, der ausgelöst wird, wenn Bedingung1 wahr wird.
Folgender Ablauf:
Hauptprogram -> Bedingung1 wird wahr -> Interrupt1Funktion wird aufgerufen -> evtl. Unterprogramme -> währenddessen wird Bedingung1 irgendwie wieder falsch -> und dann aber nochmal wahr (noch innerhalb des Interrupts) -> jetzt sollen alle evtl noch auszuführenden Bewegungen der Interrupt1Funktion abgebrochen und die Interrupt1Funktion von neuem von ganz vorne aufgerufen werden.

Es wird so sein, dass das keine Endlosschleife ergibt!!! Wird die Bedingung1 irgendwann einmal nicht mehr wahr, dann kann die Interrupt1Funktion zuende bearbeitet werden. Danach gehts ins Hauptprogramm zurück.
Angewendet soll das ganze hier:
Arbeitsbereiche und Ausweichen

Danke für eure Antworten

hallo,

ich melde mich mal wieder, da ich inzwischen ein bisschen weiter an dem Problem rumgebastelt habe.
Ich habe es jetzt mehr oder weniger so gelöst, dass ich, sobald der definierte Arbeitsbereich verletzt wird ($WORKSPACE[1].STATE=TRUE) ein Interrupt aufgerufen wird, der dann eine Funktion ausweichen() aufruft.
In dieser wird dann mit ziemlichem mathematischem Gedöns (Kollisionsebeneberechnen, Closest_Eckpunkt, usw) und komplizierten Bedingungen, die ich mir aus unzähligen Skizzen überlegt und hergeleitet habe, zwar keine weg- bzw. geschwindigkeitsoptimale aber immerhin eine (für unsere Zwecke ausreichende) kollisionsfreie Bahn zum eigentlichen Zielpunkt berechnet und abgefahren. Danach springt das Programm aus der Interruptfunktion wieder ins Hauptprogramm und kann den nächsten Zielpunkt anfahren.

Nun möchte ich das ganze noch etwas verbessern...
Ich will, dass man den Arbeitsbereich aus mehreren zusammensetzen kann (-> komplexere Gegenstände), habe dabei aber folgendes Problem:
Wenn die Ausweichbewegung für einen der TEIL-Arbeitsbereiche eine Ausweichbewegung abfährt, kann es ja sein, dass diese Bewegung mit einem der anderen Arbeitsbereiche kollidiert.
Ich müsste also irgendwie für jeden TEIL-Arbeitsbereich einen Interrupt auslösen können, der JEDEN anderen unterbrechen kann. Da die Interrupts allerdings prioritätsmäßig geordnet sind, funktioniert das aber immer nur in eine Richtung.
Hab mir auch schon überlegt so etwas wie einen MASTER-Interrupt zu definieren, der anspringt sobald mindestens einer der Arbeitsbereiche verletzt wird ($WOR...[1].STATE OR $WOR....[2].STATE OR ... OR $WOR...[N].STATE). Aber irgendwie kann ich keine zusammengesetzte Bedingung als Auslöskriterium für einen Interrupt definieren. Ist das richtig??? Oder wie kann ich das machen???
Wenn das doch irgendwie geht, könnte ich mir die Ausweichbewegung wieder zusammenbasteln.

Allerdings müsste dann die Ausweichbewegung, die vom MASTER-Interrupt aufgerufen wird, wieder durch den MASTER-Interrupt unterbrochen werden können, wenn ne Kollision mit nem neuen TEIL-Arbeitsbereich auftritt.
Der Interrupt wird erst wieder "auslösbar", wenn die Interrupt-Funktion (und evtl. aufgerufene Unterfunktionen) beendet sind. Ist das richtig??? Kann ich das irgendwie umgehen???

Thx

Na, scheint sich ja ne rege Diskussion zu ergeben...

Zitat von fubini

ich kann euch versichern, dass es so etwas bei KUKA nicht gibt. Wie schon angesprochen, kann die Steuerung ja nicht wissen wie ausgewichen werden sollen. Stellt euch mal vor die Steuerung würde einfach festlegen wie es passieren soll und fährt dann Crash.

Naju, ich glaube nicht, dass der Roboter unbedingt crashen würde. Nehmen wir mal an der normale Sicherheitsbereich und die Softwareendschalter seien - von der Hindernisumfahrung unabhängig - ständig aktiv. Somit wäre also der Roboter selbst sowie seine Umgebung inkl Operator weiterhin ganz normal vor Crashes geschützt.
Und was Kollisionen mit dem Objekt/Hindernis angeht, so muss man halt den Hindernisbereich entsprechend dem Bezugspunkt (TCP o.ä.) so wählen, dass er eben nicht damit kollidiert, bzw - bei einem erneuten Kollidieren - wieder versucht, einen Weg drumherum zu finden.

Was allerdings wirklichein ein Problem sein könnte, ist dass der Roboter nicht weiss, wir er darum herumfahren soll.
Vielleicht könnte man hier so etwas wie eine Vorzugsrichtung oder so angeben. Diese könnte ja zu jedem Hindernisbereich gleich mit angegeben werden, da für die Konfiguration eines solchen ja die genaue Lage, Orientierung und Ausdehnung des Objektes im Raum angegeben werden muss, also bekannt ist. Der Operator müsste sich dann also eine Richtung überlegen (Vektor oder auch Koordinaten eines "Ausweichpunktes"), die zu diesem Objekt/Hindernis am besten passt (Der Operator kennt ja den Kontext und die Umgebung).
Kollidiert nun der Roboter mit dem Hindernis, fährt er so lang in Richtung des Vektors/Ausweichpunktes, während er parallel ständig prüft, ob es zu dem eigentlichen Zielpunkt eine kollisionsfreie Bahn gibt. Sobald eine solche existiert, schlägt der Roboter wieder seinen Weg in Richtung Zielpunkt ein.

auch habe ich in einem anderen topic folgendes gefunden:

Zitat von Roboman

Müssen Hindernisse mit mehreren Positionen umfahren werden oder können diese wie mit dem Befehl "Jump" von Epson überfahren werden?

Weiss jemand, was es damit auf sich hat???
Das hört sich für mich so an, als wäre das genau so eine Funktion, wie ich sie suche...=)

schönen gruß
felix

hmm,
Ich will ja damit nicht den gesamten Sicherheitsbereich modelieren, der ist schon abgesichert.
Vielmehr sollen die Roboter später verschiedene Objekte mit ner Kamera abfilmen.
Wie das genau später mal angewandt und umgesetzt werden soll ist noch nicht klar, ich möchte nur wissen, ob es so eine Funktion generell gibt.
Also vielleicht erklär ich das nochmal so:
Man hat ein Programm, in dem ne feste Bahn abgefahren wird und dann tut man eben so nen Hindernis/Objekt in den Raum rein und konfiguriert darum nen Hindernissraum. Dieser Bereich liegt auf dieser Bahn.
Mit der Arbeitsraumüberwachung kann der Roboter NUR angehalten werden, BEVOR er in den Bereich gerät. Ich möchte aber eher eine Funktion, mit der der Roboter trotzdem an den Zielpunkt der Bewegung gelangt bzw die Bahn hinter dem Hindernisbereich fortsetzt, indem er eine Bahn UM das Hindernis herum befährt (die er selbst berechnet) - er weicht also dem Hindernis aus.
Gibt es sowas???

Ich hoffe es ist nun etwas klarer, was ich meine.

Vielen Dank
Felix

Hallo, liebe Community

ich will bei unseren beiden Robotern (KR-16 und KR60) versuchen, ob es möglich ist, da Hindernisse einzubauen.
Gefunden habe ich dazu auch schon die Konfiguration von kartesischen und achsspezifischen Arbeitsräumen.
Allerdings wird hier nur überwacht, ob sich die Bezugspunkte im Werkzeug bzw Werkstück innerhalb oder ausserhalb dieser Bereiche befinden, und dann ein entsprechendes Signal (Workspace[n].STATE) gesetzt sowie eventuell beim Ein- oder Austreten ein bahntreuer Stopp eingeleitet.

Ist es möglich, diese Arbeits-/Hindernisräume in die Bahnplanung mit einzubeziehen?
Heisst also, falls die Bahn eines Bewegungsbefehls solch einen Bereich streifen würde, die Bahn um das Hindernis herum geleitet/geschliffen/interpoliert wird?
Welche anderen Möglichkeiten habe ich?

gruß
felix

Hallo zusammen,

vielleicht erzähl ich erstmal um was es bei mir geht und wo ich im Moment grade steh:
Bei uns am Institut sollen zwei KUKA-Bots zusammen Objekte mit ner Kamera aufnehmen, also ein Roboter hält das Objekt und der andere hat die Kamera montiert. Dann soll man über das Bildverarbeitungsprogramm (Remote-Zugriff) Roboterdaten auslesen und solche schreiben können (zum Beispiel Positionsdaten, um das Objekt aus einer bestimmten Lage zu betrachten o.ä.). Dazu soll OPC verwendet werden.
Nun ist es meine Aufgabe als HiWi mich da mal einzuarbeiten. Ich habe auch schon das OPC-Paket von KUKA bekommen, installiert und konnte auch schon Daten mit dem KUKA-TestClient (C++) sowohl lesen als auch schreiben.
Dabei sind aber noch nen paar Probleme aufgetreten, die ich hier gerne mal reinschreiben würde. Vielleicht hat ja jemand ne Lösung für mich.

1.Problem:
Beim Aufbau der Remote-Verbindung vom Client zum Server erhalte ich folgende Fehlermeldung:
IDataObject::DAdvise: Zugriff verweigert
Danach kann ich aber trotzdem die Tag-List vom Server abrufen.
Was hat das zu bedeuten???

2.Problem:
Neue Variablen, die man dem Client verfügbar machen will, werden auf dem Server in die Datei KUKA_OPC_Config.XML eingetragen. Dabei muss auch ein Cross-Name und ein Item-Name angegeben werden.
Wo ist da der Unterschied? Muss Cross-Name genau mit dem Namen übereinstimmen, mit dem die Variable in beispielsweise einer .dat-Datei definiert wurde und ist Item-Name dann ein beliebiger Name, unter dem die Variable dann in der Tag-List aufgeführt wird???

3.Problem:
Wenn ich ein paar Variablen mittels Add Item unter Beobachtung nehme, bekomme ich bestensfalls den Initialwert der Variable und bei unitialisierten Variablen den Wert BAD. Ich hätte allerdings gerne, dass sich zum Beispiel die Positionsvariable bei Programmablauf ständig auf dem aktuellen Stand bringt (synchrones Abfragen nach bestimmten Zeitintervallen).
Das scheint aber nicht zu funktionieren. Ich muss immer zuerst selbst auf Refresh klicken, um den neuen Wert zu bekommen.

4.Problem:
Bei allen Aktionen, wie Read (asynchron), Refresh und auch Write, gibt es eine entsprechende Fehlermeldung:
Async Read/Refresh/Write: OPC Server failed GetErrorString
Hier gehe ich davon aus, dass vielleicht einfach der TESTClient nicht ganz korrekt und bis ins Detail durchprogrammiert ist. Denn es geht ja dann doch. Wollte nur mal wissen, ob diese Fehler auch schon bei anderen aufgetaucht sind.

5.Problem:
Bisher habe ich nur Variablen von dem Roboter auslesen können, auf dem der OPC-Server installiert ist.
Die beiden Roboter sind aber miteinander synchronisiert und gekoppelt. Allerdings funktioniert es komischerweise nicht, den OPC-Server auch auf dem anderen zu installieren. Warum weiss ich nicht??? Any ideas???
Ansonsten: Wie kann ich auch über den OPC-Server auf Rob1 auf Variablen von Rob2 zugreifen??? Gibt es auf Rob1 ein Verzeichnis, in dem die Variablen von Rob2 drinstehen???

6.Problem:
Wie oben schon erwähnt, soll die Lese/Schreibe-Funktionalität letztendlich mit in das Bildverarbeitungsprogramm eingebunden werden. Dazu muss ich wohl dann die entsprechenden Client-Funktionen in den Code des BVPs einbauen. Gibt es dafür eine API oder Bibliotheken oder Dokus oder irgendsoetwas???

Ich weiss, dass das hier jetzt etwas länger geworden ist.
Ihr braucht ja auch nicht alle Fragen auf einmal beantworten.
Bin aber trotzdem dankbar für jedes bisschen Hilfe!!!

Grüße
Felix