Sphere-based drive trains

During a recent idle moment, I started thinking about spherical wheels, spherical gears (I think that one might want to use 3 spheres in order to transmit rotational motion from one sphere to another, as opposed to 1 conventional gear for the same purpose) and (most interestingly) omni-directional electromagnetic motors with spherical (rather than cylindrical) shafts.

Here is (roughly) how the motor would work :

 Make the "shaft" a sphere (d'uh) and cover the surface with a pseudo-random pattern of permanent magnets.

 Put the sphere-shaft in spherical bearings, and surround it with a regular pattern of controllable electromagnets.

 At every time-step, solve for the set of magnetic fluxes (or electric currents) on the pattern of electromagnets to best apply the appropriate delta rotation to the shaft. Or, simpler yet, render (draw) the pseudo-random pattern of magnets on the shaft, rotated by the desired amount, using the controllable electromagnets.

Presumably some clever electrical engineering could measure and/or estimate the orientation of the spherical-shaft by the induced current on the outer electromagnet coils (at least while the shaft is moving). Or, hey, one could just draw a recognizable pattern on the sphere-shaft and use light sensors/emitters to estimate shaft orientation.

SIAM paper

I had forgotten to post this earlier...
Distributed Tree Rearrangements for Reachability and Robust Connectivity
published in : SIAM Journal on Control and Optimization

Scripting, processing.org, images, video, etc

So, at my new job, a bunch of my coworkers are "designer-programmers." Usually these are people who have training in art or design and who teach themselves how to program (often quite well). As one might expect, many of them shifted into C++ and OpenGL after first whetting their appetites with processing.org (which I will simply call "processing" from here on).

Every once in a while I'll run into a quick one-off scripting task whose output (or input!) is an image or a video asset, and my first instinct will be to start looking up scripting language wrappers around things like PIL and ImageMagick. Whenever I express a thought in this vein, invariably, one of the designers will say "Why don't you just use processing?" or "Processing can do that!"

And it turns out that they're right. I have conceded that, even without a strong knowledge of processing, processing is a better tool for quickly programmatically generating images and video than many of the more conventional scripting languages out there (including Ruby and Python). There are two reasons for this. The first of these is that processing gets out of your way, and lets you call visually-related API functionality without having to do a bunch of imports, or the equivalent of "system.out.println instead of printf". The second is slightly more subtle. Processing is structured around the idea that you'll have a setup, a draw, and an event loop, and that the "draw" will draw things, either every frame, or on certain events. It is absolutely amazing how much more natural this is than "print stuff out" for tweaking and debugging programs whose output is (primarily) other visual artifacts.

Back in the graphics world

Leaving Google. Starting at oblong.