I have hooked my twitter to my blogger Thanks If This Then That

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.

Open Source

I am currently open-sourcing or thinking about open-sourcing three pieces of software

1. The simulation platform I used for most of my research in grad school. You can run it and see the results at http://alumni.soe.ucsc.edu/~mds/cclsim/.

   Currently I am in the process of talking to the appropriate people at the University of California about how to do this, as I wrote most of this in the process of research for the UC. Hopefully it'll turn out that language in one of the federal grants I received forces me to open it, or that at least it'll turn out to have so little commercial application that opening it is not a problem.

2. The library and platforms used to generate most of the projects at http://alumni.soe.ucsc.edu/~mds/?News=collapse&Other=expand&Demos=expand#Demos.

   While these were developed when I was a graduate student, most of it was done before I had any research grants, and all of it was done on my own equipment.

   My main hesitation about opening it up is that I'll have to publicly admit to having used "glVertex3f" as late as 2004/2005.

   For what it's worth, a snapshot of the code is at http://www.club.cc.cmu.edu/~mds2/old_ucsc_gl_source/

3. The source for http://alumni.soe.ucsc.edu/~mds/spacecraft_sim/.

   While this project was built on top of the libraries described in the second item, this particular integration *was* done as part of official university research. I'm hoping that the fact that I did it on a NASA grant means I am forced to open it, but because it was done as a University researcher, I am pretty sure I have to go through a different path to open it up.