Latenz messen für Studienarbeit, aber wie?

[MisterM]

Hallo Leute,

Ich soll für meine Masterarbeit die Latenz eines Gesamtsystems messen. Das Setting ist folgendes:

Körperbewegung -> Motion Tracking von Vicon Nexus --> per Laptop auf server --> von server auf Recheneinheit --> Simulation wird auf der Recheneinheit gefüttert mit dem Datastream (Besteht aus 3 Computern) --> Ausgabe auf Oculus Rift.

Das Ding selbst ist einfach eine hoch immersive Virtual Reality. Nun bin ich am überlegen wie ich eben die Latenz für Body-Movement-to-Display ausgeben kann.

Eine Variante die ich mir überlegt habe, wäre eine Kamera aufzustellen (High-Speed) und meine Hand vor der Oculus rift zu bewegen und dann die Zeit zu messen, bis die Handbewegung in der Oculus erscheint.

Sind hier vielleicht Ingenieure/Informatiker die eine bessere Variante wissen?

Eine andere Möglichkeit wäre natürlich alle mir bekannten Latenzen zu addieren und so die Minimallatenz zu kriegen. Da fehlen aber eben definitiv Latenzen wie die der Recheneinheit bzw. der Simulation.

Grüße,

euer MisterM

 

[BurnerR]

Was mir spontan zumindest einfällt ist, dass die Latenz zwischen Laptop zu Server insofern besonders interessant ist, als das diese ja am meisten schwankt bzw. stark davon abhängt, ob der Laptop im selben Netzwerk ist wie der Server, ob er per Wifi angeschlossen ist u.ä.. Vermutlich ist es interessant zur Gesamtlatenz in deinem Setup noch die Latenz für die Übertragung von Laptop zu Server gegenüber zu stellen bzw. heraus zu rechnen.

Mit deinem Ansatz misst du jedenfalls die Latenz adequat für dein Setup(!). Was sagt denn dein Betreuer dazu?

 

[Philipus II]

Beide Latenzen sind m.E. hochinteressant. Die minimal mögliche Latenz mit der aktuelle Hardware und der Vergleich mit der Realität kann sogar Optimierungspotential aufdecken. Statt an Hardware oder Software-Egine rumzuschrauben könnte es sein, dass es an anderen Stellen in der Nutzungsumgebung viel mehr Latenz bzw. vor allem mehr Delta zwischen theoretischem Minimum und Realität gibt.

 

[Opuntia]

Bekommst du vom Motiontracker irgendwie einen Zeitstempel?
Den könntest du "theoretisch" überall im System abgreifen und mit der Echtzeit abgleichen.
Das würde dir auch die Latenzen der einzelnen Bauteile geben und währe für jedes Setup Nutzbar

 

[MisterM]

Also Sinn und zweck ist folgender: Die Literatur gibt an, dass eine minimale Latenz zwischen Bewegungsausführung und Bewegungsdarstellung essentiell ist, damit der Nutzer die virtual Reality als wirklich real empfindet und damit es nicht zu Motion- bzw. Simulator-Sickness und co kommt.

Ghosting und co sind ja bei der ORII ja schon mal kein Problem mehr, die nutze ich übrigens konkret. Dennoch wissen wir eben aktuell nicht, wie lange es dauert bis das winken auch als solches dargestellt wurde.

Zwecks Latenz gibt es leider keine Konkreten Normen, dennoch wollen wir aber zeigen: Unser System hat eine Latenz von XY und die Leute beschweren sich nicht (tun sie wirklich nicht, hatten keinen Fall von Übelkeit bisher). Andere könnten dann diese Werte auch verwenden als Norm bzw. Richtwert. Prinzipiell wäre es eigentlich interessanterweise mit wie viel lag die Leute leben könnten, erinnert mich an diese eine Werbung für einen Internetprovider

Meinem Betreuer ist der Ansatz nicht elaboriert genug, leider hat er selbst von sowas null Ahnung und will dass ich mich nun damit auseinandersetze, obwohl ich nicht so einen technischen Background habe -.-

 

[BurnerR]

Schonmal google bemüht? Ich meine scholar.google.de
30 Sekunden Google hat z.B. das hier ergeben:

Techniques used to measure end-to-end latency share the requirement of capturing both a signal generated by a change in the tracker position and a signal generated by the change of the image on the display device. [Ware 1994], [Liang1991], and [Miné 1993] describe techniques for making these measurements

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.298.5013&rep=rep1&type=pdf

Hier der secret suchstring, den ich verwendet habe
https://scholar.google.de/scholar?hl=de&q=latency+virtual+reality

 

[MisterM]

Diese Aufbaute mit Pendulum etc, hatte ich schon gefunden als ich nach der Latenz von Vicon gesucht habe.

Mir wäre es um Boardmittel gegangen bzw. eventuellen Features des SDK. Das hat zB einen Latenz-Messer, aber leider nicht End-to-End sondern nur Head-Movement-to-Photon etc.

Danke dir aber noch mal für das Paper, hatte eben bislang nur andere Paper gefunden , in denen es eher um Server ging etc. und das einzig "mechanische" setup, hatte ich nur für die Vicon Selbst.

Und Scholar nutze ich natürlich, wie sollte ich denn sonst die Quellen angeben am ende? :P

 

[BurnerR]

Hier ist beispielhaft ein relativ einfacher Aufbau der genau das umsetzt was dir auch spontan eingefallen ist: http://www.cs.unc.edu/~tracker/media/pdf/Miller2002_latencymeter.pdf
Wie wärs (allein das hilft dir vermutlich), wenn du hier mal auflistest, welche Methoden du aus Lehrbüchern oder Papern kennst und warum sie dir nicht taugen?
Weil die end to end latency ist offenbar ein ganz zentrales Maß im VR Bereich zu dem du ganz sicher einen Haufen Zeug findest und sichten kannst, da solltest du eigentlich null Probleme haben die verschiedenen Ansätze zu kennen, gegenüber stellen zu können und entsprechend umzusetzen bzw. in deiner Arbeit dann aufzugreifen.

Ich habe auch spontan ein VR Buch gefunden, dass einen eigenen Abschnit zu genau diesem Thema enthält: http://www.lehmanns.de/media/285878/1?PHPSESSID=se1u1gn8et6v8n1pamprucqa06

So eine oberflächliche google Suche sollte man eigentlich schon hinter sich haben, wenn man so eine Frage stellt, also sichten von papern und lehrbüchern zu den offensichtlichen stichpunkten.

 

[theSplit]

Das was Opuntia vorgeschlagen hat würde ich auch vorschlagen, nur vielleicht etwas anders eingebaut und nicht direkt im Datenpaket übermittelt, sondern in den einzelnen Stationen gesammelt/protokolliert.

So das man auf dem Emitter des Signals den Zeitstempel festhält wann die Bewegung registriert wurde, wann die Bewegung, zum versenden an einen Server, vorbereitet wurden ist (Vearbeitetungsdauer Eingabe) - Startzeit Übertragung, Messung der Zeit bis alle Datenpaket im Server angekommen sind, Endzeit Übertragung (Übermittlungsdauer) - jetzt wieder einen Zeitstempel und dann wann die Rendering Engine das Signal gezeichnet hat, letzter Zeitstempel (Verarbeitungsdauer Ausgabe).

Also hat man 2, 4, 6 Zeitstempel insgesamt wobei an jedem Punkt eine Start und Endzeit bis zum nächsten Step festgehalten werden und kann daraus die Gesamtlaufzeit ermitteln die ein Round-Trip durch die Systeme und Bearbeitung/Verarbeitung in Anspruch nehmen.

Ich würde dafür die CPU Zeit verwenden: http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html

So bekommt man, meiner Meinung nach, auch einen guten Überblick wo mögliche Bottlenecks sitzen und kann falls gegeben Anfangen zu Optimieren wenn gewünscht bzw. erhält direktes Feedback darüber wie und wo die Daten verweilen und ob eine Veränderung etwas verbessert hat oder nicht.

Vielleicht noch eine Idee für einen weiteren Messpunkt (falls das überhaupt möglich ist!)
Was ich mir auch gut vorstellen könnte, man fängt an einen einfarbigen Kreis an das Gerät zu senden, setzt einen Zeitstempel wenn das Signal gerendert wird und stoppt dann die Zeit bei Tastendruck des Testers wann der Punkt wahrgenommen wurde.

Das wäre zwar nicht wirklich "genau" - aber man könnte das 20-30 mal hintereinander machen und einen Mittelwert in wie weit gefühlt die Latenz ist für das Rendering allein. Von Ausgabeübergabe bis zur Anzeige auswerten. Die Netzwerklatenz/Übermittlungsdauer ist ja bereits bekannt und könnte davon abgezogen werden wenn man fleißig die Übertragunsdauer für etwas protokolliert hat.

So jedenfalls meine bescheidene Idee, ich hab mit sowas logischerweise nicht gearbeitet, könnte mir aber gut vorstellen das man so gut nachvollziehen kann wie der Fluß ist.

 

[Opuntia]

@theSplit:
Mir sind bei dem Aufbau nachträglich noch zwei Probleme Aufgefallen:
es misst nicht die Zeit von Bewegung zu Motionsensor Zeitstempel.
es misst nicht die Zeit von Brillen(empfang) bis Brille(ausgabe)
Dafür bräuchte man schon eine äußere Zeitmessung.

Bei deinem müsste man auch noch einmal unter Ruhe und einmal unter Last messen.
Mehr Bewegung heißt natürlich mehr Rechenlast.

Eventuell auch noch ein Grenzwert, wie viele heftige/schnelle Bewegung kann das Setup ab, bevor Verarbeitungszeit zu hoch wird.

 

[theSplit]

@Opuntia
Die Latenz bis das Gerät die Bewegung verarbeitet hat?

Gute Frage wie man das messen kann, dazu müßte man wirklich mit einer Kamera parallel aufnehmen und die Zeiten von Video und Eingang des Signales in den Sensor messen, was der TS eigentlich schon vorgehabt hatte. Also impuls/Bewegung -> Eingang in der Hardware, wann wurde gecaptured. Aber gute Frage in wie weit das SDK sowas erlaubt. Wenn man auf nen "SensedMotion Ereignis" abfangen kann, vielleicht. Das ist aber mit hundertstel Sekunden Bereich vermute ich mal, es sein die Hardware ist voll ausgelastet und arbeitet an einem anderen Signal/Vorgang und fängt dann an zu rütteln.

Man könnte zu den Zeitstempeln die Datenmenge einkreisen, also quasi das Gesamtpaket das vom Client zum Server geschickt wird - damit hätte man die Datengröße für den Frame/Berechnung und die daraus resultierende Performance der Hard- und Software. Guter Punkt!

Ansonsten geb ich dir Recht, eine Lastmessung im "Ruhezustand" wie auch "Aktivezustand" wären mit Sicherheit nötig um Unterschiede festzustellen.
Aber auch ein statisches Bild hat eine gewisse Kapazität die immer übertragen werden würde, glaube ich jedenfalls - außer das System vergleicht einen Frame, erkennt einen Unterschied und schießt den gesamten Frame in fast Echtzeit an die Server zur Verarbeitung für die Ausgabe in der 3d Brille.

Irgendwie so müßte es theoretisch auch sein.

 

[MisterM]

Also ich merke schon, ich hätte etwas mehr zu meinem aktuellen Stand der Dinge schreiben sollen.

Ich hatte mich ursprünglich zum End-to-End-Latency Aufbau nach Miné (1993) informiert. Also ein Pendel mit einem Marker welches vor einem Tracker schwingt und dadurch ein Event auslöst, welches den Bildschirm verdunkelt. Das ganze dann eben per oszilloskop messen.

Das geht leider in meinem Fall nicht, da wir über 10 Kameras verfügen die rund herum im Raum angeordnet sind und den Probanden von allen Seiten her Tracken. Ein Pendel wird hier also leider nicht gehen.

HInzu kommt, dass die Engine die wir verwenden, keine Standard-VR-Engine ist, sondern eine Engine für Fahrsimulatoren. Die verfügt nur über eingeschränkte Möglichkeiten. Events festzulegen, sind hier also leider nicht möglich, vor allem da ein einzelner Marker nicht erkannt wird. Es müssen 14 Marker sein, welche den Menschen modellieren, ansonsten funktioniert die komplette Simulation nicht -.-

Die Idee wäre somit eine video-basierte Variante zu machen, wie ich sie bereits für CAVE-Aufbauten gefunden habe. Die sind leider halt nicht komplett kompatibel, da es sich bei einer Cave um einen Projektor handelt, ich aber eben ein sehr kleines HMD hab.

Die Grundlage hierfür ist übrigens nichts technisches, also ich soll da nichts optimieren oder so, sondern nur herausfinden wie groß eben der Lag der Bewegung ist. Er ist zwar fast nicht da, aber fast nicht ist halt keine Präzise Angabe die man machen kann, wenn wir den Simulator bei der nächsten IEEE vorstellen wollen.

Ich würde nun eventuell mit zwei GoPros gleichzeitg meinen Arm und das Display abfilmen. Beide mit 120FPS um dann zu sehen wie viele Frames Unterschied sind. Dabei würde ich den Arm in verschiedene Richtungen bewegen. Die Videoauswertung würde ich vermutlich mit einem Post-Record-Tool machen, evtl SLT (MATLAB Plugin zum Bewegungstracking) und mir dann eben das deltaT anschauen zwischen Arm und Arm auf dem HMD.

Eine Armbewegung wähle ich, da sie mit die schnellste Bewegung ist die man in dem Simulator machen kann. Der Rest ist recht langsam, da man eben auch nur sehr gemächlich gehen darf.

Eine reine Grundlatenz, ist für mich jedenfalls unerheblich, da ich wirklich nur wissen will wie es für den Probanden selbst ist. Der wahrgenommene Lag im HMD ist nämlich ausschlaggebend für die Presence (Slater & Wilbur, FIVE).

Was nur mein Betreuer noch gerne hätte, wäre eine Ausgabe über den Projektor um zu sehen wie viel Zusätzlichen Lag die OR2 verursacht. Der Projektor wäre in dem Fall per VGA angeschlossen und hat ja für sich keine Recheneinheit.

Danke jedenfalls für die ganzen Ideen und einwände, sollte mal jemand sich um die technische Optimierung kümmern wollen, werde ich auf eure Vorschläge zurück kommen.

 

[Philipus II]

Hochinteressantes Thema, ich bitte um Info wenn die Arbeit fertig ist!