Daniel Fütterer – Marlon Schumacher

Human-Computer Interaction, Motion Capture

6DOF Motion Tracking mit Polhemus G4

Abstract: Beschreibung des elektromagnetischen Motion Tracking Systems G4 des Herstellers Polhemus und dessen Software

Verantwortliche: Prof. Dr. Marlon Schumacher, Daniel Fütterer

Das Polhemus G4 System erlaubt das Tracking von Positions- und Orientierungsdaten über magnetisch arbeitende Sensoren. Sender werden im Raum platziert und eingemessen/kalibriert, die Sensoren am zu messenden Objekt befestigt und an kabellose und tragbare Hubs angeschlossen. Diese übertragen die Daten an den PC, der wiederum diese Daten auswerten oder (wie in unserem Anwendungsfall) ins Netzwerk streamt.

Die Software des Herstellers läuft auf Windows und Linux, ist via kodiertem UDP-Export kompatibel mit der Spiele-Engine Unity und besteht jeweils aus mehreren Komponenten für Registrierung, Kalibrierung, Monitoring und Übertragung (z.B. mit Named Pipe oder UDP). Darüberhinaus sind große Teile der Software Open Source, was die Entwicklung individueller Tools ermöglicht.

Unter Linux gibt es eine Suite aus mehreren Programmen:

g4devcfg: Proprietäres Tool zur Konfiguration der Polhemus-Hardware (Dongle und Hub)
g4track_lib: Bibliotheken zur Verwendung mit den anderen Programmen
createcfgfile: Programm zur Erstellung der Config-Files (Aufstellung der Hardware)
g4display: Grafische Anzeige der Sensor-Position und -Orientierung
g4term: Textuelle Ausgabe der Sensor-Daten
g4export (Entwicklung von Janis Streib): Kommandozeilenprogramm zur Übertragung der Sensordaten via OSC

Angewendet wird die Software in Kombination mit Programmen wie Max/MSP oder PureData, die in der Lage sind, den OSC-Stream der Sensordaten auszulesen und zu verarbeiten.

Eine Beispielanwendung wird im Projekt des Studenten Lukas Körfer realisiert: Speaking Objects.

Eigene Software Entwicklungen: Max-Patches

Weitere Entwicklungen von Janis Streib (inkl. Anleitungen):

Für weiterführende Ressourcen, siehe Menüeintrag zu Polhemus unter „Ressourcen“ (Nextcloud)

Vergleich verschiedener Motion Tracking Systeme:

Link (extern)

Demo Videos:

Pilot-Test zur Verwendung der G4export Software (Janis Streib) auf einem Raspberry PI zur Kontrolle eines Virtuellen Mixers über OpenSoundControl.

Proof-of-Concept: Verwendung des G4 Systems zur Kontrolle des Avatars (Headtracking) für die Applikation Binauralix.

Offizielle Videos des Herstellers:

Hinweis: externe Links zu YouTube

VonDaniel Fütterer

git, Markdown, Object-oriented Programming, Python

Changelog-Generator

Abstract: Python-Skript zur automatisierten Erzeugung eines Changelogs (Markdown) aus einem git-Repository (Conventional commits). Work-in-progress

Verantwortliche: Daniel Fütterer, M.A. (Wissenschaftlicher Mitarbeiter), Prof. Dr. Marlon Schumacher

Ressourcen: Software Repository, Wiki Artikel

Die Idee zum Skript enstand aus dem Bedarf, bei öffentlichen Repositories einen unkomplizierten Weg zu finden, Entwicklungsvorgänge anhand eines Logs (Changelog) zu dokumentieren und sauber zu formatieren. Mit Hilfe der Verwendung von Conventional Commits ist es möglich, das zu automatisieren. Conventional Commits ist ein Regelwerk, das einen einheitlichen Aufbau für sämtliche Commit Messages eines Repositorys vorgibt.

Ziel ist es, diese verschiedenen Parameter (type: Kategorie von Commits, scope: deren Umfangsbereich, tag: Versionsnummern, hash etc.) zu erfassen und strukturiert darzustellen.

Das Skript steht in Python, ist objektorientiert implementiert und noch nicht veröffentlicht, mit ihm erzeugte Changelogs sind aber bereits in Verwendung, z.B. Binauralix (Applikation zur Binauralisierung beliebiger Lautsprecher Konfigurationen) von M. Schumacher.

# Beispiel-Changelog (vgl. Beitragsbild)

## Version 1.0

### Features
- *scope*
    - message (short-hash)

### Fixes
- *scope*
    - message (short-hash)

### Other
- *scope*
    - (type) message (short-hash)

### Non-conform commits
- full message (short-hash)

Commits werden nach den Types der conventional commits Syntax sortiert: feature und fix werden separat aufgezählt, andere Typen werden unter other gesammelt. Innerhalb der Types wird nach scope untersortiert; diese werden durch das Skript ausgelesen und gegliedert. Commits, die nicht nach der cc-Syntax erfassbar sind, werden nicht verworfen, sondern am Ende gesammelt. Diese Gruppierung gilt jeweils für eine Versionsnummer.

In der aktuellen Entwicklungsversion sind diese Einstellungen noch statisch, in Zukunft sollen sie dynamisch über Kommandozeilenparameter flexibler gestaltet werden können. Das Programm wird ohne Parameter aufgerufen:

python changelog-generator.py

Daraufhin fragt das Skript den Pfad zum git-Repository ab und wo der Changelog gespeichert werden soll.