Felix Pfarr

Ein privates System, das ich vollständig selbst betreibe. Es sammelt, was ich an einem Tag esse, wie ich mich fühle, was ich tue, wie meine Vitalwerte aussehen und wie die Luft in dem Raum ist, in dem ich gerade sitze. Ziel ist es, Zusammenhänge sichtbar zu machen, die ohne durchgehende Messung unsichtbar bleiben, etwa zwischen Sport am Vortag und der Stimmung oder zwischen Luftqualität und Konzentration.

Kern ist eine Django Anwendung, die Ernährung und Kalorien pro Tag erfasst und gleichzeitig als REST-Schnittstelle für alles andere dient. Zwei selbst gebaute Flutter Apps schicken Stimmung und Aktivitäten dorthin. Im Raum hängen ESP32-Boards mit BME680-Sensoren für Temperatur, Luftfeuchte, Luftdruck und Luftqualität. An jeder Tür klebt ein NFC-Tag. Einmal mit dem Handy scannen, und ein Aufruf der Schnittstelle startet die Sitzung für den Raum, in dem ich mich aufhalte. Die Vitaldaten meiner Fitbit Inspire 3 holt ein eigener Import über die Google Health API dazu.

Die Rohdaten landen in MySQL. Apache Airflow DAGs räumen sie auf, bringen die sehr unterschiedlichen Quellen in ein gemeinsames Format und legen ML-fähige Datensätze ab. Modelliert wird in einer Anaconda-Umgebung mit TensorFlow und scikit-learn.

Der Betrieb gehört zum Projekt dazu. Alles läuft auf einem Proxmox Hypervisor bei mir zu Hause, aufgeteilt auf getrennte Ubuntu Server VMs für die Django Anwendung, die MySQL Datenbanken und die Analyseumgebung. Virtualisierung, Netzwerk, Nutzerrechte, Backups und Updates liegen damit genauso bei mir wie der Code.

• Django
• REST-API
• Flutter
• ESP32 / BME680
• NFC
• Google Health API
• MySQL
• Apache Airflow
• TensorFlow
• scikit-learn
• Proxmox
• Virtualisierung
• Ubuntu Server

Mehr zum Projekt Code auf Anfrage

Ein Franka-Emika-Panda greift ein selbst in Fusion 360 konstruiertes, chirurgisch nachempfundenes Instrument, hebt es an und legt es an einer Zielpose ab. Gelernt hat er das in NVIDIA Isaac Lab mit PPO, in 4.096 parallelen Umgebungen. Ein U-Net liest anschließend aus dem Kamerabild ab, ob das Instrument gerade getragen wird.

Untersucht habe ich nicht, ob das funktioniert, sondern was passiert, wenn sich die Bedingungen ändern. Die Greifpolicy fällt von 95,6 auf 78,0 Prozent Erfolgsrate, sobald der Bereich der Objektstartpose um 60 Prozent wächst, und zwar gleichmäßig und ohne Kipppunkt.

Beim Segmentierungsmodell entscheidet dagegen die Breite der Randomisierung über alles. Auf der eigenen Verteilung kostet sie 0,01 mIoU, unter unbekannten Bedingungen trennen die beiden Stufen 0,55. Die schmal trainierten Modelle werden dort nicht ungenauer, sie brechen zusammen. Breit zu randomisieren ist damit fast kostenlos und entscheidet trotzdem über Erfolg und Totalausfall.

• Fusion 360
• NVIDIA Isaac Sim
• Isaac Lab
• rsl_rl
• PPO
• Domain Randomization
• U-Net
• Python

Mehr zum Projekt Arbeit auf Anfrage

Aus HAM10000 habe ich Bildpaare in 64x64 und 256x256 Pixeln erzeugt und in TensorFlow ein SRGAN gebaut, das die niedrige Auflösung wieder hochrechnet. Die eigentliche Untersuchung kam danach, denn anschließend lief derselbe Klassifikator über alle drei Varianten.

Er erreicht 71 Prozent Genauigkeit auf den niedrig aufgelösten Bildern, 74 Prozent auf den echten hochaufgelösten und 78 Prozent auf den hochskalierten. Die Rekonstruktion schlägt also das Original. Bei Melanoma, der klinisch wichtigsten Klasse, fällt die Trefferquote gleichzeitig von 0,79 auf 0,54, was die gute Gesamtzahl deutlich relativiert.

• TensorFlow
• SRGAN
• VGG19
• EfficientNetB0
• Transfer Learning
• OpenCV
• HAM10000
• Python

Mehr zum Projekt Ausarbeitung auf Anfrage