Welcome! Below you will find the finest selection of my personal engineering confections — a curated assortment of projects that are dearest to my heart. Some were built for work, some for fun. All were handcrafted with care and offer a rich taste of my interests, skills, and the joy I find in building things that matter — at least to me.

   Aim of this project is to explore interactive workspace visualization as a tool for robot cell design as well as robot and tool design. It is the successor of my dissertation project (see below).

   This is what my dissertation is about. It is a force-field-like visualization of different workspaces of a robotic arm:
•  Where can the TCP go in a straight line from its current position while maintaining its current orientation?
•  How far can the TCP twist while maintaining its current position without hitting a joint limit?
•  What points are reachable in general (not just in a straight line) in a configurable set of orientations? All this is computed on-the-fly on the GPU and changes as the robot moves. It can be used for designing robots, tools and the environment around robots. It does not consider collisions yet because that would have been too tough to implement on GPU but with today's CPU power it is probably feasible.
   UPDATE: See project above.

   I needed computationally cheap and interactive water for a game, so I came up with this idea. It has become my most starred github repo!

   When working with Python on robotics projects, I often felt it lacked a good and lean tool for handling transformations. I had issues with all the tools out there, so I decided to create my own.
   I also wanted to demonstrate the advantages of open source to my employer and since we were not allowed to open source our work, I wrote it in my free time. As there were no deadlines, I took the opportunity to do everything properly: an idiomatic API, proper testing, proper documentation, proper code checks.
   It took a lot of work but I learned a ton and I hope it catches on. Tell your colleagues, friends and family about it ;)

   At Gestalt, we've quickly reached the limits of what MoveIt can do and I found it extremely difficult to extend it with new functionality. So instead I built a custom trajectory planner. It has some features which sets it apart from the competition, including a very efficient way to handle orientation constraints and an also very efficient way to verify the collision-freedom of large joint motions. Unless I am allowed to open source it, which I am trying, I can't disclose much more.
   UPDATE: I was allowed to open source it! https:/​/​github.com/​mqnc/​kite-motion-planner

   II-VI HIGHYAG wanted to mount their laser welding head which can cover a small volume with high speed via mirrors to a robot arm to increase the workspace. The robot should automatically sweep the welding head workspace over all seams while the laser welds them. This is essentially a TSP but with some exciting twists: Some seams are very long but need to be welded in one go, which kind of maps to a portal from one town to another in TSP space. Another is that the traveling salesman is not a point but has a large volume (laser head workspace) and can cover multiple towns at the same time. This was one of the most interesting challenges I've ever worked on.

   JSON is a very elegant and intuitive file format for representing data. However, it does not support NaN, ±infinity, or comments. I've been trying to work around these limitations (using "//":"my comment" for comments, null for NaN, and 1.79769E+308 for inf) but all of that is very inconvenient and feels wrong. The desire for these features is strong, several parsers support some of them. Python's json optionally supports NaN, Infinity, -Infinity. nlohmann/json optionally supports comments. But there is no interoperability.
   I've looked at other file formats. XML is overly verbose and does not really match the object structure in programming. YAML is not an option because of these points https:/​/​en.wikipedia.org/​wiki/​YAML#Criticism and because it very annoyingly has significant indentation. The situation with TOML is almost the same: https:/​/​dev.to/​siddharthshyniben/​why-not-toml-1fj9.
   Then I came across Hjson and JSON5, they both solve everything. I like JSON5 more because of its compatibility to JavaScript and because it has an official spec. However, there was no C++ implementation for it, so I created one. I directly translated the reference JS implementation and all the tests.

   I have a constant love-hate relationship with C++. It's designed in a way that the compiler has to read everything only once, so I have to write everything twice. Its strong focus on backwards compatibility means that every new feature must have been a syntax error before and that's what C++ looks like today. Lzz3 brought some relief but is outdated now.
   I went through several insufficient iterations to make my life "easier", from tons of preprocessor macros to a custom regex-based preprocessor to proper languages that transpile to C++, of which Cinnamon is the latest iteration.
   Then I learned that Herb Sutter went down the same road and created Cpp2. I was expecting that his project will probably be more popular than mine and got both discouraged and excited because I'm also happy if he solves all my issues. However, it doesn't look like Cpp2 will be production-ready anytime soon so I might go back to Cinnamon.

   While working on Cinnamon (see above), at some point I got unhappy with the transpiler being based on Lua and decided that I need to write an appropriate transpiler tool first. I stumbled upon Ometa and was very pleased with it. However, there is no C++ implementation, so I decided to create one.
   I was also intrigued by the idea that the to-be-transpiled source could configure the transpiler to understand custom syntax, something I only know from Felix (https:/​/​felix-lang.github.io/​felix/​) (apart from the somewhat inconvenient C preprocessor macros). This would also allow for custom infix operators with custom precedence and custom associativity. So I built Ometa-C++ in a way that facilitates that idea.
   It is in a state where it is almost feature-complete and usable, however I lost interest in it as I lost interest in Cinnamon with Cpp2 on the horizon.

   For my little daughter I wanted to have an animal poster that contains ALL 240 different animals there are, so like any good father I searched the whole wide world wide web for animal photos and created a custom kind-of-physics engine in order to puzzle all these concave shapes together into a nice poster (the link above is just a debugging screenshot, not the poster).
   I was very pleased with the result and several friends and our kindergarten also wanted one. I wanted to turn animal posters into a business before AI can create something like that in 10 seconds but I got discouraged by how much bureaucracy it is to do a business tax declaration in Germany. One day I will still give this a shot.
   UPDATE: I am now giving this a shot! https:/​/​www.kidposter.de

   Let's be honest! We all started programming because we wanted to make video games when we were kids!
   I've been working on this game together with my cousin since we've both been going to school. We both love the shopping-cart-like vehicle control from Asteroids, so we wanted to build a multiplayer game around that. We went from C++ to Blitz3D back to C++ to Java to JavaScript to TypeScript. I've learned about all these languages, a ton about computer graphics, physics engines and software architecture in general from that. It's not done yet — but one day, it will be!

   My latest procrastiject! :) What I want to try out here:
•  realistic-feeling drone control
•  3d physics in the browser
•  dedicated worker for physics
•  fisheye camera
•  motion blur
•  shadows
•  light baking