LEGO Othello board

I have a weird bucket list. One remaining item was to create a full-size, playable Othello board, with ridges to avoid discs from moving around. I finally decided to try and mimic an existing board. The result looks pretty close to the original:

Unfortunately I was unable to figure out how to create smooth (and yet flat) discs, but they are at least quite playable. Suggestions for improvements are welcome. I'd also be happy to share more information or even a parts list anyone would like to recreate it.

Shed Skin restricted-Python-to-C++ compiler 0.9.7

I have just released version 0.9.7 of Shed Skin, a restricted-Python-to-C++ compiler. The highlight of this release is native Windows support, by moving to CMake (and Conan). Shakeeb Alireza came up with this idea and did most of the implementation. So to build something on Windows, one doesn't need a weird emulation layer like MingW anymore, just Visual Studio build tools, CMake and Conan (popular tools that many will already have installed). He also made sure that most things work under OSX. Here is a screenshot of an (also) new DOOM-engine example running under windows:

With the recent Python 3 and now native Windows support (plus an ever growing Python community), I'm hoping the project will see more usage and feedback/contributions over the coming years. Please consider joining the project, as there is always enough to do!

Besides other contributions from Folkert van Heusden and Humhue, the release comes with many other improvements, such as support for relative imports, the walrus operator and struct.pack_{from, into}. See here for the full release notes.

Fast DOOM WAD renderer in 999 lines of Python

For the longest time, I've wanted to re-implement the original DOOM engine in Python, and compile it with Shedskin to get reasonable performance. So when I finally ran across a pretty small engine written in Java, by Leonardo Ono, I decided to convert his version to Python.

I left out some optimizations (most notably "visplanes"), for readability and in order to keep everything under 1000 lines of code (while following PEP8). So it could run quite a bit faster still. This is including a WAD loader and interactive Pygame wrapper, that makes it almost feel like you are playing DOOM.

It's interesting how using Python (using just CPython) seems to be about as fast as using assembler back in the day.

This video shows the day-and-night difference in FPS after compilation using Shedskin.

The source code can be found in the Shedskin examples directory.

I may revisit the code now and then, to try and improve readability by adding comments and/or refactoring parts. Patches in this direction very much welcome of course.

Shed Skin restricted-Python-to-C++ compiler 0.9.6

I recently decided to sit down and finally port Shed Skin, an experimental restricted-Python-to-C++ compiler in the works since 2005 or so, to Python3. Three painful months and a total diff of 50k lines later, everything now works with Python3 (Shed Skin itself, and all tests and examples..)

This does not mean that every Python3 feature is supported, but what was there now at least works fine with Python3.. For example, unicode is still restricted to 1-byte characters, and there is no support (yet) for nice new features such as f-strings. Python2 support has been dropped with the new release, and subsequent releases should add support for various new Python3 features.

The following people have contributed along the way:

• Johan Kristensen (large patch for moving from compiler.ast to ast, still on Python2)
• Shakeeb Alireza (extension module support for Python3, ported many examples, improved OSX support, and various code cleanups)
• Folkert van Heusden (some fixes on the C++ side, move to c++17)
• Jeremie Roquet, Thomas Spura, Paul Boddie and others who kept doing maintenance on the project in my absence

I started work on the port after realizing that Shed Skin was being removed from distributions, especially Debian, as it was still tied to Python2, and I really want to keep Shed Skin in a working state if possible.

So what about the future of the project? Not really sure, but I'm happy to sit down again in a few months to prepare a new release. Any feedback on what to support or improve would be very welcome!

For fun, here are screenshots of some of the Shed Skin example programs (in total 75 working example programs can be found on the github site):

TACO VR: an Infento-based omnidirectional treadmill (unfinished prototype)

The initial excitement of owning a wireless headset such as the Oculus Quest is quickly followed by disappointment in the size of one's living room. Unfurtunately there does not seem to be a solution to the problem of not being able to move around by more than a few meters without using the controllers in an awkward manner, or a satisfactory solution to me at least. For example, I really feel like one should also be able to walk up and down hills, or climb stairs and that such a thing should be possible.

There are various categories of existing solutions, each with significant downsides. There are the infinideck-type omnidirectional treadmills, which seem really expensive and bulky by design, and probably very noisy as well. Not that great for most living rooms. And as I mentioned, they cannot offer up/down movement without a completely separate system. Then there are the 'gliding bowl' solutions such as the kat-vr. This works, and to be honest I haven't tried one, but this just cannot feel very realistic. I do appreciate the elegant, cheap solution, and I mean that as a compliment. But again, there is no possibility for up/down movement. Finally, there are the prototypical "magical" shoes, that can perhaps move up and down in theory, but having to wear (bulky) shoes doesn't do it for me either. I want to be able to "feel" the ground with my own shoes, or even with my bare feet.

With this blog post, I would like to introduce my own type of solution. I'm sure others have thought of similar things, and it's not entirely finished either, so I can't yet say if it will work like I think it will or if it will turn out to be a dead end. I have mostly just been having fun working out the mechanical concept using Infento, which is a highly-recommended product for protopying sturdy mechanical devices (initially developed for making/rebuilding children's bikes). I also had to 3d print some gears, as Infento doesn't sell these (perhaps out of safety concerns - you really don't want to have kids fingers in there..).

I was worried that some Infento parts would not be strong enough to hold my weight, but so far they have held up great.

The core idea is to have a central 'rail system' that rotates with the line between your feet. Each foot has its own moving platform on this rail, that (after adding sensors and motors) follow the respective foot, and ultimately catch the foot as it comes down. After catching a foot, and based on the motion and direction of the other foot, the platform moves back to a natural position to continue walking or may stay in the same place (for example while the user is turning). But all of this is a bit hard to explain, so I tried to film the general idea (note of course that for a final solution it should be possible to lift your feet and walk/turn naturally!).

Video showing movement

The gears connect to the stationary base plate and make sure that the platforms are always facing the same direction, much as the tiles of your floor. The same effect could be achieved by adding more motors, but I thought this was interesting anyway, and probably cheaper and more silent in the end as well.

So while there is no support for up/down movement at the moment, it is clearly possible to make the platforms go up and down, or potentially even tilt (slightly).

If this were to become a real product, for safety there would probably need to be a large circular encasing (could be much more flat!), plus something to catch you if you lose your balance, much like the other solutions. The platforms would stick out of a slit in the middle, again potentially moving up/down. It would not be cheap, but could perhaps be relatively cheap when built as an open source kit. But to be honest, I'm not sure I will ever continue work on this prototype, so I'm just putting it out there.

Additional photos

update: I've started to collect specifications, parts lists etc. on github.

interlocking modular origami unit 2 (IMORU2)

The original Sonobe modular origami unit is almost like a "lego block" for origami structures, but falls short in that the result is often not very rigid and/or falls apart without using adhesives. My previously published unit, called IMORU1, utilizes interlocking hooks to work around this problem.

It works a lot better, but after playing with it further for a while, I realized it also has two annoying issues: the hooks are a bit difficult to insert (and arguably a bit clunky/inelegant), and much worse, it is still not always completely rigid at the corners.

So I went back to the drawing board, and finally found something which has easier to insert hooks, is rigid in all corners and is actually also easier to fold. I'm not sure if it can still be called a Sonobe variation, but it's definitely inspired by it. This time I also tested it better. Here are some basic example structures:

And here's the diagram of how to fold it.

Photo of the completed unit:

Finally, a youtube video showing how to fold and join units.

Now, there still is one minor issue left with IMORU2, in that edges are not always taut, but this is basically cosmetic and doesn't affect its functionality. I may try to find an improved IMORU3 sometime in the not too distant future. But for now, let's first try to fold a few thousand of this.. O_o

Update: The diagram, plus some more details, were added to the OrigamiUSA diagrams page.

Prusa MK2+MMU

I recently built a Prusa MK2 + MMU (multi-material upgrade), using only PLA parts printed on my T3P3 delta printer. I wasn't entirely sure PLA was going to work for the extruder parts, as the parts that come with the kit are printed in ABS. After more than 100 hours of printing with it, I think it's safe to say that this works just fine, at least when printing with PLA (at around 200 degrees celcius).

The multi-material upgrade is a lot of fun. I had a minor issue at first, where the filament would repeatedly get stuck at the end of the cooling tubes. I decided to ream the filament path(s) below the cooling tubes with a 1.85mm drill, and haven't had an issue since (knock on wood). I love the simplicity of the whole thing, and the ease with which the multiplexer opens up to debug any issues.

For anyone interested in getting a multimaterial upgrade, it's probably good to know that the normal wipe tower settings don't work very well for especially black filament. In order to avoid filaments 'colour bleeding' into each other, I usually had to double the wipe tower size. In combination with constant filament switching, this means you should be prepared for very, very long prints, across multiple days for moderately large objects (with many colors). The large kirby above (about the size of a tennis ball) took 11.5 hours to print. Another thing to consider is that print quality seems to suffer sometimes, I guess because of the bowden setup, especially if a color is only used for a small detail (see for example the eyes of the small omnom above.) Interestingly, it seems that this depends on filament (color).

I will play more with multicolor prints in the future (when hopefully there will be filament available with less bleeding, as well as per-filament settings for the wipe tower!). I will also play more with supports, and hopefully print my SNES controller again with it. I already printed a donkey using BOVH for support, and found out that doubling the wipe tower is also a good idea with supports, or the main part may become brittle: