Flavonoid Archives - Near Future Laboratory

Companion Species Training Game

The new-to-me Nintendo DS “Personal Trainer Walking” (heck of a name..) alongside of the Japanese language game whose name I forget and cannot read.

I found out about this Nintendo DS game from Kevin who found out about it from Russell. I literally just got it yesterday, but it’s pretty exciting to see. I can only imagine in my head out the play dynamics unfold, but I’ll be playing with it and have some more thoughts before long.

So far I enjoy the “blind” design of the pedometer part of the concept — not too much display other than this blinking light which changes color when you’ve reached your goal. Simple, direct and not a nagging taunt from a fancy LCD that shows more than you need. You focus on your activities or just being a normal human being without poking and prodding at the device all the time, checking your status in detail, etc. When you’re in the world, be in the world, I say.

This one aspect of the design is quite curious — there is an extra pedometer device for your dog! I mean, I get the idea — people walk their dogs and so this is perfect for you and your dog to get some training together. The language in the users manual / guidebook is very funny, and I’m not sure if this is deliberate or perhaps the sensibilities of a Japanese game design company? I know none of the facts and that does not matter so much to me, but maybe it’s my sensitivities to things that fold together different species into what my advisor calls “transpecies” or “companion species” — species that need each other, or play and interact together in curious ways. (cf The Companion Species Manifesto) Thus, I cracked up when I read these items in the guide:

The meter should only be used by a person or dog. It will not work properly with any other type of animal.

The meter should only be used on a dog when supervised by a person. It should be attached in a location where it is not at risk of being chewed or swallowed.

Great stuff. I’m looking forward to seeing how the DS experience works.

Downside: I’m pre-disappointed that walking is the only physical activity it seems to work with. I ride a bike and want this to count. And there are so many other sorts of physical things that won’t count, I assume.

*shrug*

Russell points out the simplicity of the synchronization ritual, which is fantastic. Point. Press. Watch your pedometer pebble appear from a pipe on the screen and become “alive” on your screen. If you’ve ever tried to synchronize ANYTHING you’ll laugh out loud, as I did. If you’ve ever designed ANYTHING that requires synchronization, take close note of the interaction ritual here. It’s fantastically playful and simple and sensical.

Some related topics: this perpetual Laboratory project, Flavonoid.

The Face of the Faceless User Interface

Ironically, a typing command user interface to do set-up stuff and manage the Flavonoid device itself. There were enough unknown variables in the design of the device and enough of my own obsession with preferences and configurations and such all, that I spent some time creating a configurable device.

Here at the Near Future Laboratory, Nicolas and I are interested in digital devices that are essentially faceless. Just blank, “blind” devices, like Sascha’s awesome “Blind Camera” project. They are intriguing because of the way they run counter to intuition and thereby raise questions and immediately make their expression curious and unknown, hopefully opening the possibility for accepting new kinds of interaction rituals besides just pressing little plastic squares and such sorts of interactions that we’ve come to expect.

The irony is that there are enough variables for parameterizing the device’s functionality that I needed some way to manipulate them, at least at the start. So, I created this behind-the-scenes interface for adjusting the properties and behaviors of the object. Most of the time you would not access this at all, certainly not while carrying the Flavonoid device with you.

The Benefits Of Zealous Design

I could say over design, but zealous sounds more purposeful.

So, zealously over designed peculiar digital life-game controller here. Added a coin cell holder for a 3v coin cell (12mm) to keep the RTC clock going if power drops or is removed. Added an on-off switch(!) Added two extra components to the power management circuit — a MAX4651 for the really off situation in which I use a removable battery and insert the battery backwards, and a MAX6439 battery watcher deal that’ll signal the MCU if the battery goes below a specified (factory trimmed) voltage, pull down reset if it goes super low, and signal if it rises back above a threshold, with a bit of hysterisis. Problem was that the thing could drain the battery into oblivion which made recharge long and tricky. But, frankly — now with the on/off switch and battery back-up for the RTC, it’ll be much easier to charge over USB. I hope. Found some small LiPo batteries from an iPod Shuffle battery replacement kits, of all things. One is 230mAh, the other one says it’s 400mAh but it’s marked 330mAh. Close enough for Jazz. It’s about 37mmx22mm.

Also I found this operation:

www.synst.com.tw/english/prdlist.aspx

They sell small, flat, light LiPos with decent capacity (160mAh+/-), but much more expensive and harder to get.

Curious about what’s what? The Flickr page has “notes”.

Update. The iPod replacement batteries work great so far.

Gestures and Interface: Things To Do With Your Finger

What are the boundaries of interfaces for our digital lives? Our fingers? How can the gestures we use to interact with our devices extend to create new sorts of interaction rituals and interactive experiences that go beyond the digit interface? From simple switches found in old trucks, to the 19 tactile buttons on the guidance computer that took a few men from the earth to the moon, to the current fascination with a different form of tactile “touch” interface, to finger gestures for sign-language interactions to the early experiments with pre-Wii gesture interface — how we interact is all caught up in the interface between intent and action that is very much wound up in the same desire for connection as Michelangelo’s imagination rendered on the ceiling of the Sistine Chapel.

I’m interested in how this interface can be changed to create a new idiom for connected digital lives that are more playful and less burdensome. How can the core elements of the interface syntax be stretched and reformed into a new style and meaning for computation that reflects upon the fact that were beings who live in space and time and sometimes enjoy the friction of social engagement? Can there be a kind of interaction where time actually counts? Where it is not instantaneous email download style time? What happens when the gesture is consumed by time — so that one gesture “unit” extends over an period of several minutes or even hours? What about space? Can there be a way that digital experiences are not about conquering space and diminishing it to a blink of packet switched gigabyte optical fiber speeds? Sometimes covering ground is a good thing, and doing so at a human pace can be a welcome reminder of our physical selves. Suppose that hike counted for something in a different model of computing? Or passing by a familiar landmark — a street corner or pedestrian overpass — is like the gesture of moving a game piece in a video game?

Version Version Version Version Version Version Version

I’m in a fit of over-design. Here I am on the sixth edition of Flavonoid, which is going rather well. It does pretty much everything I would like it to do, save a proper rest mode, some little bit of recoding to make it more fuel efficient, a pedometer (step-counting) mode per Dennis’ request and, well — mostly commissioning a proper enclosure of some sort for it.

And then I had a number of things that sort of bugged me. One was the relatively low level of oomph with which the device could charge over USB. So, I started thinking about a number of power-related things. One idea (that the seventh edition will have) is a low-battery circuit that’ll allow the device to go to sleep when the battery is so low that it should be charged. For that I’m trying out the MAX6439 to raise a flag when the battery starts to bottom-out. Then I started thinking about a non-fixed battery — one that could be replaced and recharged in a normal recharger. So, I added that. Then I started thinking about a non-fixed battery being put in wrong way ’round which would definitely blow out the LDO regulator I’m using which isn’t, like..so great — so I added a little circuit using the MAX4636 CMOS switch to quickly fix that situation. Then there was the kind of annoyance of the real-time clock loosing track of time when power is removed — so I added a coin cell to keep the real-time clock juiced even when the proper battery has gone flat. And I knuckled into my own weird design fetish about things that don’t turn off and added a switch..so Flavonoid can be turned off..but it’s a very very small switch so maybe I won’t turn it off except in weird situations, like getting on an airplane or whatever.

I took off the reset pushbutton because I realized I was never hitting reset, pretty much. I left two plated holes so I could put a little reset jig together if I needed to, which I won’t, cause I can now turn the thing off and then on, or reset it any number of other ways. Here is the layout for version 7, now somewhere in China coming to be.

Lately I’ve been walking around with one on my hip and one in my pocket to capture some data. I wrote a little Python script that connects to the Flavonoid over USB, grabs the data and then tosses it up to the Flavonoid mothership database. I’ve also started jotting down how many steps the pedometer says for the day. I’m comparing pedometer steps to Flavonoid “data points” just for grins and to check for any correlation or consistency. These days, I’m not particularly physically active — I move back and forth between the bench and the desk, spend a few days a week doing more or less the same at Nokia — and that’s pretty much it. But, hopefully when others get theirs or if I try and do anything other than “test” myself, some insights will develop.

I’d actually be more interested in seeing some cool offline gaming style games develop..

In The Midst Of Design-Technology

In the midst of trying to finish this first run of Flavonoid boards — getting the firmware right, finding little gotchas in the design, little mistakes in the assembly process — I keep flipping back and forth between thinking about the minutiae of assembly and the craft work, and the 6-mile-up design theme. The minutiae is obsessive and completely tunes your head for basically just sitting in front of the tube (writing code, debugging code you’ve written, finding work-arounds, banging my head, asking Todbot for help with this and that.) Sometimes I almost forget why I’m making this thing.

So, for my own sanity. The Near Future Laboratory — Nicolas and I — are interested in experimenting with “offline gaming” — ways of interacting, particularly in mobile and pervasive contexts, that were digital and required some kind of engagement with physical aspects of the world. It was a way to begin investigating hybrid interaction rituals. Hybrid interaction rituals being those that coupled some action and activity related to the physical world, with digital practices.

One way we’ve been investigating this theme of offline gaming has been to speculate on simple kinds of game scenarios. One we are particularly keen on would work in the fashion of “accumulating” kinetic energy points by doing actual, physical activities. These kinetic nature of these activities — running, skipping, surfing, snowboarding, gardening — would accumulate these energy points which could be linked to power-ups of some sort within the digital game. So, physical activity in the normal, human physical world generates the potential for action in the digital game world, probably in an online environment. So, for example, your character in, say, WoW gets a — whatever — Rock of the Condor Sword because you’ve done a solid weekend of hiking and kyaking or something.

So, conceptually, there’s this mechanical linkage. You do something offline and see some representation of that offline activity, online, later.

Problem was — I really wanted to construct the device that would make that mechanical linkage. I played around with a few commercial pedometers, and thought about GPS, etc. I wanted the translation to be as seamless as possible. Dennis had experimented with using off-the-shelf pedometers translating the step numbers into a game grid. That’s the brilliant way about working on the problem. I personally found the pedometer a bit too instrumented. It wasn’t foot-falls I wanted to link to the digital representation of your physical activities — it was physical activity generally. So, more than just running or walking. But, suppose you garden? There’s not tons of walking to represent the activity. Or suppose you were a skateboarder or surfer? Pedometers aren’t particularly good for measuring that stuff.

I decided that I needed a more ambient accumulator of kinetic activity. A momentum-ometer. Or something.

At the most basic level, that’s what Flavonoid is — it measures changes in momentum across all real-world axes. What that means more simply is that it just records physical motion in every direction. It records this at time-based intervals that are configurable, and with a thresholding feature that allows you to ignore any motion below a particular threshold. Each data set records the accumulated changes in acceleration and the maximum change in acceleration for that period.

Two acceleration readings are taken at a time, with 100ms interval. The difference (change) in acceleration is what I record. Why change in acceleration? Because, by my estimation, that’s an indication of change in momentum, which is closer to work-done. I could be wrong — but its a convenient enough place to start. The main point is that I’m less particularly concerned with what the numbers mean specifically and more that they’re directly related to physical activity. No one would “count” accumulated changes in acceleration as they would accumulated number of foot-falls. But, these numbers can serve as a suitable input to the offline game experience just fine.

I also made this as a basis for a number of other projects within this general theme of creating hybrid interaction rituals. We needed some sort of device that could correlate physical activity and put it in a digital form that was amenable to a variety of different expressions. I had first hoped that a “connected” pedometer would work, generally — but many of these are closed systems, using proprietary interfaces. So, even if the pedometer did measure what I wanted it to measure (ambient activity rather than foot-falls), I couldn’t easily extract the data. That’d only work by hand, which wasn’t ideal.

Command Line

Here’s a revamped Flavonoid configuration console. This allows easy configuration over USB. There’ll be a few more commands in here for other features and crap, especially extracting the recorded data. This harkens back to the old school VT100 style terminal controls. There’s no drag-and-drop here, just words and commands. (Evocative of Don Norman’s bit on what he sees as a revival of the command line user interface. I wouldn’t say that this here in particular is a breakthrough, except in being retro.)

I like this mode of interaction. There are commands with parameters and that’s basically that. And output in a bottom area “annunciator” area. It makes the Flavonoid pretty much platform agnostic — anything that has a USB “COM port” and can obey VT100 terminal commands can interact here. And a keyboard.

This uses Pascal Stang’s cmdline library from his great avrlib for Atmel 8-bit MCUs.

Power Craft

Power. Faced with the design challenges of keeping things that don’t sleep awake as long as possible. One of the more intriguing aspects of the Flavonoid project has been to find ways that it can stay active and recording without it requiring a large, heavy battery. This battery here — the “Powerizer” — is about as big as I want to get. I also have some “flat-pack” style LiPo cells that might work well. The Powerizer is an industrial 3.6v 650mAh cell. Here Flavonoid is drawing about 18mA while recording data — the A2D converter is on and pretty actively sampling, the I2C/TWI bus is running frequently reading the time from the real-time clock. And every 15 seconds the LED blinks for a moment just so I know its alive. It’s also running a command line console interface over USB, so the FT232RL RS-232<->USB chip is spun up.

One problem I faced — still facing — is how to recharge the battery, which is basically “fixed” (non-removable, or only removable by removing soldered connections.) The design presently uses the Maxim MAX1555, which a chip that will charge a single LiPo cell over USB or from a +5 volt, higher current source, about 200mA, whereas USB will max out at 100mA. My laptop’s USB port won’t charge at more than 80mA at best. The idea here is that USB charging would be more convenient than having another wall plug and wire running around. Since the Flavonoid uses USB for configuration and downloading data, you’d have it hooked up over USB anyway. I assumed USB would be fine, and generally it is. But the times that I’ve tested the Flavonoid’s ability to run for a couple days, the battery went way low — 1.8v — and I had to recharge it from the higher current +5v source. Getting the Flavonoid to charge in the flat-battery circumstance is tricky. Presumably, since there’s no on-off switch, the Flavonoid is trying to start up, which draws a modicum of power, making it more difficult for the battery to just chill and charge.

What’s the alternative? Well, the immediate fix is to keep the Flavonoid plugged in at night so it maintains its charge. And I’m looking at adding a battery monitor (Maxim MAX6439) that will be able to let the Flavonoid microcontroller know when the battery voltage drops to a certain level. There’s built-in hysterisis so the battery needs to go above a specified voltage before the MAX6439 will let it know that its back in some kind of nominally revived state. The thinking here is that the battery monitor could trigger a pin-change interrupt that would put the Flavonoid to sleep so it draws barely any power at all. When the battery is back to normal, it’ll come back to and carry on as usual.

Techne

From a distance, the craftwork of prototyping speculative devices is really, really exciting to me. Thinking about design, electronics, construction, developing activated objects that actually work? That’s great.

From 10 millimeters, under a jeweler’s headset with tiny, tiny 30 gauge wires popping off .005 inch integrated circuit pins? I feel like a misunderstood King Kong or something.

I wanted to learn more about debugging at the microscopic scale with hardware, and this seemed as good a time as any. The debugging process essentially takes over the microcontroller, exposing all the little inner secrets — registers, program counters, memory, etc — and lets you step through your code line-by-line. The alternative is either to blink LEDs (if any are attached) and try to assume what might be going on based on that, or the old standard print to output, which means you have to roll a few libraries to actually do that, and have some sort of way of getting the microcontroller’s UART to talk to your computer. (Many of the projects I do have that feature as part of the design, but generally that isn’t always available.)

This has been working “okay” for Flavonoid, mostly because I rigged an interface for JTAG boundary scan debugging as an afterthought for this particular spin of the Flavonoid board. You can see it hasn’t gone super great — one of the little 30 gauge white wires there — the one sitting by itself on the right — keeps popping off the MCU, and I’m getting increasingly reluctant to hand solder it back to its pin again. It’s supposed to be attached to one of the multifunction pins on the Atmega324p that’s used for the boundary scan protocol. The heat and possibility of shorts makes me nervous. All the board soldering things on and off causes incremental problems — like the short to ground between a via and the spot on the board where the battery ground attaches just cause a little solder joined them. And the via was to the UART transmit so communication was only one way from the computer to the board, which was perplexing after everything worked. And perplexing for a couple of hours. Hours.

There are craft lessons learned here. Don’t put susceptible vias too close to other things where solder might cause a short, which means more closely inspecting board layout for such things, and creating special rules. Most vias won’t be near something of this sort, but occasionally they will. (Such was the problem with the first run of MobZombies boards where a via was placed way too close to a large ground pad that lived underneath a $35 tiny, leadless gyro.) A book of design rules-of-thumb would be useful to create.

Same with rules about creating accessible debugging test points. I had been conscious of this, but not for the ultra-useful boundary scan debugging. Part of what makes it useful — maybe one of the biggest reasons — is that it exposes all of the registers so you know right away whether you called something by the wrong name by mistake — a common problem when registers are named very similar things and bleary, late-night eyeballs are not as attentive. PORTA PINCA start to look the same after awhile.

There’s also this peculiar boundary scan process that I remember hearing about back in the day what when I was helping design relatively gargantuan integrated circuits. There was this test procedure where you could shift in and out data to individual parts of the device and figure out what was going on inside without having to actually connect directly to the chip. You could essentially send in a message that would set the state of various parts of the chip and retrieve state. There are these bits of logic that essentially sat in between pins and other logic that can either get or set the state of the innards when its in test mode. When your chip isn’t in test mode, the boundary scan cells that sit in there between the pins and logic are made invisible so they don’t effect the operation of the thing. The JTAG part stands for Joint Test Action Group — pretty vague — that was summoned into existence to figure out a standard way for testing digital electronics.

So, well — I think there’s something to be learned here that is not just about the minutiae of electronics and microcontroller debugging. There’s a character of design here that I’m enjoying and that deserves more attention. This is a process that is part of the circulation of ideas — from what is possible to what can be imagined and then, how do you construct it? As I collaborate more and more with innovation groups, designers, products people I am hopeful that more of the craftwork of creating what lies below the surface will be much more integral to the conversations these folks have. So that hardware craftwork is not outsourced but integrated in the concept, design, fabrication process.

Why do I blog this? Thoughts about the process of prototyping/sketching as a kind of design that’s part of “Design.”

The World's Slowest Instant Messenger, Part II

Finally, something to show for this “Slow Messenger” project, a playful interface for instant messaging. I’ve gotten all the hardware bits cobbled together and most of the firmware. Now I’m working on learning how to tie in AOL Instant Messenger so that messages can be delivered to the device. Fortunately (I think) AOL has opened their API somewhat. You get some sort of key and then can create your own IM applications based on their protocol and network. I don’t know how well this works, but I suspect if it works well-enough, a preposterous projects like this should be able to make good use of it.

I found one little unexpected design glitch — the LED driver (MAX6953) and the EEPROM I’m using (AT24C1024) have the exact same ‘default’ I2C address (0x50). I stumbled across this while trying to debug why the EEPROM didn’t seem to work, even after an electrical test and crap. You can typically hard-wire the chip to take on one of another possible addresses. On the AT241024 you just wire the A1 pin to either GND or VCC and set the A1 bit of the device address either low or high. The MAX6953 has a similar deal, only a larger matrix of possible different addresses, probably because the chip will typically be found in systems with lots of MAX6953s ganged together to drive large LED displays. In my case, it’ll be easier to make some small hardware changes to the Slow Messenger display board than it’ll be to change the AT241024, which is on a generic Flavonoid board that I want to keep as identical as possible to the other one’s to make managing the firmware easier.

Strange, but I thought that I got closer to having the real-deal I’d understand more about why I’ve committed so much time to doing it. But, I’m no where near understanding why I’m doing it or what it means. This may be beyond the near future and somewhere from another planet.

I heard someone confuse the Near Future Laboratory with corporate R&D. Like, essentially assuming that what I was doing was stuff just around the bend that someone at some corporate lab or product design operation is probably better suited to develop. Whatev. The Near Future Laboratory is the other near future â€”Â the one no one in a corporate lab would really think about because the demands of commerce minimize risk, don’t even scratch their heads if the perceived market is too small, and only think about what can be realized to help make next year’s earnings look good. Just to clarify.

Slow Messenger Part III

Technorati Tags: Near Future Laboratory, slowest instant messenger