Hacking the Trivial Pursuit – Digial Choice Edition – pt 1 -
I acquired the Trivial Pursuit - Digital Choice Edition game at a local target for 10$. It's an interesting little device, with an b&w LCD display, usb out, 16mb internal storage, and the ability to download or create your own questions... on windows only (ouch).. Turns out it's an interesting device. Here's what I've been able to find out so far.
Wallclock 4.0 – Portable Project Natal
So every week or so I go to my junk box and look through the parts I'm not using. I think to myself, "Hunter, do you need this or is it taking up space?". The answer is always "taking up space", hence my penchant for soldering (taping, hot gluing, welding) things together. This week, it was a slim ps2. Taking the wallclock (microscope edition) apart, I stripped it of a couple of printed circuits (don't reeeeaaaly need that last row of keys do we?). A disassembly of a ps2 eyetoy camera revealed a tightly integrated circuit board with a sharp L angle. For those of you who have never played eyetoy, it's essentially project Natal with a low resolution webcam. Fantastically fun at parties, not particularly lasting for single player.
Wallclock 3.0 – 200x Microscope Edition
Every once in a while you come across a busted piece of kit that you know you make useful again. This week, it was an ACN Video Phone. For the unknowing, ACN sells ip phone/video phone service bundled to their video phone hardware. On the upside, the resale value is very low. On the downside, this means it's worthless without the monthly fees.
... Or IS IT??
My new wallclock at work ;)
10 year old HP Jornada Windows CE 3.0 device - 15$
Serial extension cable - 1$
Shell script to display network and system statistics - 0$
Using Linux - Priceless.
Calorie Counter for Game Boy Advance and Nintendo DS
Ok,
So having lost 30lbs since I wrote the python calorie counter, I'm a big proponent of counting calories. It WORKS. Not only that it's easy, and it appeals to the chewy mathematics center of my brain. All is well and good, and I've got a nice phone that supports python scripts so I'm set. There are some instances though, where a phone is just too much bulk to carry around and I really just need something smaller.
As luck would have it, I came across a game boy micro.
This little devil is TINY, and fits right in a shirt pocket no troubles. Plus you can get one for 30$ used at gamestop, bonus! However there was one tiny snag, there's no python interpreter for GBA!
So I wrote a version of the calorie counter application for the game boy advance. It uses the savegame sram to store your current calories and calorie goal. It'll work in any gba emulator, flash cart, or the nintendo ds gba slot. Even better, most flash carts allow you to use it for your startup game so the time to start is around 2-4 seconds. Very reasonable! Anyway, it's pretty simple stuff and gplv3 so feel free to give it a try or even modify it. Note, you'll need the excellent HAM gba library to recompile.
You can download it here: GBA Calorie Counter
Food (and diet) management for the unix geek, a python script
For many a scientist like myself, the pear-shaped waistline which has become synonymous with the unix guru has become all too familiar. While there are a number of mitigating factors, I'm going to chalk it up to the sedentary lifestyle of the typical programmer. A study posted on Digg last week showed that on average, dieters who kept a food journal lose twice as much weight as those who don't. That's a pretty powerful tool. Carrying around a notepad doesn't make a lot of sense for me, as I'm almost never without my laptop, so I've been keeping a csv spreadsheet like below:
07:53 ,oatmeal , 160
07:55 ,water , 000
10:40 ,kudos , 100
10:40 ,water , 000
Which is fine. It accomplishes what needs to be accomplished, with regards to the diary at least. However, I would like some statistics with my diet. How many calories do I have left in the day, how many glasses of water, how many calories did I eat at lunch, etc. These little statistics and calculations really drive home the message. I always keep today's .food file on my desktop, and I have my .bashrc set up to show me my dietary information whenever I login or open a shell like so:
# display how many calories I've left/eaten today
echo "Remember to fill in your .food file today"
echo "-----------------------------------------"
~/Scripts/DotFoodStatistics.py ~/Desktop/*.food | grep today
echo "-----------------------------------------"
Attached-> python “food processor” diet statistics <- is the simple python script I wrote to calculate food statistics and keep track of my dietary intake:
As you can see it's a very simple procedural script. Took me all of 20 minutes for the python. Only time will tell if the dieting is as straightforward.
Half a line of shell to display to screen while compressing output… The most useful shell I’ve written in forever
Ok, so here's the deal. I write a lot of C in my line of work, so when I get the chance to write some clever shell script, I relish it. I do a lot of long supercomputer simulations, which tend to be hard to debug (especially when a problem arrises 3 days into a 4 day run). This is where logfiles come in handy, I know I'm not alone in this. Unfortunately, for really long runs these logfiles can add up to hundreds of gigs of space, which is a hard to come by commodity on supercomputing clusters. I found numerous solutions online, all of them tending to be long and overly complex shell scripts... No thanks!, when I want something done on shell it needs to follow the shell paradigm, small and powerful.
The problem:
I want to see the logfiles as they are created, but I also want them stored and compressed and not taking up space.
The solution:
---------------------------------------------------------
| tee >(gzip > logfile.tgz)
---------------------------------------------------------
Let's break it down one bit at a time
| tee
Standard output is piped through tee, the unix t-shaped pipe, pretty much comes standard with all *nixes. Tee has two outputs, first it outputs to a file (or file handle), and second it pipes the output to the screen.
>()
This right caret/parenthesis pair comes in very handy. It opens a sub shell, leaving an implicit file handle that can be piped to. Tee sees this as a regular file, and begins piping standard output to it.
gzip > logfile.tgz
Gzip defaults to standard in for the input if no file handle is given. It uses lz77 encoding along with Huffman trees in a 32k sliding window. Decoding data (Huffman trees) are placed at the beginning of each block. This means
--------------------------------------------------------
| tee >(gzip > logfile.gz)
--------------------------------------------------------
Putting it all together, we pipe standard output to tee which pipes to screen as well as the implicit file handle created by the sub shell. The sub shell is gzipping the piped standard input at maximum compression and outputting the resultant gzip file to logfile.gz. Just pipe any huge log file through this bit of code, and you've taken your space requirements from gigs to megs, with virtually no cpu/memory overhead. Handy, and fits easily into most launch scripts.
Re-Writing the laser pointer paint program (image processing) in C/C++ – 10x speed improvement
This should significantly increase our capture and processing speed. First, install libcv1 in ubuntu, I like to get the documentation and python bindings as well, and these will install libcv1 anyway. sudo aptitdue install python-cv opencv-doc Now we'll start writing some C code. As I have the benefit of writing this article after the code, I know that one can render/display 30fps without processing, and can render/display without lag with processing as well (thank you compiled code!). You can compile opencv code in linux using the following command:
gcc `pkg-config --cflags opencv` `pkg-config --libs opencv` -o MY_PROJECT_RUNME MY_PROJECT.cpp
Well that's simple enough. The structure of the program has a few changes.
- Program takes first command line argument as the image filter size (try 2-10 for good results)
- Program no longer does image subtraction for a mask over the image, it's direct processing now
- Program is significantly (10x) faster, depending on speed of camera frame grabs
- Check out the openCV tutorial for grabbing images from a camera, then check out the code below..
- You can snag it here
- Also, please note that 'escape' will end the loop and finish the program
Home Automation + Gmail in Ubuntu
Ok, now that we have a working home automation server setup (see article 1), let's plug in a lamp module and have it flash when our gmail arrives. First up, plug in the light module, select your house code ('heyu info' will tell you your house code) and an unused x10 number on the dial.
Find a lamp you'd like to have flash (or turn on, or dim etc etc) and plug it into any other outlet. Turn on the lamp, you want to be sure the light is actually on before you start cursing at your x10 module. Now plug the 'on' light into the x10 module. Let's try turning on the module with a heyu on A3 Where A is your house code and 3 is your module number. Voila, you should have light. a quick heyu off A3 will get us back to the off state. There are many heyu options (dimming !) to try out, but they all work in this manner. Now, let's install gmail-notify with a sudo aptitude install gmail-notify Gmail notify is a great python script to notify you when you have gmail. We will insert an execute command into the python code (very simple) so when gmail-notify runs and we have an unread email, flash the light (or dim the light, or turn on your lava lamp, etc.)
Fire up your favorite editor (I prefer vim, but most guides prefer nano) sudo nano /usr/lib/gmail-notify/notifier.py Now head down to line 208 (it was 208 as of 9/07). You are looking for this block of code: if attrs[1]>0: print str(attrs[1])+" new messages" We will change it to: if attrs[1]>0: path = '/usr/bin/gmflash.sh' os.system(path) #execute gmflash print str(attrs[1])+" new messages" What we've done is told gmail-notify to execute the script /usr/bin/gmflash.sh when there is new gmail. Now we'll need to create this script with a sudo nano /usr/bin/gmflash.sh Here we'll tell the x10 light to flash on, then off. It takes my x10 module 1 second to deactivate a light and 1 seconds to activate one. It takes my light 2 seconds to 'warm up' to bright. We'll want our script to pause for at least (1 + cycle time + bulb time) seconds, so in my case that's 4. Insert into your editor window: heyu on A3 sleep 4 heyu off A3 Save it, close it, and make it executable with: sudo chmod +x /usr/bin/gmflash.sh
That's all there is to it. Fire up gmail-notify, put in your gmail settings, and send yourself a test email to check. If your light doesn't flash, try executing /usr/bin/gmflash.sh. If this doesn't work, time to re-check your setup. Fin.
Using scilab video processing toolbox and a laser pointer to “paint” a scene in realtime.
A little tic/toc ery has shown that without an image draw scilab can process 3 fps. So here's a loop unrolled version that delays image rendering till 3 dots have been drawn.
//"paint" a scene with a laser pointer in realtime
//speed of update depends on speed of camera + processor
//could also easily be used on a video file
n = camopen();
for idx=1:15,
//give the camera time to auto white balance
im1=avireadframe(n);
end;
im3prime = rgb2gray(im1);
//save our "primary scene"
im3 = im3prime; imshow(im3);
//show us our primary scene
r=x_message(['Baseline Set'],['Ok']);
//let us know when to laser pointer
for ido=1:15, mask = zeros(im3);
//clear out our mask quickly
for idx=1:3,
//or however many frames/sec you can process
//tic;
im2=avireadframe(n);
//read a frame in
//subtract the greyscale current image from the primary scene
//then take that logical array, convert to numerical and
//use it as a mask over im3
mask = mask + bool2s(imsubtract(rgb2gray(im2), im3prime) > 50);
//imshow(im3);
//toc
end;
im3(mask == 1) = 255;
imshow(im3);
end;
avicloseall();