Here’s a simple demonstration of my working tap tempo system and animation time-scaling. I’ve deliberately used a trivial animation for this demonstration, but the mechanism works for all my animations.
Note: The recent dearth of posts has been a result of a little vacation to Florida. I’m back, and working away.
I must have this project “done” by August 18, 2011. So that means I’ve got about five weeks to go. As a result, I’ve decided to scale back on a few of my plans. I designed a pretty good user interface for this project with a 20×4 LCD, bend and analog joystick inputs, finger buttons, and an encoder wheel. Sadly I have to shelve some of those plans for now, along with some of the more ambitious control mechanisms. I’m going to use something much more straightforward, but still ultimately satisfying.
For display, I’m going to revert to colored “mode” LEDs mounted in or on the computer enclosure. It will be enough for me to tell what the thing is doing. I expect three modes:
- Automatic which just plays animations continuously
- Communication which plays one of a small number of special animations that have some semantic meaning
- Utility which has some diagnostics that I can use to check the functioning of the suit, such as turning on all the LEDs to make sure they’re plugged in correctly. I will also have extended diagnostics available when the suit is connected to a computer via USB.
I also modified the protoshield to accept the new connection to this device. It will run under the right arm straps to my hand. It’s kind of rubbery and has a nice feel to it.
Another big piece of work over the weekend was the creation of a Beats class that implements a flywheeling tap-tempo system. I can tap the middle button of the controller in rhythm and my Beats class averages the taps to determine a tempo, then flywheels at that tempo. Since I have computer control over the backlight on the controller keypad, I set up a task to flash the red lights on the keypad in time with the beat.
Now what I’m working on is making the animations time-scale to the current tempo. This is surprisingly easy, and it’s already partially implemented. I will probably be able to post a demo video of tap-tempo-synchronized animations Thursday night.
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.
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.)
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.)
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).
(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!
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 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.
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.