Bokode @ Home – Recreating MIT’s bokode tech with everyday materials

One interesting paper I read from this years SIGGRAPH paper on the creation of an interesting real life tagging technology called Bokode. Here’s a DIY page detailing an implementation. It’s really quite simple (and neat!) I might have to code this together.

Bokode @ Home – Recreating MIT’s bokode tech with everyday materials.

Day 2 of the NVIDIA GPU Technology Conference

Yep, I’m actually at the NVIDIA (why do I type NVIDIA like nVidia? everything seems to indicate that it is all caps now, I dunno) GPU Technology Conference, trying to once again get into the swing of things with respect to GPUs. Sadly, almost everything I know about computer graphics (which is actually considerable) predates the ongoing revolution that GPUs have brought to the table. We’ll see if some of this sticks this time around. For the first time, I’m beginning to grasp the functionality of current machines, and see where the evolution is going such that I feel it might be worth committing a significant fraction of my (seemingly always shrinking) store of available brain cells.

It’s about time for the 2nd day keynote by Hanspeter Pfister from Harvard, to start. I was lucky enough to serve with Hanspeter on a SIGGRAPH Sketch committee a few years back, and it seems like he’s been busy since then.

I might blog more about what’s going on here, but you might as well track what’s going on using NVIDIA’s official conference blog:

GPU Technology Conference Blog – NVIDIA.

Small caution on using PyEphem…

My previous post on using PyEphem to compute satellite locations was based upon my experience with the latest version (3.7.3.4). Apparently this includes a fairly serious change to previous versions: by default my FreeBSD box seems to install 3.7.3.3 still, and the next_pass method for observers doesn’t exist. So I thought I’d go back and use whatever calls they did, but next_rising followed by next_setting didn’t seem to return what I would expect. For example, this little program (first find the next rising, then, after that, return the next setting):

#!/usr/bin/env python 

import sys
import os
try:
    import ephem
    print "Using pyephem version", ephem.__version__
except:
    print "couldn't find an installed version of pyephem"
    print "try downloading and installing it from http://rhodesmill.org/pyephem/"
    sys.exit(1)
   

iss = ephem.readtle("ISS (ZARYA)             ",
    "1 25544U 98067A   09270.93046296  .00012316  00000-0  87133-4 0  6870",
    "2 25544  51.6378 139.3506 0009010 136.5725  48.2903 15.74423743622138")

obs = ephem.city("San Francisco")

iss.compute(obs)
print "ISS is currently at alt %f az %f" % (iss.alt, iss.az)
rise = obs.next_rising(iss)
set = obs.next_setting(iss)
print rise, set

sys.exit(0)

When I run this rather simple little program, I get this:

Using pyephem version 3.7.3.3
ISS is currently at alt -1.181396 az 4.241607
Traceback (most recent call last):
  File "./iss", line 22, in <module>
    rise = obs.next_rising(iss)
  File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 385, in next_rising
    return self._riset_helper(body, start, True, False)
  File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 363, in _riset_helper
    d1 = visit_transit()
  File "/usr/local/lib/python2.5/site-packages/ephem/__init__.py", line 317, in visit_transit
    % (body.name, d))
ephem.NeverUpError: 'ISS (ZARYA)' transits below the horizon at 2009/10/2 07:44:16

I haven’t tracked down what the deal is with this yet, but maybe I should keep on with my Python Plan13 code a bit longer.