As is de rigueur, all the code is available on github.

The Minitel/Tumblr Time Tunnels will be on display at this year’s NYCR Interactive Party. Be sure to come by and see the internet the way it positively demands to be seen!

Since the theme of the party is “Digital Archeology”, all of the control stations are being built from repurposed dead hardware. There’s a patch panel, push buttons, strobe lights, more push buttons, quadrature knobs, oscilloscopes, and maybe even a teletype to keep score.

Each console will have a Raspberry Pi with Wifi to talk to the other consoles, some number of Teensys to talk to the real world, and some sort of glitchy way to communicate to the operator (like an NTSC TV or a Minitel). If things don’t work right, that’s part of the fun. And, of course the source code will be available for you to build your own Future Crew Consoles.

Tickets for the party are on sale now!

The IK solution uses the DH Parameters to compute the three joint angles for the major axes (the rotation around the stalk, the upper-arm angle, and the fore-arm angle) such that the center of the spherical joint will be placed at a given XYZ position. There are two binary additional binary parameters for this configuration: RIGHT/LEFT controls the orientation of the arm on the right or left side of the stalk, and OVER/UNDER for the configuration of the elbow pointing up or down. See figure 5 in the paper for a diagram of the four possible combinations of these two parameters.

Once the first three theta angles are known, the second phase of the IK solution computes the last three wrist joint angles given the third binary parameter UP/DOWN, and three vectors: the “approach vector” a[] that points in the direction of the tool, the “sliding vector” s[] that points in the direction of the grasping joint, and the “normal vector” n[] that points towards the top of the tool. Figure 4 from the paper shows the relationship of these three vectors in the hand coordinate system.

This video shows the IK iterating between two points (in RIGHT and OVER mode) and generating a piecewise linear path that holds the tool (a cheap pen) mostly level on a constant heading aligned with the X axis. It is a little jerky since the motor controllers don’t have a way to chain commands between points and my calibration on the joint lengths and angles isn’t perfect. Also note that the wrist joints are cross-coupled and require proportional adjustments based on the other joints positions, so the code has some fudge factors to try to account for this behaviour. There are also some corner cases to be sorted out when the “best” joint angles switch quadrants, which will swing the tool around in a circle.

The code isn’t super clean and can use some refactoring to move the DH parameters into a config file, but hopefully you’ll enjoy the human readable code compared to the machine generated ikfast output.

Rapid prototyping tools are great for quick hacks, but their real power lies in their ability to allow you to quickly iterate and refine a design. Earlier this week I hacked together a primitive nine-channel punched paper tape reader, but it had a number of limitations: the LEDs that I was using to read the bits were noisy and slow, the materials used didn’t mask the light well enough, the tape wasn’t mechanically aligned well, the electronics were a mess and the entire mechanism was difficult to use. This Friday, I decided to do what my third-grade teacher would tell me to do every time I half-assed something: go back and do it right.

This time I used proper phototransistors and IR LEDs I scrounged up around the space (thanks, Miria and Raphael!). Because they’re 5mm in diameter (and the spacing between channels is only 2.54mm), I had to come up with a new sensor packing. This one reads bits from four separate columns over a space of five columns, requiring an internal buffer of five columns to reconstruct a single column of data. Even so, the spacing was tight, and I had to sand down the flanges of the phototransistors and LEDs to make everything fit. I milled simple PCBs for both sides to keep things nice and neat, and used a small surface-mount potentiometer to limit the current to the LEDs in case the paper wasn’t thick enough to block enough light. The light mask is made of black acetal this time, and the spacers include runners to help keep the tape straight. There’s still no automatic feed mechanism, but we now have a reader that’s fast and reliable enough to read tapes in earnest.

The updated code, mechanical drawings, and PCB designs are all up on Github. There are still a few tweaks we’d want if we were going to scan more tapes, but this version works very well. Now we just have to figure out what to do with all these PDP-8 binaries. Any ideas?

(Note to time-travelling computer conservators: in the past/future, please do not store your paper tapes in damp basements. These programs are stinky. The Fortran compiler, in particular, is exceptionally foul. Yours truly, phooky.)

The rig is composed of a Teensy++ 2.0, eighteen red LEDs, eighteen resistors, and a few bits of laser-cut plastic. LEDs are used to both illuminate the paper and sense the holes. The sensor design is based on the classic Arduino LED sensing code. It’s not very reliable, but it’s a fun afternoon proof-of-concept.

If you’re interested, the code and design files are up on github.

If anyone has been sitting on Cray-1 or Cray X-MP software (or you just have some idea of how to use COS!) for the last 30 or so years, now is the time to come out of the woodwork! Get in touch with me or Andras and we’ll make it happen.

Go, download the simulator and have your own simulated 1980′s data-center! Or just read his incredible write-up on his progress so far!

The code is a straightforward port that reuses almost all of the original logic. The only change is to rearrange the screen slightly from the MonoChron’s 128×64 LCD to the Pebble’s 168×144. This involved translating the glcdClearDot() and glcdSetDot() calls to 2×2 rectangles using the Pebble’s graphics_fill_rect() functions. Unfortunately the e-paper display on the Pebble is designed for mostly static images, and updating it at 10 Hz for the animation draws far more power than a once-per-minute clock face. This means that this watch face consumes lots of power and the Pebble only lasts part of one day instead of an entire week. Perhaps optimizing the redraws instead of redrawing the entire screen would let it last longer.

Want to learn how to write your own watches for the Pebble? Sign up for the May 18 Pebble programming class at NYCR or come to the hackathon after!

If you haven’t heard of it, Pebble was the wildly successfull kickstarter project that pre-sold over 80,000 watches. The watch has a 144×168 transreflective e-paper display, an ARM M3, Bluetooth, an accelerometer and lots of potential. MyPebbleFaces has a few hundred ideas for fun projects and many people have already programmed their dream watch faces.

After the class, we’ll be holding an all-night hackathon to write some new watches. Developers from Team Pebble will be here to hack with us and help answer any deep questions about the API. The hackathon is open to everyone with a Pebble and is a great chance to meet other wearable wrist-watch computing enthusiasts in New York. If you don’t have your Pebble yet or don’t want to risk your prized wristwatch, we’ll have a limited quantity of factory seconds that might not be waterproof, might have glue bubbles, or discoloured bezels or other QC issues available for $75. Tickets for the class and hackable watches are available here!