NXT Drawbot

When I saw this drawbot, I immediately thought it was something I should be able to recreate with Lego Mindstorms. And so I did. The idea is simple, there's a pen suspended on thread from motors in the corners. When the motors wind or unwind the thread, the pen moves and draws a line. The rest is a simple application of the Pythagorean theorem to move the pen where we want it.



When watching other drawbots on YouTube etc. I was surprised to see they were able to achieve a level of precision that allows them to recreate pictures by effectively drawing each of their pixels with clever patterns. My bot clearly lacks such precision. I think the main reason for that is the friction between the pen and the drawing surface. Each time the pen is about to start moving, there's a noticeable moment before it breaks away from the static friction. That makes the bot incapable of very small precise movement. There's another source of imprecision - since the radius of the spools that the threads are wound onto is small, the difference in radius when there is no thread wound and when there is a lot of thread wound on the spool is non-negligible.

Here are some more pictures of the bot.

Google Earth with a PS3 controller

Google Earth is a lot of fun with a 3D input device. But not everyone can justify shelling out a hundred bucks or so on a SpaceNavigator just to play with Google Earth. I've explored other possibilities, but the best alternative I've come up with is the PS3 controller. It has more than enough joysticks and buttons for five degrees of freedom. Have a look:

The PS3 controller is pretty well supported under Linux (at least if you connect it with a USB cable, it's more complicated if you want to use Bluetooth). The only problem really is mapping its various buttons and joysticks to proper functions in Google Earth. Fortunately, there is a piece of software called pystromo that can freely remap input events, thus allowing us to turn a PS3 controller into a SpaceNavigator-lookalike.

Here's what you need to do.

• Download and unpack pystromo.
• Open the lib/constants.py file in the pystromo directory with a text editor. Find the line containing "ABS_MISC" and add the following two lines after that (before the curly brace):

  48: "ABS_L2",
  49: "ABS_R2",
  

  (We have to do this, because pystromo doesn't have constants for the PS3 controller's L2 and R2 buttons.)
• Create a new file in the pystromo directory and call it, say, config/ps3-ge.map. Put the following in it:

  [Device:dualshock]
  vendor=0x054c
  product=0x0268
  
  [Map:dualshock]
  ABS_X@0~255:ABS_X@0~255
  ABS_Y@0~255:ABS_Y@0~255
  ABS_Z@0~255:ABS_RZ@0~255
  ABS_RZ@0~255:ABS_RX@255~0
  ABS_L2@0~255,ABS_R2<1:ABS_Z@127~0
  ABS_R2@0~255,ABS_L2<1:ABS_Z@127~255
  

• Connect your PS3 controller using a USB cable and press the PS button.
• As root, run the following command: ./pystromo-remap.py -R -v -m config/ps3-ge.map
• This will create a new input device, called eventN in /dev/input/. The one you're looking for is the one with the highest number. As root, run this to give your regular user access to the device: chmod 666 /dev/input/eventN
• Open /opt/google/earth/free/drivers.ini with a text editor and put the following after the "SETTINGS" line (after the curly brace), remembering to replace eventN with the proper device number:

  SpaceNavigator/sensitivityX = 0.4
  SpaceNavigator/sensitivityY = 0.4
  SpaceNavigator/sensitivityZ = 0.1
  SpaceNavigator/sensitivityPitch = 0.05
  SpaceNavigator/sensitivityYaw = 0.05
  SpaceNavigator/sensitivityRoll = 100
  SpaceNavigator/device = /dev/input/eventN
  SpaceNavigator/zeroX = 127
  SpaceNavigator/zeroY = 127
  SpaceNavigator/zeroZ = 127
  SpaceNavigator/zeroPitch = 127
  SpaceNavigator/zeroYaw = 127
  SpaceNavigator/zeroRoll = 127
  

• Run Google Earth.

You should now be able to navigate using the left and right sticks and L2/R2 buttons.

Control Google Earth with an Android tablet

I have previously described how to turn an Android device into a mouse under Linux, using the uinput module. There's no reason we should limit ourselves to a simple mouse. Some applications benefit from a multi-axis controller, which we can simulate in a similar way. One such application is Google Earth. Here's a demonstration video:

And here's how it's done. Just as before, there's an application running on the tablet that listens for touch events and broadcasts them on the network and a Python script running on the computer that listens for those events and translates them to simulated controller events that Google Earth understands. Here's the tablet application's source code and here's just the APK if you don't want to compile it yourself. The Python script that's running on the computer is here.

There are some additional hoops you have to jump through to get it running.

• The Python part requires python-uinput, which in turn requires libsuinput.
• Remember to unblock UDP port 20125 on your computer's firewall, as that's the port that the tablet application uses to broadcast touchscreen events (the tablet and the computer obviously have to be on the same network).
• Run android3dmouse.py as root.
• Run the TouchscreenBroadcaster3D application on your Android device and touch the screen (the simulated mouse device only appears on the computer after the first events are emitted).
• Look in /dev/input/ and figure out what the newly created device is called (it's going to be the eventN file with the highest number).
• As root, execute the following command to let Google Earth running as a regular user access the device: chmod 666 /dev/input/eventN
• Open /opt/google/earth/free/drivers.ini with a text editor and paste in the following after the "SETTINGS" line (after the curly brace), remembering to replace eventN with the proper device name:

  SpaceNavigator/sensitivityX = 80
  SpaceNavigator/sensitivityY = 80
  SpaceNavigator/sensitivityZ = 30
  SpaceNavigator/sensitivityPitch = 0.5
  SpaceNavigator/sensitivityYaw = 0.5
  SpaceNavigator/sensitivityRoll = 0.5
  SpaceNavigator/device = /dev/input/eventN
  SpaceNavigator/zeroX = 0.0
  SpaceNavigator/zeroY = 0.0
  SpaceNavigator/zeroZ = 0.0
  SpaceNavigator/zeroPitch = 0.0
  SpaceNavigator/zeroYaw = 0.0
  SpaceNavigator/zeroRoll = 0.0
  SpaceNavigator/gutterValue = 0
  

• Since X happily grabbed the new device and it now moves the mouse cursor, execute the following command to make X let it go: xinput set-int-prop "python-uinput-mouse" "Device Enabled" 8 0
• Finally, run Google Earth.

You should now be able to pan, zoom and rotate via multi-touch gestures on your tablet's (or phone's) screen. (Yes, one more degree of freedom would be nice, but I haven't figured out a good way to do it yet.)

If you can't get this mess to work, I'm not the first one to do something like this, there's a Google Summer of Code project done by Reese Butler that works in a similar manner, but uses a slightly different control scheme. The Android part is on the Market and the computer part can be found here. Maybe you'll have more luck with that one.

Android phone as a touchpad for a PC

The Linux kernel has a module named uinput that allows userspace programs to simulate input devices like mice, keyboards and joysticks. I used this neat mechanism to turn my Android phone into a touchpad for my computer.



Here's how it works. On the phone there's an application that broadcasts touchscreen events over the network. You can get the application's source here. On the PC there's a script running that listens for the events and translates them into mouse events that get injected into the system via uinput, at which point the X server sees them and moves the mouse pointer accordingly. That part is written in Python and requires the python-uinput module (which in turn requires libsuinput). You can get its source here.

As always, there's room for improvement. I used my phone's trackball as left mouse button, but for phones or tablets that have no trackball it would probably make sense to use some regions of the screen as buttons. It would also be interesting to add multitouch gestures for scrolling and zooming. Another thing that comes to mind is to use the phone as a 3D controller for Google Earth. Four degrees of freedom should be doable with the touchscreen alone via two-finger gestures and maybe we could use the phone's other sensors like the accelerometer and gyroscope (which my Nexus One lacks, but newer phones have them) to get all six.

On keyboards

Many people don't care about keyboards. I do. But unlike most keyboard enthusiasts, who focus on the switches (mechanical vs. rubber dome etc.) and are prepared to give long lectures on buckling springs and how the IBM Model M is the greatest keyboard of all time (which is probably true), I don't care that much about switches. I can't stand keyboards with wrong key layouts. I don't mean Dvorak vs. QWERTY, I mean the physical layout of the keys. And by "wrong" I mean pretty much any layout that's different from the standard full-size one. (That's one of the reasons I don't see myself using a laptop for anything serious anytime soon.)



Fortunately, most full-size keyboards have sane key layouts. There are two issues with modern keyboards that drive me crazy. One is the "menu" key introduced by Microsoft some time around Windows 95. Notice that I don't even mind the Windows logo keys that much. An additional modifier key is sometimes useful. Mac keyboards have three modifier keys on the bottom row, classic Unix keyboards often had them as well. I don't even care that it's the Windows logo, not some OS-agnostic symbol. But the "menu" key? What is it for? I don't think I've ever seen it used for anything. It's useless and it messes up the symmetry of the layout (three modifier keys on each side of the space bar). It also means the space bar is too short. So that's the first of my keyboard-related pet peeves. As you're about to see, I care about the second one much more deeply.



Numeric keypads. I hate them. I guess they're useful if you're an accountant and must input a lot of numbers into your spreadsheets. I'm not an accountant. I imagine to most people the numeric keypad is as useless as it is to me. The last time I remember using it is when we were playing Mortal Kombat fifteen years ago. So what, I hear you say. Just don't use it. But you see, it takes up space that I need for something else, namely the mouse. I need my keyboard positioned so that the monitor's symmetry axis goes between the G and H keys. That way my arms are positioned in a natural symmetric way when typing. That means that if my keyboard has a numeric keypad, the mouse goes too far to the right. I'm pretty sure it's not just annoying, but also not good for my posture.



What can we do about this sad state of affairs? Aren't there any good keyboards? Well, there are. Bad news is, they're not exactly cheap. I have two candidates for "the perfect keyboard". One is the space saving variant of the previously mentioned Model M:



In a lot of ways, it is the Holy Grail. An elegant weapon for a more civilized age. No numeric keypad, no stupid Windows keys. Built like a tank. Likely to outlive its user. There are downsides though. And I'm not even talking about the loud click, which is sure to drive your coworkers and roommates crazy. Problem is, the keyboard is long out of production and it is the less popular variant of the Model M. So when one of them shows up on eBay, it easily goes for more than 200 USD.

Is there no keyboard with all the right features that is still in production? As it happens, there is, the Realforce 86U:



As you can see, it has the Windows logo keys, but as I said, they don't bother me. What's important is that there's no "menu" key next to the right Control. And no numeric keypad of course. What's the catch? The keyboard might be in production, but it doesn't mean it's cheap. It currently goes for 265 USD on EliteKeyboards. Ouch.

I'm not aware of any cheaper keyboards that would match all my criteria (no menu key, no numeric keypad, standard full-size layout otherwise). If you're not ready to shell out two hundred bucks or more on a keyboard, you have to start making compromises. The one I'm probably willing to make is to accept the menu key. I still think it's extremely idiotic, but I guess I can live with it. If we allow the menu key, that opens up several possibilities in the 100-150 USD range. EliteKeyboards currently carries some nice keyboards from Leopold and Amazon has several Filco Majestouch keyboards to choose from. Both brands seem reasonable, but they're still a bit pricey. Like I said, most keyboard geeks obsess about the mechanical switches ("Cherry" switches in the case of Leopolds and Filcos) and they don't come cheap.



An important thing to know when looking for keyboards with no numeric keypad is that they're called "tenkeyless". Don't waste your time looking for "space saver" keyboards as they're almost always some ugly layouts that keep the numeric keypad, but drop the arrow keys/page up/page down area (a notable exception is the Model M mentioned above). I really don't understand the thinking behind such layouts. What I understand even less are the laptop keyboards with numeric keypads. And they are getting popular. I guess on 15-inch and bigger laptops there is enough space for extra keys, but why would you waste it on a numeric keypad and not, say, reasonable sized arrow keys and page up/page down etc. Another problem with such laptops is the already mentioned asymmetry. It's impossible to position your arms comfortably when typing, when the home row of the keyboard is shifted to the left (and obviously you can't reposition the laptop's keyboard in relation to the screen).

One day Logitech will make a nice, cheap, "tenkeyless" keyboard. But it probably won't be tomorrow, so what can you do in the mean time? Well, you can take inspiration from this guy, who shares my dislike for numeric keypads, take a keyboard that has a numeric keypad and... chop it off. It's what I did to a Logitech UltraX:



It turned out to be more difficult than I thought (the keyboard looks cheap, but there's a metal plate inside that I had to saw off) and it may not look pretty, but in the end I have a keyboard with a reasonable layout that didn't cost an arm and a leg. If you want to try it yourself, some instructions can be found on wikiHow. Obviously the details will depend on the exact keyboard model that you choose to lobotomize.

If you're considering becoming a keyboard otaku, I strongly recommend that you check out geekhack.org, they have an active forum and a wiki with more information on keyboard switches than a sane person needs.

Update (September 2012): As of right now, the CM Storm Quick Fire Rapid seems to be the most reasonably priced tenkeyless keyboard. The Cherry MX blue version goes for 64 USD on Amazon.

Update (August 2013): I just found this HP keyboard, not very pretty, but with mostly correct layout and only 26 USD on Amazon.

Dominoes

A few years ago I was briefly interested in physics engines. Nothing ever came out of it, but I did make a few experiments. Here's one of them:



It uses the Bullet engine and I'm actually quite surprised that I bothered to make a relatively polished interface for placing the tiles. I was somewhat less surprised with the fact that it didn't compile after sitting on my hard drive for a few years. It turns out that there were some incompatible changes in Bullet since then, so I had to make a few modifications to make it run with recent versions.

If you want to play with it yourself, here's the code (be warned it's ugly inside, though).

Hippo Paint

My three year old niece likes to sit in front of Google Image Search and look at pictures of dinosaurs (and frankly, who doesn't?). Every once in a while there's a coloring book style picture and she wants to paint it. The best I could come up with on short notice was to print out the picture and give her crayons. But obviously there had to be a better way.

Enter Hippo Paint.



It should work in all modern browsers (it even works in IE9). While making this I could clearly see that JavaScript engines in browsers really are getting faster (for example there's a big difference between Firefox 3.6.x and 4.0), but you still have to make all the trivial optimizations like function inlining or common subexpression elimination by hand.

I also encountered an interesting bug that only manifested itself in Opera. I had a piece of code that looked something like this:

var img = new Image();
img.onload = function() { /* ... */ };
img.src = '...';

And sometimes the onload handler function wasn't getting called (even though I could see that the image was successfully fetched from the network). After a frustrating debugging session I noticed that it only happened when fetching the image took longer than usual (say, more than a second). It turns out that it gave Opera's garbage collector enough time to kick in and collect my img variable. I don't know if other browsers don't have as aggressive garbage collectors or if they think that the existence of an event handler is enough to mark the variable as still needed. Anyway, the solution was simply to move the variable to an outer scope.

I hope you and your kids have as much fun using Hippo Paint as I had making it.

Pivot screen fun

I used to think pivot monitors were only good for playing Pac-Man in portrait position. But why restrict ourselves to just the landscape and portrait positions?



Since the monitor only knows two states, I had to resort to a little trick. I attached my phone to the back of the monitor and wrote an application that broadcasts orientation data from the phone's accelerometer on the network. On the computer, another application receives the data and rotates the teapot accordingly. (Here's the source code to the phone application and the teapot application if you're interested.)

What I really wanted to do was to make the desktop rotate with all the windows. I think it should be possible with Compiz, but I'm pretty sure it would prove difficult enough for me to lose interest halfway through. So, a teapot for now.

Morse Code Reader

I wanted to make a Morse code reading application for some time now. Here's my first attempt, it listens to the signal through the phone's mic and translates it to text:



I'm sure there are all kinds of advanced signal processing techniques that I should be using, but for now I went with the simplest, most naive approach. And it sort of works, except when it doesn't. What I do is I keep an exponential moving average of the signal's volume and I decide that the signal is currently "high" when the average is above a threshold and "low" when it's below it. The threshold is set based on recent peak volume. Then I try to decide what the length of a dot and a dash is, interpret the input accordingly, and finally translate the dots and dashes to letters. The application adapts to changing volume and speed within reasonable limits (it should work up to about 40 WPM).



I was hesitant about putting the application on Android Market, as I only tested it on my phone and it quite often fails at translating Morse code. Then again, it's not like I have anything to lose by getting 1-star reviews and insulting comments, so why not.

Here's a Market link.

Page turner Mark II

I have improved my initial page turner design. Thanks to a third motor that repositions the rubber wheel between the left and right of the book, we can now turn pages in both directions!



The device is still manually operated and the problem of sometimes grabbing more than one page remains. But it is now less of a problem, because if we go a few pages too far, we can always go back.

Automatic page turner

Reading books is hard enough as it is. They're often long, boring and some don't even have any pictures in them. I decided to at least eliminate the physical effort of turning pages and constructed this little device:



At the moment it's not entirely automatic as I'm still controlling the individual motors manually (via Bluetooth from my phone, which is off-screen, because I'm also using it to shoot the video). The setup requires some tweaking for the exact size of the book and probably only works for a certain range of pages in the middle of the book. It also still sometimes grabs more than one page. But hey, it's a start. There's obviously room for improvement, for example it would be nice to be able to turn the pages in both directions. (Update: Here's an updated version that does that.)