Robosapien Repairs
I got a Robosapien V2 on Craigslist for very short money, and started working on turning it into a robot. This doesn’t interfere with my other projects because the stuff I’m using to robotify it is the same codebase I’ll be using for brain hacks at Defcon and and a drink dispensing robot at future festivals. But I digress.
On powering it up, the Robosapien complained about a “low brain battery” and turned itself off. When I replaced the batteries, it failed to do anything at all. I checked a few forums, and it turns out that the problem is the wire insulation failure that struck a lot of the Robosapien V2s. The problem is that the insulation on some of the wires, particularly the ones that are single strands, rather than part of multi-wire cables, is bad. It becomes brittle and crumbly, and then flakes off when the robot moves. This causes the batteries to short out, and die quickly, if you are lucky. If you are not lucky, the Robosapien melts or catches fire.
In my Robosapien, the affected wires appear to be confined to the leg wiring harness, particularly the motor wires, battery leads, and wires from the foot switch PCB to the main PCB. To fix this, I’m going to extract the wires, and replace them with un-crappy ones. It’s kind of a tedious job, but I am actually kind of looking forward to it as a way to unwind at the end of the day. Have a beer, replace a bunch of wires, chill out.
IR Receivers
For a long time, I have been thinking about making a set of pin badges that signal to each other using an IR pulse, and blink with a visible light. If a few of them were together, they would synchronize their lights, like fireflies.
To do that, I’d want to detect IR, and reject IR that was not from one of the badges (like light from a fire or the sun). The IR receivers that go into TVs do that, and there are super-small versions available for surface-mount construction.
Osram’s SFH5410 looks perfect, but was discontinued, this time in 2010, and without a suggested replacement.
Sharp makes the GP1US30XP series in surface mount packages about 4x4mm. Their sensing direction is normal to the PCB, which is ideal for aiming them away from the wearer. This would be the ideal part, if but it was also discontinued.
For purposes of prototyping, I can use some larger parts that I already have, but the ultimate design will be very small. Someday, perhaps I’ll have them fabricated professionaly and give them away at Firefly.
Toy Helicopter Hacking
This Christmas, my parents gave me a palm-sized toy helicopter (Avatar Z008), and my girlfriend’s parents gave me a slightly bigger toy helicopter with a video camera (Egofly Spyhawk). I also have one that I bought myself (Syma S107). All of them are gyro-stabilized, coaxial-rotor helicopters, which basically just means that they automatically don’t roll, and are easy to fly.
I had hoped to convert one of them into a tiny drone. I opened up the S107 this morning to take a look at the internal PCB. The IR signal from the remote goes to an unmarked 14-pin IC. The gyro (which I assume to be the little metal can mounted on a daugther board from the main PCB) is marked, with “C 146” and “Y2373”. One pin of the gyro is grounded, one, marked “TLY” is connected to the unmarked IC, and one goes to Vcc. That is pretty clearly power, ground, and a signal pin.
This means any control that the system is doing based on the gyro is done by that unmarked IC. Chances are that re-implementing the gyro control would be amusing, but much harder than simply adding whatever drone control I decided to add “on top of” the existing hardware.
An easier approach would be to take advantage of work that other people have done on reverse-engineering the IR protocol, and add my own control circuit that sends IR control signals to the existing board. That way, the existing board would take care of driving the motors and keeping the helicopter balanced, while my board would add autonomy.
Downward and front facing versions of SpeckleSense could be used to give the helicopter a sense of its movement in the world, which might be good enough for dead-reckoning navigation over small distances.
Mindflex EEG Hacking
I got a Mindflex Duel for Christmas. The Mindflex Duel is a toy that uses a pair of EEG headsets to read signals from the users, and then send those signals to a base unit that contains a blower and a little sliding cart to move the blower. The users try to concentrate to control the cart, moving a little ball suspended in the air jet from the blower into a goal.
Needless to say, I gutted it.
The base unit has a little PCB with a 2.4Ghz radio on it, and a little hardware to control the blower and cart motors. The headsets are the really interesting part. Each one has a single-channel EEG and a wireless radio. I took the radios out and replaced them with BlueSmiRF bluetooth-to-serial links so that I could connect them to my laptop. The hardware part of the replacement is below, the software part will be in another post.
The guts of one of the headsets. The 2.4 Ghz radio is the top daughter board, the EEG hardware is the bottom daughter board.
I desoldered the original radio. It works in the same band as Bluetooth, and consumes power, so there was no need to have it there.
The red and black wires supply power for the BlueSmiRF. It can take up to 5 or so volts, but the headset runs on 4.5v, so it is fine to hook it up like this. The red wire is connected to the power switch, rather than V+, so that the power switch also turns off the bluetooth radio.
The white wire goes from the pin labeled “T” on the EEG board to the RX pin on the BlueSmiRF. The T pin of the EEG board is a serial line, which transmits the EEG data to the BlueSmiRF.
Glue the bluetooth radio into place with hot glue. The LEDs on the BlueSmiRF are covered by black paint on the inside of the Mindflex headset, but I scractched away the paint in little circles so the BlueSmiRF status lights would shine through.
The finished product looks stock, until you turn it on. That red light on the side is not normally there.
Toybrain further improvements
I populated one of the Toybrain V2 boards and gave it a bit of a shakedown. I still have to test the motor driver, but I’ve at least fixed the backwards ICSP header and the reversed TX/RX lines. I did add a LED for debugging, but then hooked it up to a ADC line, so lighting it up means losing an analog pin.
For those as don’t know, you can get the analog pins on an Arduino/ATMega168/ATMega328/whatever to act as a digital GPIO by treating it like one, using the aliases “A0” through “A5”. Full instructions are here.
The V2 boards also have a reset button, which is very useful.
I’m already working on V3, which is going to be smaller. The V2 has headers for power, ground, and data for each pin, which I think is a bit much. I want that room back to build a voltage regulator and some filtering onto the board. The microcontroller can run at 1.8 to 5.5 volts, so the filtering is a bit more important than the regulation. However, some toys surely run at 6 volts or more, and would ruin the microcontroller, which is a SMD device.
So V3 will include filter capacitors, probably SMD, on the power rails, and a 3.3V regulator (The Micrel MIC5209-3.3 in SOT233 package looks good) or the option to short around it. The regulator only supplies the power for the microcontroller, so it won’t need to be very high power.
ToyBrain V2 Ordered
I’ve ordered the boards for the second version of the ToyBrain project. These boards are smaller than the originals, and should correct most of the problems (swapped TX/RX lines, put the ICSP header in right, etc.) I’m planning to outfit them with ATMega328s.
If these work and are all correct, the next version will be done in black, possibly with gold for looks. After that, perhaps I’ll make a kickstarter of it and see if I can’t sell a few boards.
Cider started
A while back, Sami and I made two gallons of hard cider. When we were doing that, we made two errors as well. The first is that we put in the ginger, cloves, and cinnamon that we wanted to flavor it with when we pitched the yeast. Cinnamon and cloves are both antifungals, so they probably contributed to the yest dying off. We also used normal bread yeast, which isn’t very hardy. The resulting cider tasted fine, but it was very sweet, because the yeast died before it had a chance to convert much of the sugar into alcohol.
My new batch of cider is 5 gallons of cold-pasteurized (with UV light, apparently) cider from Bolton Spring Farm, one packet of SN9 yeast, 5 tsp. of yeast nutrient, and about two pounds of sugar. I started it earlier this morning, and the yeast appears to be working already, forming carbon dioxide and lifting itself in the cider. My plan is to let it run until the yeast poisons itself and settles out, and then flavor the cider with cinnamon and cloves and bottle it. If I go with cinnamon and cloves, I probably won’t do a second fermentation to get it to be carbonated.
Drinking with Robots
I am building a drink-dispensing robot. It has 5 pumps internally, so I want to find the set of five liquids that will produce the largest variety of mixed drinks. To do this, I’m going to need a huge set of drink recipes. I got a bunch from a cocktail database that esquire maintains, but the biggest list I’m aware of is The Webtender. Unfortunately, that database isn’t in a form that permits me to make queries to find out what is the maximal set of drinks that I can make, given the constraint of 5 liquid ingredients. So instead of the web interface, I want the raw data.
This means I want to download every single drink recipe from The Webtender. The URLs there are of the form http://www.webtender.com/db/drink/6217, so the obvious thing to do would be to write up a little bash oneliner that just wgets each of the files in turn. It would probably look something like this:
for (( i=1; i <= 6217; i++ )); do wget http://www.webtender.com/db/drink/$i; done
But it may be that The Webtender issues a 403 Forbidden error if you use wget, probably to prevent just this sort of hijinks. Unfortunately for them, wget can be configured to claim to be something else. These instructions provide the config file to cause wget to claim to be Mozilla on Windows NT, which The Webtender should have no problem with.
For my next trick, I'll use BeautifulSoup to turn the HTML files from the webtender and Esquire into a SQL database, and probably perform some form of normalization on the data, such as making all the measurements be in the same units.
Cross-system chat log sync
I created a directory called “pidgin_logs” in my Dropbox folder, backed up my logs, removed the old log directory, and then created a link from where the log directory should have been to the Dropbox directory. Pidgin still starts up fine, and after I do this on all of my systems, they will all log chats to my Dropbox account.
I’m not sure I’m comfortable with the level of trust that this places in Dropbox, but it will be very convenient.
The commands to do it are:
cd ~/Dropbox/ mkdir pidgin_logs cd ~/.purple/ mv logs logs_backup mkdir logs ln -sfn ~/Dropbox/pidgin_logs ~/.purple/logs mv logs_backup/aim logs/ mv logs_backup/jabber logs/
Academic Problems in New Media Art
I’m trying to convert Deluze & Guattari’s A Thousand Plateaus into a corpus for use by a program. Among other things, the program will break the text down into its component sentences. The text has a lot of notes, which connect the text to a lot of other sources, but are not always written in complete sentences, and so will result in odd output from the program when considered as sentences.
So I’m faced with a choice: lose the notes, and so lose the cultural context and references to stuff that went before, or keep them and suffer degraded output. Nobody warns you about the odd stuff you’ll have to decide when you start doing new media “art”.
Recent Comments