Our initial view of the Spy Video TRAKR “App BUILDR” site had us believing this would be an internet-based code editor and compiler, similar to the mbed microcontroller development tools. Delving deeper into the available resources, we’re not entirely sure that’s an accurate assessment — TRAKR may well permit or even require offline development after all. Regardless of the final plan, in the interim we have sniffed out the early documentation, libraries and standalone C compiler and have beaten it into submission for your entertainment, in order to produce our first TRAKR hack!

TRAKR software development at the moment, to phrase it just as politely as we can, has a Wild West flavor to it. The finished tools and reference materials aren’t expected until October. Early documentation is rough — entire sections still missing — so it’s frequently necessary to rummage through their example code to learn how things operate. And the compiler is exceedingly rough right now…it requires a minor patch just to get started, and works only within Cygwin, a UNIX-like command shell for Windows systems. So tonight we’re gonna program like it’s 1999! To continue, we’ll have to assume you’re at least vaguely familiar with command-line development tools, as explaining the entire process from scratch is more than we can fit here.

It probably goes without saying, but for posterity: these are beta tools and the entire process will almost certainly change as the TRAKR HAKR site nears release, rendering these directions obsolete. Until then, for those wanting to get an early start, here’s how we began building our own TRAKR hacks…

Getting the compiler

The C compiler and documentation are presently located on the Apps Help page of the TRAKR web site. Just follow the directions there to download the App Primer (containing the compiler and demo source code), the TRAKR Codebook PDF (an introduction to TRAKR programming), and the Function Reference and code snippets for lighter-weight reference once you’re familiar with the concepts.

The Apps Help page states that the tools work with Linux, but this isn’t entirely true. The App Primer ZIP file contains only the Cygwin (Windows) toolchain, along with the TRAKR libraries and sample code. The C compiler is based on arm-elf-gcc 3.4.6 — Linux users might stand a chance with the pre-built 3.4.3 package from the GNU ARM web site. You’ll still need to download the App Primer for the libraries. With Mac OS X, things get ugly…we’ve yet to locate a viable package for Intel Macs. Building the 3.4.6 toolchain from source (or via MacPorts) has brought only frustration, and the TRAKR makefiles don’t play nice with later (but working) arm-elf-gcc editions. Joy. Eager to move ahead, and not wanting to invest a lot of time on beta tools that are certain to change, some of us are simply using the Windows package in VirtualBox for now.

Getting the compiler to actually work

After unpacking the App Primer ZIP file, copy the TRAKR.1 folder inside to a suitable working location within your Cygwin directory. The _MACOSX folder can be deleted — this is just an artifact of the files having passed through a Mac at one point; there are no OS X build tools here.

Just unpacking the Primer and trying to compile the examples, you’ll encounter a slew of “undefined reference” error messages and a failed build. There’s a problem with the TRAKR library — some test data that’s not properly archived — but it’s a straightforward fix. Go into the Internals directory and edit the Makefile using vi (or another editor of choice if you have one installed). Line 22 looks like this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS)

It should be changed to this:

OBJECTS = $(S_OBJECTS) $(O_OBJECTS) $(O_IMAGES)

Save the changes and exit the editor, then (still in the Internals directory) type:

make trakr.a

Now you can go back to any of the examples and successfully compile by typing “make”. For example:

cd ../EX06_Sound
make

This will create a “.bin” file that can be loaded onto the TRAKR. Attach a USB cable between your computer and the TRAKR vehicle (the power switch can be on or off, it doesn’t matter). In a moment, the TRAKR’s internal storage will show up as a small removable drive. Then just copy the .bin file to the APPs folder on this drive, e.g.:

cp EX\ Sound.bin E:APPs

Disconnect the USB cable, power up the TRAKR and remote, press the remote’s Home button and use either stick to navigate to the “EX Sound” menu item, then press the “Go” button. The app should prompt you to record 10 seconds of audio from the TRAKR’s microphone, then plays this back. Cool stuff!

Writing your own apps

Each TRAKR app is required to have three functions: Start(), Run() and End(). Your Start() function contains one-time initialization code, such as opening the motors to software control; End() is the complimentary function for when your program finishes, restoring control to normal TRAKR operation. Run() contains the meat of your application…this function is expected to return either “true” or “false” to indicate whether it should run again iteratively, or is ready to exit.

The header file svt.h contains constants and prototypes for the functions described in the Codebook and reference documents. This includes high-level functions for producing graphics and sound, turning the infrared LED on or off, reading the controls, driving the motors and accessing the SD card. This is all the Official Documented Stuff thatApp BUILDR will encourage us to use.

But there’s a second header, JAPI.h, revealing much of the underlying functionality on which the TRAKR library is built. And for the time being, this is the only way to access the really interesting stuff like digital I/O, video processing and USB host. This is most definitely not the Official Documented Stuff, and relying on it now means your code will probably require some changes to work with the Official Stuff later.

There’s something conspicuously absent from both libraries: higher-level digital I/O such as serial UART or precise PWM control. We’re not even certain yet whether any the accessible breakout lines correspond to these hardware functions. Maybe it’s something forthcoming, or maybe this will require the chip datasheet, with code talking to the registers directly. Worst case, such I/O will just have to be done with slower bit-banged methods. Which is exactly what we do with…

Our first hack

We really wanted to showcase both the software and hardware hackability of the TRAKR. There isn’t the space for an overly-technical writeup, but neither do we want to send you off with a trivial modification. Hopefully we’ve found a good balance here…mildly esoteric, but most readers with modest prior soldering and programming experience should be able to follow along and create something similar.

Our inspiration came from an earlier Hack a Day article about the txtBomber, a handheld dot-matrix graffiti printer:

The width of the TRAKR is about the same as a sheet of paper. With a row of solenoids and some paint markers, we could make a fantastic mess with this…or even simpler, skip the markers and head to the beach, having the TRAKR “comb” messages in the sand.

Problem is, we didn’t have a stack of solenoids on hand, and we wanted to get right into this rather than wait around for parts to arrive. Rooting among the detritus of our secret underground vault, we found a great substitute from a prior project: a row of 48 addressable LEDs driven by shift registers, the board on which they’re mounted perfectly matching the TRAKR’s 10 inch width! So our aim now was to achieve the same effect in light. The TRAKR moves too slowly for retinal persistence of vision to occur, but we could use long exposure photography to capture the results.

Anyone can buy a TRAKR off the shelf now, but the light bar was something custom-made for a POV project. The good news is that it’s a very common circuit, something we’ve linked to before, and a slightly scaled-back version can be built on a breadboard. Ours has a set of six 75HC595 shift registers with decoupling caps, each driving eight LEDs with associated current-limiting resistors. Very similar to what’s shown in that article, but cascaded out to six chips. You could also do something similar (and way more colorful) using ShiftBrite LEDs.

The LED board is held to the ’bot with masking tape. Spared no expense!

As pointed out in our teardown, the all-important JACK3, containing the GPIO lines, is smack dab in the middle of the TRAKR main board. The unpopulated header USB2, which we’ll use as a power tap, is closer to the outside edge.

In our haste to create a presentable demo, we just soldered wires directly to the TRAKR’s circuit board, but at some point intend to dismantle the thing again and solder on a proper header for inserting wires. For +5VDC and ground, the VDD5V and VGND pads of the idle USB connector are used. The shift registers require three data lines (as we’ll explain in a moment), and we opted to use the first GPIO lines on the board, labeled GPC0, GPC1 and GPC2.

The shift register interface, referred to as a 3-Wire serial connection or sometimes SPI (Serial Peripheral Interconnect), is a synchronous serial interface, meaning that each bit of data is accompanied by the synchronized tick of a clock bit on another line. A third line, called the latch, signals the end of the data transmission — in the case of an 8-bit shift register, this will output on its 8 parallel data lines the last 8 bits that were “clocked in” over the serial connection.

For our light bar hack, we’ll use GPC0 as the clock line, GPC1 as the data line, and GPC2 as the latch. Most microcontrollers feature some kind of native 3-Wire/SPI support, but as mentioned earlier, with the TRAKR library at present we’ll have to trigger all these bits through software control.

Next thing we need is an image to display on the LEDs, one row at a time. Naturally, we’re going to use the Hack a Day logo:

In the source code archive provided later, the image is present as a 1-bit Windows BMP file, simple to work with because the data is uncompressed. The image is turned sideways as it requires less code for the program to decode each horizontal row of the bitmap than it would for processing vertical columns. It’s 48 pixels wide, corresponding to the 48 pixels in the LED bar, and 60 pixels high, including some blank lines at either end so repeated logos don’t run one into the next.

Our example program is hardcoded for this one demo image, which is embedded in the executable. A more sophisticated program might allow the user to load an image from the SD card, and would properly parse the BMP header to query the actual image dimensions. Again, we’re just looking to keep the code simple and not stretching out to hundreds of lines.

// POV demo for Spy Video TRAKR w/shift register LED bar.

#include "svt.h"  // Official API
#include "JAPI.h" // Secret sauce

#define ROWS  60 // Image height in pixels
#define COLS  6  // Image width in bytes (pixels = 8x this)
#define PAD   (3 - ((COLS - 1) & 3))
extern unsigned char _binary_logo_bmp_start[]; // In logo.o

#define CLOCK (1 << 0)  // GPC0
#define DATA  (1 << 1)  // GPC1
#define LATCH (1 << 2)  // GPC2

void Start()
{
  JAPI_SetIoOutputMode(CLOCK | DATA | LATCH);
}

bool Run()
{
  unsigned char *ptr, byte;
  int r, c, b;

  // 62 byte offset to start of image data within BMP:
  // 14 byte BMP header, 40 byte DIB header, 8 byte palette
  ptr = &_binary_logo_bmp_start[62];

  for(r=0; r<ROWS; r++) {     // Each line in image
    for(c=0; c<COLS; c++) {   // Each byte in line
      byte = *ptr++;
      for(b=128; b; b>>=1) {  // Each bit in byte
        if(byte & b) JAPI_SetIoLow(DATA);
        else         JAPI_SetIoHigh(DATA);
        JAPI_SetIoHigh(CLOCK);
        JAPI_SetIoLow(CLOCK);
      }
    }
    JAPI_SetIoHigh(LATCH);
    JAPI_SetIoLow(LATCH);
    Sleep(20);
    ptr += PAD;  // BMP rows start on 4-byte boundary
  }

  return true;
}

void End()
{
}

The graphics-related #defines should be clear by now, we know this program is set up for this one specific image. The CLOCK, DATA and LATCH #defines correspond to the individual bits passed to GPIO-related functions, making subsequent code easier to read.

In the Start() function, the call to JAPI_SetIoOutputMode() initializes all three lines as outputs.

Because of the way the image is formatted, there’s minimal work now to be done in the Run() function. For each horizontal row of the image, six bytes of image data are output one bit at a time, 48 bits total: the DATA line is set either high or low to indicate the corresponding 1-bit pixel value, and then the CLOCK line is quickly toggled high and then low to “clock out” the data bit. At the end of each row, the LATCH line is similarly toggled to tell the shift registers to display the new data. A 20 millisecond delay holds the image for a moment so it’s not all scrunched together, given the TRAKR’s limited speed.

The next line advances the image pointer to the start of the next row, if required. In BMP files, rows are always a multiple of 4 bytes wide. Our bitmap is only 48 pixels (6 bytes) across, so this skips the two extra bytes at the end of each row. The final “return true;” line tells the TRAKR library to repeat our Run() function again indefinitely.

The End() function is empty for this program, but it still needs to be present to keep the linker happy.

A ZIP file containing the above source code, bitmap image and makefile can be downloaded here. Extract this archive within the Trakr.1 folder, alongside (not within) the Internals directory. “cd” to this directory and type “make”. If all goes as planned, this should produce the file POV.bin, which can be loaded on the TRAKR as described earlier.

Even in this early stage, warts and all, we’re quite excited by the prospects for this toy’s hackability. Wild Planet is to be applauded for their open-minded approach in encouraging software and hardware modifications. A lot of comparisons are already being made to the Roomba and Rovio, both of which have spawned enthusiast sites and even books. Time will tell if the Spy Video TRAKR catches on the same way.

So that’s our TRAKR hack…now let’s see yours! When you’ve got something cool to showcase, don’t forget to tip us off!

When the tipline popped up with this LED suit, part two, by [Marc DeVidts] we were expecing a simple led version of the previously known EL coat.

Well we were right and wrong in the same instance. Correct in that like predictions, the outcome is stonking great. Wrong in that this suit far outpaces EL in abilities we weren’t expecting. Namely to start off, an iPhone app over WiFi dictates to some 200 Arduino multiplexed RGB LED modules to dance randomly or follow patterns; an accelerometer and microphone are also implanted to further some effects. And finally if the suit isn’t enough to make you giddy, his PCB and enclosure milling surely will. Catch a video of the entire setup after the break.

Waking up at 5:30 in the morning. [Mark Stead] didn’t like the idea either when his chickens started crying to be let out. One simple solution obviously is to eat the chickens build an automatic door opener. The mechanism starts out with an old style mechanical alarm clock, add a geared motor with some creative switch work to pull open the door, weather proof the entire thing, and done. [Mark] even modified the setup later to work with vertical doors. No MCU required for either.

Pair this with an automated feeder system, egg gathering and cooking setup, and you’re half way to having your breakfast ready for you when you wake up in the morning – around noon like the rest of us.

[Thanks MS3FGX]

The program avr-size is part of the AVR-GCC toolchain used to develop programs for that line of microprocessors. The program tells you how much space the code will take up on the chip, important information if you’re trying to cram a program into a small program memory. Perhaps more importantly, it shows you how much ram is being used. This is the “Data:” portion of the image above and if you overflow the memory this will be the only thing that lets you know that has happened (except for unstable behavior once the program is running).

For quite some time the avr-size package in Ubuntu has been missing a key feature that makes the information more human readable. [Jeff] over at mightyohm tracked down the solution to the problem on the bug tracker and posted the directions on how to bring your copy up to date. Basically, download the package from Debian (an upstream copy that has already been patched) and install it. [Jeff's] guide is based on the AMD64 version so we’ve copied his procedure in a more generalized fashion after the break.

1. First, go here and download the appropriate package for your architecture. The most common is i386 and you should download the most recent revision number (2.20.1-1 at time of writing).

2. Use the Debian package management system to install the package you just downloaded (you will need to change the package name if you didn’t download the i386 version):

sudo dpkg -i binutils-avr_2.20.1-1_i386.deb

3. Place the package on hold to prevent automatic updates that actually downgrade back to the broken version:

echo "binutils-avr hold" | sudo dpkg --set-selections

That’s all there is to it. We like to use a makefile written as a WINAVR example to compile and upload our AVR code. We’ve made the changes necessary to use the fixed avr-size program. Download the makefile here.

[Devon Croy] built a case to join a webcam sensor with a camera lens. The box is a PVC conduit box you’d find at a home center. He used JB Weld to attach four bolts to the back of the box. These are used to fine-tune the mounting plate for the webcam sensor to ensure it’s at the focal point of the lens. The lens connects through a couple of extension tubes to an adapter mounted in the center of the box’s cover plate. The setup above shows a macro lens that takes pretty good pictures.

If you need images of really tiny things you should look into a microscope adapter for your camera.

Don’t steal. It’s a lesson that children are taught from the youngest age and a core principle in every society. The PSGroove sets out to follow this mantra in several ways. It is an open source implementation of the PSJailbreak hardware we covered a couple of weeks back. It’s difficult to find a definitive source of information on that hardware but many have speculated that the original device contains stolen code. Whether that’s true or not is moot as the PSGroove doesn’t include the backup manager program alleged to violate copyright.

The device is also aimed at running homebrew, and doesn’t natively allow one to play backups. It runs on a variety of AVR hardware, including the Teensy boards. If you have one of them, it’s just a matter of compiling the code and unlocking the potential of your PlayStation 3.

[Thanks Mark via PS3news]

[Dan Kouba's] parents replaced their doorbell button with one that lights up and found that the chime wouldn’t stop sounding after the button was pushed. These lighted buttons use an incandescent bulb in parallel with the button (a piece of hardware we’ve hacked in the past). It draws a small amount of current which isn’t enough to trigger the chime, but it is just enough that the chime unit reacts as if the button press never stopped. His parents asked what he could do about this and after some investigation he build a replacement board for the chime unit based around an ATtiny26L. The board monitors the voltage drop across a resistor in the doorbell circuit. When the comparator on the AVR detects a rise in the voltage drop across the resistor it rings the chimes, actuating the solenoids with a set of PNP transistors. [Dan] sent us all of the details which you can check out after the break.

Dan writes:

My parents have this really old door mechanical chime that they got as a housewarming gift 25 years ago, and recently when they replaced the doorbell button with a newer lighted one, the bell wouldn’t stop chiming.  Apparently the light in the button passes enough current through it while its on (and the button is unpressed) that it triggers the bell over and over again.  They didn’t want to get rid of the doorbell, as the newer electronic ones just aren’t the same, so I was asked to see what I could do about it.  My solution was this project.

The old chime system consisted of a motor, which would be set into motion by pressing the button, and a set of contacts which the motor would revolve around and trigger the four solenoids that ring the chimes.  Once I disassembled it, the cause of the infinite cycle was obvious.  The motor’s start current was higher than the light in the bell would permit, but once it was triggered once by pressing the button, the bulb current was enough for it to remain in motion.  There wasn’t a whole lot I could do to fix the old system, so I designed a microcontroller based replacement.

I used an Attiny26L (admittedly overkill, but it was all I had on hand) for the brains of the operation, a button press detector made out of a comparator and a resistor (more about that in a second), and four transistors for triggering the solenoids.  Those parts along with the power supply (there was 20VAC available at the wall) fit onto a radioshack PCB which happened to fit perfectly where the old system had sat.  The old system had the option to either chime a sequence or only a single chime when the button was pressed, and I replicated this feature in software using the large blue DIP switch shown in the pictures.

My detector circuit is simply an 82 ohm 5W resistor inline with the button/light combo.  The button and the light are in parallel, so there is always some current passing through the line, causing a small voltage drop across the resistor.  When the button is pressed, the light is shorted out and the current becomes much higher, thus causing a higher voltage drop across the resistor.  I used a comparator attached to a voltage divider reference (half the supply) and to the resistor.  That in turn is connected to the AVR which monitors for the button press and triggers the chime accordingly.

One of the problems I ran into was that the solenoids are high side switched.  One lead of each solenoid is attached to the case, so unless I wanted to run 4 more wires, I had to use PNP transistors to switch them (I would have used MOSFETs, but I had the transistors in my parts box).  I used an NPN transistor to pull their bases low so switching from my 5V AVR was easier.

The code is really simple; it’s just an infinite loop watching the comparator output for a trigger, and after that it triggers either the chime sequence or the single chime based on the switch input.  I was originally going to use interrupts, but I had issued with multiple triggers.  The interrupt flag was cleared as soon as the ISR was being processed, so if the bell was pressed twice before the chime sequence was finished, the interrupt would trigger a second time once the ISR finished its first run.  A simple if…then statement fixed the problem.

Download [Dan's] code and schematic package.

The keyboard on [Marek's] laptop stopped working. He didn’t want to buy a replacement so he decided to start using an external keyboard. But hauling around a full 104-key model is a bit of a pain so he decided to make himself a shorter keyboard. He basically chopped off the 10-key pad on the right side of the board. This had the unexpected consequence of removing the screws that hold the top and bottom of the case together so he ended up adding a few extra screws to shore it up. You may be wondering how the key matrix still works if a portion of it has been cut off. [Marek] used the simple trick of folding the extra part of the membrane over and covering the unused contacts with some tape.

If you try this you should consider getting rid of the directional arrows and editing keys as well. There must be a way to map those keys elsewhere. Perhaps the half-qwerty keyboard hack will give you some inspiration for that.

If you’re too frail to take the full impact of a paintball round let this tank serve as your surrogate. The camera perched on top of the platform feeds video back to the operator’s head-mounted display. Instead of using a joystick or other traditional controller, the user aims by looking around, with his or her head movements mimicked by the camera and barrel of the tank. It looks cooler than it sounds so jump with us after the break to see for yourself. If you’re playing against this thing, we’d recommend aiming for the camera lens.

Here’s a great magnetic levitator build. [Scott Harden] dug up the link after seeing that awesome rotating globe this morning. This version hangs objects below an electromagnet but it has a sensor system to provide a constant distance between magnet and object even if the payloads are a different weight. This is done with a couple of infrared sensors. One acts as a reference detector, always viewing an IR LED in order to get a baseline measurement. That measurement is compared to a second detector mounted slightly lower. The circuit adjusts the electromagnetic field, making sure the object is always breaking the lower beam but never interrupting the reference beam. No microcontroller needed, this is handled with a couple of OpAmps. See it in action after the break.

[Alexy Sha] has done this fantastic hack, where he modified a magnetic floating globe to be motorized and spin on a tilted axis. The original globe was simply levitating via a magnet mounted inside. Though you could spin it by hand, it wasn’t motorized, and actually floated completely vertically instead of being tilted.

[Alexy] wanted to take this idea further and make it automatically spin on a rotated axes. He built a rotation assembly that was basically a motor, hung off-center, attached at the center of the globe. He had to power it via a coil hidden in the base unit, so that it could remain light enough to float. He did a fantastic job and the final product seems like it is the true way it should have been sold.

Check out a video of it in action after the break. We actually like the spinning ring, when he’s testing it, just as much as the final spinning globe.

This peculiar setup allows [Ben Krasnow] to control an alternating current device using one pin on a microcontroller. He’s experimenting with a power drill and has relocated the trigger circuitry that makes it spin. On that board he found a variable resistor combined with a capacitor which control a triac, actuating the speed of a drill. [Ben's] solution works great and isolates the drill from the control circuitry. He replace the variable resistor with a cadmium sulfide photoresistor (basically a variable resistor whose resistance depends on the intensity of light). Pulse-width modulation is used to adjust the brightness of an LED shining on that photoresistor and thereby affect the speed of the drill. This is such as simple alteration to the drill we’d call it MacGyver-esque.

See a demonstration after the break.

Last Friday we looked at Wild Planet’s Spy Video TRAKR programmable RC vehicle mostly from an end user perspective. Much of our weekend was spent dismantling and photographing the device’s internal works, and poring over code and documentation, in order to better gauge the TRAKR’s true hackability. Our prior review included some erroneous speculation…we can clarify a number of details now, and forge ahead with entirely new erroneous speculation!

Our plan with this teardown is to establish more concrete details of what’s hackable inside the device, what’s not, and to help nail down some of the unstated hardware specifications.

We incorrectly reported that no programming documentation or compiler is yet available. Turns out all this information was simply tucked away in a help section of the TRAKR web site, not on the “App BUILDR” page where we expected it. Derp! These resources are still in a rough state, yet proved to be a far more valuable source of information than the physical teardown. C code and PDFs aren’t very photogenic though, so we’ve got plenty of circuit board pr0n to start with!

Inside the Remote

The concealed rear USB port was mentioned last time, which we’ve been informed is to allow for field-upgradeable firmware. If you don’t mind being tethered to one spot, we discovered the remote can also be powered from a USB hub, or even from the TRAKR’s own USB host port.

In another nod to tinkerer-friendly design, both the remote and the TRAKR are held together with identical Phillips screws throughout, recessed but not hidden under stickers or rubber pads.

The LCD screen is one typically seen in cell phones, 15-bit color at 160×120 pixels.

The remote and TRAKR have outwardly-identical radio transceivers. They’re rather well-sealed and we’ve not dismantled them further yet, but recall hearing they’re based on a Nordic 2.4 GHz part. Wild Planet claims that with a forthcoming firmware change, they’ll be WiFi-capable. We remain hopeful but skeptical — it seems far more likely that the remote’s rear USB port will come into play, or in the interim perhaps one of the SparkFun Nordic options will prove a viable choice for PC control.

Inside the TRAKR

Removing the screws is straightforward, but fully removing the lid from the TRAKR requires several cables be detached first — and they’ve all been glued in place for reliability. We just cut through the glue with an X-acto knife and pried a bit, but maybe it can be more delicately dissolved or melted.

The right side of the main board (turned sideways here) focuses on connectivity and the CPU. The ribbon cable at left leads to the camera. The pair of two-pin headers lead to the microphone and front accessory bump switch. The purpose of the unpopulated SW1 isn’t known — it might be that early designs featured an additional rear or top switch, now vestigial. The larger headers lead to the radio module and the trim pots and recessed reset/debug switches on the bot’s undercarriage.

No need to get through that epoxy blob. Digging through configuration files for the compiler, the chip appears to be a Nuvoton W55VA91, featuring an ARM926EJ core running at 192 MHz, and hardware-assisted JPEG codec.

Little to see on the underside. Another inactive V0_TVOUT pad taunts us! This side is dominated mostly by the SD card socket, and…

The USB host port is on a small daughter board, and each of the motors has some local driver circuitry as well.

Each motor is driven through a reduction gearbox. They operate quietly with only a slight amount of slop. As with the radio, we’ve not further dismantled these yet.

Though not powered, the front wheels aren’t as boring as we first thought. This rack and spring mechanism keeps a constant tension on the rubber tread belts, allowing them to flex and maintain traction as the TRAKR drives over various terrain.

The partly-disassembled camera pivot mechanism. Two small rubber pads provide just enough friction to hold the camera in its set position, yet still allow it to pivot easily. If attempting to add servo control to the camera, removing those pads will likely help.

Extracting the camera PCB from its housing, we were greeted with a low-hanging hack opportunity: the board was designed to accommodate multiple LEDs, but in practice shipped with just one large one in place. Boosting the light output should be a very simple matter of adding the missing resistors and LEDs, though you’ll need to drill holes through the case or run wires to mount the LEDs externally.

We’re not 100% certain of the camera sensor yet. From PR materials at Maker Faire, we know it’s from OmniVision, but don’t know the exact model. Based on size and specifications, the OV7670 looks like a possibility, in which case it should be capable of full VGA resolution, not just the QVGA output we’ve seen.

The “accessory port” is just a passive attachment point to clip things on; it resembles a headphone jack, but isn’t. There is a pushbutton switch behind it, maybe an interactive cat-poking stick is planned.

The artist’s signature.

Reassembly was straightforward. Cable connectors are keyed for orientation, and for those that aren’t a unique size, the correct positions can be inferred from cable length. And there was no mysterious “extra screw” at the end — everything went together easily and worked on the first try.

Passengers

Arduino, natch. Small devices like this can be powered from the TRAKR’s USB host port, but without an FTDI driver on the host side this connection can’t be used for serial communication.

Half-size and quarter-size breadboards fit exceedingly well, almost snapping into place. But anything placed back here though is going to block access to the SD and USB ports.

More Hack Ideas

Having explored the hardware inside and out, we’re already ruminating on the possibilities…

The TRAKR has a big infrared LED on the front (with two more easily added). The firmware for TV-B-Gone is open source. Enough said.

With the transport deck removed, the rear wheels of the TRAKR protrude slightly behind the body. With the addition of a gyro sensor, will it be possible to get the TRAKR to stand upright and scoot around Segway-style? The remote’s joysticks are non-proportional, but software control of the motors allows for very fine speed adjustment. It’s been done with LEGO NXT, so we think the practicality of this idea will come down to the responsiveness of the TRAKR’s motors. (Yes, we know it’s just propped up against the back wall there. Shhh!)

This bulky package is a Nixie tube wristwatch. We still like [Woz's] watch better but this one has a few nice tricks of its own. Notably, there aren’t any buttons to set the time. Instead, a large magnet is used to actuate a magnetic switch inside the body. Speaking of enclosures, the case is aluminum and the face plate is polycarbonate but looks like it’s been vacuum formed. Check out the clip after the break.