extrem hohe Rechenzeit in Matlab-Skriptknoten

Hallo

ich habe hier im Anhang ein SubVI hochgeladen, das Teil einer Robotersteuerung für einen 6-achsigen Knickarmroboter auf LV basierend ist.
Um den Sachverhalt evtl nachvollziehen zu können, beschreibe ich kurz, was das SubVI macht:

Das VI hat folgende Eingaben:
6xn Matrix beta (in radiant): 6 Gelenkstellungen des Roboters zu jedem der n berechneten Zeitpunkte (i.d.R. 1000<n<20000)
6xn Matrix y_d: Translationsgeschwindigkeiten und Orientierungsänderungsgeschwindigkeiten der Kardanwinkel des Endeffektors zu jedem der n berechneten Zeitpunkte
DH-Parameter: Devanit-Hartenberg Parameter.. einfach hinnehmen. Sie sind zur weiteren Berechnung notwendig.

Ausgang:
6xn Matrix beta_d: Winkelgeschwindigkeiten der 6 Gelenke

In dem Skriptknoten ist nun zu erst die Jacobimatrix in der symbolischen Form definiert. (vorher in Matlab berechnet)
Nun werden zu erst die DH-Parameter substituiert.
Anschließend substituiert die Schleife für jeden Zeitschritt die aktuelle Spalte der beta-Matrix in die Jacobimatrix und rechnet anschließend die entsprechende Spalte der beta_d-Matrix aus. (beta_d = Jacobi^-1 * y_d, bzw beta_d = Jacobiy_d).
So werden nach und nach in der for-Schleife alle Spalten von beta_d berechnet.
Das Problem ist, dass diese Schleife alleine je nach Eingaben zwischen 50 und 500 sekunden rechnet und das ist leider nicht akzeptabel für die Anwendung in welcher das SubVI gebraucht wird.

Hat jemand eine Idee, wie man die Berechnung beschleunigen könnte?

LV Version 8.5.1
für y_d, beta und DH sollten Beispielwerte gespeichert sein

Danke schon mal, falls jemand bis hier gelesen hat.

Gruß
Fiinrod

Hallo Fiinrod,

ich habe bis zum Schluß gelesen.
Ich meine gestern gab es einen Beitrag da ging es ebenfalls um Matlab.
Ich plappere nur nach was dort gesagt wurde. Matlab ist nicht wirklich auf Performance getrimmt.
Vielleicht solltest Du die Matritzenrechnung aus dem Scriptknoten herausholen und in LabVIEW lösen.
LabVIEW muß zum ausführen dies Skriptknotens ersmal einen Scriptserver starten, der dann meines Wissens den Knoten im Hintergrund von Matlab bearbeiten läßt. Das resultat bekommst Du dann zurück zu LabVIEW.

Wenn Du die gesamte Rechnung in LabVIEW machst dürfte das um Welten schneller sein.

Grüße
Andreas

PS: <klugscheiss> Denavit-Hartenberg sollte es eigentlich heissen.</klugscheiss>
Falls jemand mal mit dem richtigen Begriff suchen sollte.

Edit: Hab den Beitrag eben gefunden. http://www.labviewforum.de/index.php?s=&am...ost&p=94210

Wäre mir grundsätzlich auch lieber, alles in LV zu rechnen. Das Problem ist folgendes: Die symbolische Jacobimatrix, die man in dem Skriptknoten sieht, ist wie gesagt in Matlab vorberechnet (das hat irgendwann mal mein Betreuer in seiner Diplomarbeit gemacht, oder so... auf jeden Fall kann/will ich da das Rad nicht neu erfinden). Und ich habe keine Ahnung, wie ich diese symbolische Matrix in LV übertragen könnte und dort dann die entsprechenden Werte rein substituiere, weiterrechne ect..

(Denavit? Ich glaub den schreib ich falsch, seit ichs das erste mal gehört hab.)

Hi Fiinrod!

Wenn Dein Betreuer in seiner Diplomarbeit die Jacobimatrix berechnet hat, dann kann er Dir sicher weiterhelfen, daß die auch den Weg in LV findet. Ich bin leider überhaupt kein Matrizen-Künstler und kann Dir da nicht wirklich einen Ratschlag geben.
Aber es gibt hier im Forum ein paar Kandidaten, die da einiges auf dem Kasten haben.

Grüße
Andreas

Schön wärs, aber mein Betreuer arbeitet nicht mit Labview. Und auch sonst so ziemlich niemand an dem Lehrstuhl. Deswegen bin ich da relativ auf mich allein gestellt und eben das große weite Web.
edit: und um auch gleich die Frage zum beantworten, warum dann diese Robotersteuerung überhaupt auf LV basiert: weil irgendwann mal ein Student damit angefangen hat, diese Steuerung mit LV zu entwerfen

Hallo Finrod,

diese Jacobi-matrix wird doch (so wie ich es sehe) "nur" durch diverse Polynome berechnet. Es mag zwar mühsam sein, diese nach LV umzusetzen, aber durchaus machbar. (Außerdem könnte es hilfreich, sein, dieses Matlab-Skript besser zu formatieren. Momentan sieht man ja nur einen Bruchteil des gesamten Skripts.)

Wer hat dir übrigens gesagt, dass man Array-Elemente liest, indem man das Array nach Cluster umwandelt und dann "unbundelt"? Wozu gibt es wohl IndexArray?

Hi!

aber von Matritzenrechnung wird der Betreuer ja noch Ahnung haben.
Er muß ja nur erklären was in Matlab passiert, damit Du es in LabVIEW umsetzen kannst.

Grüße
Andreas

Kurzer Einwurf:
Matlab ist auf Matrizen-Rechnung optimiert und sollte um einiges schneller Laufen als LV, vorraus gesetzt es ist vernünftig programmiert.

Könntest du das Matlab-Skript mal hochladen?

' schrieb:Kurzer Einwurf:
Matlab ist auf Matrizen-Rechnung optimiert und sollte um einiges schneller Laufen als LV, vorraus gesetzt es ist vernünftig programmiert.

Um einiges schneller - sicher nicht. Optimiert auf Bedienfreundlichkeit - ok, Performance - ich weiß nicht. Das Problem ist nicht wie schnell MATLAB rechnet, sondern die Schnittstelle zwischen MATLAB und LV.

' schrieb:Matlab ist auf Matrizen-Rechnung optimiert

Diesen Satz habe ich auch schon oft gehört ... Der wird meiner Meinung nach falsch interpretiert. Optimiert ja - weil's einen riesigen Haufen Tool-Boxen dafür gibt und man muss sich nur die richtige rauspicken. Was der Compiler daraus macht steht auf einem ganz anderen Blatt.

Ich hab mal Kreuzkorrelationen gemacht. Erst mit MATLAB, viel später mit LabVIEW - identiche Daten und LabVIEW war um Welten schneller.

' schrieb:Hat jemand eine Idee, wie man die Berechnung beschleunigen könnte?

Habe einen Freund, den ich jetzt leider nicht fragen kann, der hatte das gleiche Problem. Wenn ich nicht ganz irre, war die entscheidende Verbesserung ein Update von Labview, wahrscheinlich schon von 8.5 auf 8.6.