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.
Monthly Archives: June 2011
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).
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!
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.
Best laid plans
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”:
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(); ... }