First two are from us.  We just found the third one!

Ok a lot’s happened. Leo, Joel and I worked furiously to get the vests built up and out. We made 7 for the Lightning in a Bottle festival. Huge success and can’t wait to work on the v2.

The current version of the iPhone interface is below. I’ll post pictures of the hardware installations in the next posting.

We had a great time walking around the festival in sync. People loved the vest but when they saw that it was controlled from a central controller, they freaked. It was really fun to see the reactions. We had almost no issues with the hardware or software. I sat on my system and broke one of the connections. Would have been an easy fix but one of our friends left so I just took his. Also, I tried to create a couple of other patterns but realized that I would have had to re-burn the Arduinos. Not something that I wanted to try to do out there (possible but not …).

The LiPo batteries worked great. We standardized on the 2200mAh size and recharged each night. I think these would work for a couple of nights but it would have been a risk. We worked for about 4 hours and I think it would be safe to stick with this 2200mAh size for Burningman because we’d probably be working on a longer time set. Also, the iPhone battery needs a backup. I was running out quite quickly and the Minty boost charger wasn’t working well. Need to debug that.

We loved having the project come to fruition. I’ll post more details but just wanted to put an update out.

Another while.

A lot of tying up loose ends lately. Mocking up and finalizing the software. The bigger items have been taken care of already. Leo is working on the pattern and construction of the vests themselves. We’ll be working on a full mock up this weekend so we’ll send some video out then.

The biggest issue I’ve been dealing with lately is with power. I got some sample Li-Po batteries and mocked up a power supply for the LED strands. Surprisingly I was seeing 2A coming through. The spec said 1A. I called CoolNeon and they admitted the error. I’m scrambling to find another power supply because 2A melts the plastic with a linear regulator. Wanted to use a switching power supply but it would be difficult with the time and effort. I found some interesting circuits built for RC systems and ordered a handful for testing. This weekend should be fun on that front. Boo to CoolNeon for the bad advertising.

We mocked up some of the fur that Leo got and it’s actually quite nice. I’m looking forward to the full mock up. Stay tuned.

It’s been a while since I’ve blogged. Sorry about that. A lot has been completed. In some sense much of the last month has been spent on bundling up the project for deployment. I’ve built some prototype wearable enclosures and Leo has been helping with scoping out how the vest are going to be assembled. We played around with a few configurations last night and the consensus was that it’s going to be really cool. It should be pretty hard to mess this up now.

I’ve been cleaning up the code quite a bit over the last few weeks. Documentation, robustness, organization, performance, etc. There’s still a lot to do but the framework is now in place to be able to evolve much more quickly. Pattern design can now take a front seat.

• Upper right shows a count of the currently active members in the network. The idea is to click on that triangle and show a detailed list of who’s in the group. I decided to remove the details from the main screen for artistic reasons.
• The center flash button is what I think will be the main interactive command. This causes all strands to do a strobe like effect. I think this will work well with music.
• The circles around the flash button are representations of the members. The size and position of the circle is controlled by the radio signal strength. It works quite well to move the radio away from the controller and watch the circle shrink smoothly. Also, these are animated, orbiting the flash button at a speed depending on their closeness. Like.
• The layout for the rest of the buttons is free form. I’ve refactored the code to be a bit more flexible and it’s just a matter of designing patterns and implementing the details.
• Sliders are a bit enhanced to make it easier to select. On the phone these were really small and difficult to control

I need to upload some video of the interface in action. Also the effect on the fur that Leo found is really nice. It’s almost like you don’t need too many patterns!

Working on building a deployment version for the phone. I think some of the performance issues could be due to the debug version that I’m running. Having some problems with getting a .ipa file generated. This helps but not there yet (http://forum.openframeworks.cc/index.php?topic=7758.0).

Massive, massive success tonight. Finally took the leap to get the iPhone setup. It was a hold your breath kind of night. A few hiccups. One, I had trouble finding the right ground pin. What I was told in some of the blogs wasn’t giving me the 3.3V that I needed to power the XBee. I finally settled on pin 15 which I found referred to as a valid ground. Second, I forgot to change the serial port identifier to the iPhone (/dev/tty.iap). Patience. Got those items fixed and was good to go. Got it to work exactly the same as it works in XCode. Huge grins. Popped the corks kind of thing.

I also received my Mega proto shield and built it up to start testing with 2 clients. There was some concern on the sparkfun website about building it up but it went ok. Another couple of hiccups. First, the TX / RX pins were difficult to get to (because there are so many on the Mega). Second, the SPI pins are moved to the 50s. Forgot about that one but…patience again. Read up on the TCL documentation and its reference to check the documentation. Got it. So 2 clients running now. And they popped up! Great to see them both on the screen and getting them to work with the iPhone.

Upped the baud rate to 57,600. This helped with the dropped packet issue I was seeing in XCode. Funnily enough though, I didn’t see the dropped packet issue on the iPhone. I’m wondering if this has something to do with the USB connection to the XBee from the computer.

So my big concern now here is openframeworks performance. In XCode, I’m seeing a full CPU being taken up. Not good. Also, some of the animation that I was doing on the phone looks sluggish. I have to look into this now.

Last couple of nights has been a good cleanup opportunity. I’ve tidied up some of the error handling and logging so that I have more information on timing of messaging. One of the issues was that I wasn’t getting a TX status response message. I forgot to set the frameId in the transmission. I’m now getting a status response. One of the issues that we’re going to have is with timing. The status response takes on the order of 50ms. This seems long and may be an issue as the swarm grows. 10 members means .5 seconds. We’ll see how it scales but I may need to investigate the broadcast message. I’m just concerned with acknowledgement. Research, research.

Batteries. Some research needed here too. hobbyking.com has some good options (and I just learned about them today). I need to talk to someone about this and I’ll be going to Boss Robot to see what they have. Maybe a little more expensive but will make the network more stable.

I’ve been playing around with the system here for a while and it’s really fun. Pump, sparkle, full color…. No problem!

Poco! I just learned about this framework and it looks like a great thing. It’s bundled in the openframeworks distribution. There is a lot of functionality here that I will take advantage of. First was to get logging message with millisecond resolution. There’s a lot more here to look at. I’m thinking that there may be some opportunity to link into the network at burningman to see if we can get some synchronized messaging from what’s happening there live.

Had a nice day of around the house puttering. Sometimes that’s what you need on your birthday.

Was able to make some good progress on Coordinator -> Member communication. I had to refactor the Member Arduino code a bit to help modularize how patterns are going to be designed and executed. Once that was done, I got the coordinator to fire off various commands to the member (full color strand control, sparkle, sparkle descending). I then got Elan to wear it and wander around while I controlled it through the simulator. Works!

still have a couple of problems. One is that the member inexplicably drops out and the “time in swarm” count resets to zero. I haven’t seen a pattern to this yet. Also, I haven’t gotten the iOS memory usage analyzed and I really need to get a handle on that in order to avoid any long running issues.

And, I need to figure out the battery situation. A 9V wasn’t cutting it for long. I could probably address part of it by not running the brightness so high. This was part of the sparkle design that was interesting to discover. Your eye can’t really tell the changes at the top 25% of the brightness loop. I shortened the time it spends there and it helped make it more ‘sparkly’. I should probably take advantage of this with the full brightness control.

Weekend was productive. Was able to setup a sync script to make sure that the iOS and OSX versions are based on the same code. Code is copied from iOS, renamed and then checked in to SVN.

Also, I’ve created an openFrameworks slider that I’m going to use to help select the color for the LED strand. Below is a screenshot from the iPhone simulator. Lifting your finger will broadcast a color setting message to the clients. That is the next step.

It’s been a fun couple of nights. I’ve been working on the bi-directional communication aspects of the project and now have the iPhone simulator sending commands to the Arduino to change the pattern of an LED. Simple but cool.

I’ve also solved the issue of the dropped member. I’ve instituted a 20 second heartbeat absence as a drop. The icon representing the member changes when a drop is recognized.

Did a little hardware work too. Soldered up the iPhone breakout board and built up a connector for the TCL LED string. It’s plugged in and ready to play with. What I want to do is build an openframworks widget to help control various aspects of the TCL wire. Specifically the RGE levels and overall output level of the string. There are a bunch of openframeworks addons available but after reviewing them I’m of the mind that I should create them myself. Wish me luck.