Eureka!

I bought a usb-serial adapter today (amazingly only $15) and hooked it into the s'ware I've been writing for a few weeks. Like magic, it worked!

Therefore, there are some *known* bugs to be worked out, but... when I walk into my bathroom with my laptop in hand, it makes a flushing sound *childish grin*

I created abstract regions too [they aren't convex hull or anything, just circles and rects] -- if a condition, like being in a region, fails -- the event that was triggered is stopped.

I do *not* support any kind of triangulation at the moment. Each beacon is a singularity as far as it's concerned. But I have function calls in place waiting to be filled.

Oh... and we still need to get a 9 pin serial->USB adapter if we hope to use this on any modern laptop. As it is I'm still using the serial off my desktop (with a nice long cable ;)

Java Gallery Progress

Now that I finally finished cs161, I've been working on the user-end code and spent a while refactoring it and making it nice and somewhat painless to create somewhat expressive 'galleries' -- meaning, extending a Gallery class to define how a particular gallery works, e.g. RISD gallery, or CIT computer museum gallery, etc...

There is still lots that could be done on it (it's not a hack, it's a very elegant, well-thought-out hack). I'm hoping to connect it to a live cricket data stream in linux in a few days (I've been using a prerecorded session) -- InputStreams are data sources, so it's pretty easy to wire into a file, a socket, or a terminal in Linux.

Of course, this means that the implementation requires a laptop, preferably running Linux (the Cricket code that broadcasts readings from the serial port is *Nix only -- we'd have to port it otherwise), and necessarily running Java. This could be changed by rewriting the code in another language, but Java is good for prototyping.

---

Ideally the user code would be extended to server code, which would understand stateful sessions of users running the same gallery. And that we could recieve readings via BT or WiFi TCP, and stream audio packets back over BT. (there's more to worry about, like mixing the audio, or making sure there's only one stream playing -- not really within the realm of what we've got now).

Status on Cricket

Currently I can get raw cricket readings via serial port (forwarded over TCP). So at the least, if we have a laptop with a serial port moving around, we will be set.

I do not have proper localization working, per se -- but I am simplifying what we want cricket to do for us (for now): Rather than localizing where someone is based on multiple crickets, we will do what our initial goal was which is just consider distance to a single cricket. Meaning that we will know our radius to a node independent of what other nodes are saying, and can calculate our position to an accruacy of 1cm.

This way we can determine when someone is close to a point and trigger an event.

One way to improve this is to increase the sampling frequency on the nodes so we can get a more continuous gradient and potentially get acceleration. Neat.

For now, I recorded a dump of the communication as a listener moves towards a node, and will use it as 'training' data while I work on a Java client that parses the stream and triggers events.

Progress Report

The progress report is now available in PDF and PS

Project Proposal

Excitement! The project proposal is now available:
For those that read PDF... and those that run PS

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.