Restrapped

Recently I’ve been having to don the full anthrolume setup more often, whether to fabricate some part, measure something, or shoot a video. I have noticed that it takes around 25 minutes to put the thing on, especially the 18 straps on the arms and legs. I’ve had a full set of straps for a long time using my original design but it got me thinking about how I could simplify the strap design. What seems most tedious is having to thread the ribbon cable through each strap in sequence. So I came up with a newer design that uses velcro instead of snaps. I built a single prototype and it worked great, so I went ahead and recycled the elastic from the old straps to make a complete new set of 18. The fact that I could do that in a day attests to just how much simpler this new design really is.

Presenting…Anthrolume!

Here it is. Same limited set of animations, but at glorious full-scale. There’s much work still to be done, but I’m pleased with the results so far. (This demonstration is limited to 50% of maximum brightness.)

Cycling animations

I just now got cycling animations working. Here’s a demo running on MiniMe of five simple animations running on the production animation system. That means that now, finally, I can do a video demo with the full-size harness. That’ll be next. (Fade time set to 5, random color per iteration, max brightness set to 50% to avoid overcurrent on USB.)

Animation code working

I keep promising here in my blog to don the full suit, now that it’s fully functional, and post a video demo. While my excitement about having completed 90% of the physical fabrication part of the project is understandable, I was getting a little ahead of myself. The problem is that since the software isn’t done, it’s not easy to get anthrolume to do a lot. Or maybe I should say, it’s not easy to get anthrolume to do more than one thing. You’ve seen posts here with animations and all manner of lights in them. That’s all real code (if a little hacked up). But they’re each separate programs, or programs where to change the animation pattern I have to comment out one block of code and uncomment another. And then I have to upload the program to the Arduino, which means hooking up to USB. So getting a nice variety of material together to show in a video is actually kind of tedious.

So on Friday I started writing parts of the real production software that I will be running when I am strutting around the Playa. The weekend’s progress:

• Invented a compact representation for arrays of LED addresses.
• Figured out how to put the static data for animations into Flash memory.
• Wrote a class to wrap LED addresses (AddressTable).
• Defined the structure for static animation data.
• Wrote a collection class for animation data (Animations).
• Wrote a singleton class to execute animations (Animation).

Listing animations and running one of them

And the cool part is that as of last night, for the first time I could run a real animation using all this software. So I have to port a few arrays of addresses to this new program (that define the frames of animation), and type up some static data, but very soon I should be able to make anthrolume loop through a bunch of animations for a proper demonstration. And then I’ll post the video.

Wired and fired

(Title is a teeny part of a quote from Dr. Timothy Leary – someone I’ve always admired.)

I did the Protoshield rewiring, and the image below shows the spine harness plugged in as it was intended. I also constructed the last harness tonight – the “lower spine” that visually connects the legs with the chest. So the good news is – all the full-scale wiring is done! It’s too late tonight, but tomorrow I’ll put the whole thing on and do a demo for the first time with all 50 lights. It’s been a long voyage, but the hardest part (from my perspective) is more-or-less in the bag. Whew!

Rewired for proper orientation

Being…absolutely sure

I’m largely resigned to rewiring the Protoshield, which means all kinds of desoldering. To test my theoretical understanding of the wiring, I decided to comp up what I’m planning to set up in the rewiring, and make sure that I’ve got action. Looks like I’m good to go.

I am not going to screw up this time

Best laid plans

Despite my careful planning, an error

During the fabrication of the anthrolume harnesses, boards, cables, and other physical constructs, I’ve been careful. Half of that is to avoid wasting materials. The other half is to avoid wasting time. The third half is to avoid frustration.

I built MiniMe to be a dry-run for all the minutiae of the harnesses. How will the ribbon cable origami work? Where’s pin 1? Which way will the LEDs plug into the IDC sockets? Is the “marked” side of the ribbon forward, or towards me? Are we using conductors 1, 3, 5, and 7 or 2, 4, 6, and 8 on this particular harness? You get the idea. And the production harnesses are exactly like the ones on MiniMe, except four times bigger. All this planning has been spectacularly successful at avoiding time-consuming mistakes.

Until tonight.

I just now discovered that my planned orientation of the header connector on the Arduino is upside down. What was supposed to be a straight-through ribbon tap, only works when plugged in like you see here. So now I’m doing some analysis to see what’s the easiest way to mitigate this. An ugly bit of ribbon-cable origami would do the trick, but I don’t like that bit of imperfection in an otherwise orderly harness. Or I could rewire the Protoshield—a definite pain in my ass. Or maybe there’s some simpler solution. It’s only midnight—I’ve got some time to think about it.

An experiment in remote development

When I develop the software for anthrolume, I sorta need the microcontroller and the MiniMe harness with all the LEDs in it to do any kind of testing. But what if I’ve got some cycles to burn at a Pete’s Coffee and I don’t have all the gear? I decided to try an experiment in remote development. I pointed the webcam in my studio at MiniMe, and left the Arduino plugged into USB. Then I remote into my studio computer and do development on the software over the remote connection. I can upload the programs to the Arduino, run them, and see the results in a webcam window. It feels kinda geek-cool.

Here’s me running my AnthrolumeTest program (which is a command-line program for testing the harness), and telling all the LEDs to be blue with the command “ab” for “all-blue”:

Using a webcam to do remote development

I think after anthrolume has had its debut at Burning Man I’ll set up a permanent MiniMe website that lets you send commands to it to run different animations. It’ll be a fun lasting artifact.

Getting started on the software

I’m getting pretty close to done with the fabrication of the final physical harness and mechanisms by which the harness is to be affixed to my body. Now that the hardware’s under control, it’s time to start building the real software. All along I’ve been building little programs to test the rig and to try out different animations, displays, and controllers. But these were little one-off programs. I’ve been designing the internal architecture for the real software in my notes for a month, and I started working on some of it this weekend.

The first library I carved off was a mechanism to do scheduled tasks. There are no threads on the Arduino, so I need to carry out my animations on the one and only loop() thread. The plan is to make that loop as fast as possible, and to have it call a TimedTaskManager “tick” function each time through the loop that will fire off any tasks that are scheduled to happen at the current time. That class, the public interface for which is shown below, is now implemented and tested:

class TimedTaskManager
{
  public:
    // Constants
    static const int kMaxTasks = 32;

    // Constructor/destructor
    TimedTaskManager();
		
    // Task management
    bool addTask(ulong when, TaskProc proc, ulong cookie);
    void removeAllTasks();
		
    // Call this from your loop() function as often as possible
    void tick();
		
    // Debugging
    void dump();
};

All my programs have a “heartbeat” that blinks the on-board LED on the Arduino periodically so I know it’s alive. Using TimedTaskManager, that turns into the following:

const ulong kBlinkMs = 200;
TimedTaskManager gTasks;
byte gBlinkState = LOW;

void _HeartbeatTask(ulong cookie, ulong scheduled, ulong fired)
{
  byte* pBlinkState = (byte*)cookie;
  *pBlinkState = (*pBlinkState == HIGH) ?  LOW : HIGH;
  digitalWrite(13, *pBlinkState);
  gTasks.addTask(fired + kBlinkMs, _HeartbeatTask, cookie);
}

void setup()
{
  pinMode(13, OUTPUT);
  gTasks.addTask(millis() + kBlinkMs, _HeartbeatTask,
    (ulong)&gBlinkState);
}

void loop()
{
  gTasks.tick();

  ...
}

Battery life: I’ve got it

Charging after a hard day's work

I did a test today of the four parallel batteries that power all the LEDs. I turned MiniMe on at full brightness at 8am, and to my amazement, at 4pm it was still going strong. By 6pm when I got home, some of the LEDs were off. That indicates that the voltage had dropped below 3.6V. I measured it, and after 10 hours it was 2.8V, well below the threshold where things go to hell. But frankly 8 hours of life at full brightness is way more than I need. That whole time the Arduino was spinning away, but it wasn’t really a fair test – for one thing I set the LEDs to full brightness and just left them – there was no ongoing computation or I/O that might have used more power. So I don’t really know how long the Arduino will run on its two series batteries yet – but after 10 hours it was still at 7.6V (it started at 8.2V this morning).