http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf
Even if you only read the abstract, this is a really cool paper.
Sunday, March 25, 2012
Wednesday, March 21, 2012
Wiimote Whiteboard Demonstration
http://www.youtube.com/watch?v=VwhGGChEUHg
This is an alpha demonstration of the Wiimote Whiteboard project that the project group that I'm in through UVM's C.S. Crew is a part of. My part in this project was project director and chief software engineer (if I had to give a title to it). In other words, I was responsible for delegating tasks out to each team member according to their ability as well as taking on a portion of the coding myself. Also, since I built the fundamentals of the program and held the master copy of the files I was also the one in direct contact with each group member for assistance on integrating things.
So let me break down what you're seeing in this short video (besides my Whistling). On the surface, you're seeing a projection of the screen from my laptop onto a canvas. There is (out of the picture) a Wiimote facing dead on to the canvas, and in my hand is a small IR LED attached to a 22 Ohm resistor and 2 1.5V batteries. The wiimote functions as a sensor that picks up the IR LED output. (Infrared light), this wiimote is paired to my laptop through a bluetooth dongle. This device is then found by C# software written by my group and Brian Peek's Wiimote Library.
The program pairs to the wiimote using Peek's library, and from there a wrapper class allows for points found from the Wiimote to be sent to the program. This wrapper class was my task in the group. The UI queries the wrapper class for another point and then decides to either draw, or to click a button depending on the points it recieves. There a few other things that I'd like to mention without talking about the details. The program is a completely multithreaded program. The UI runs on it's own thread, and the wrapper class is queried on a seperate thread. There a few timers that run during the course of the program, during calibration timers run to fill up streams of points that are then interpolated to configure the wiimote's point of view into one that transforms into the picturebox on the form.
After calibration, points are queued as well as written out to a data file, and whenever the UI asks for a point, a point is dequeued from the queue and shown on the drawing pane, or causes a click. A few windows 32 dll's are used to cause the mouse to follow the IR pen and to help aid clicking a button. There is a variable rate of points coming in from the queue, this is decided by a variable normally set to 10, that corresponds to a timer querying the queue every 10 milliseconds to sync up with the Wiimotes 100 report generations a second. All of this combined enables us to do what we did in that short video.
This is an alpha demonstration of the Wiimote Whiteboard project that the project group that I'm in through UVM's C.S. Crew is a part of. My part in this project was project director and chief software engineer (if I had to give a title to it). In other words, I was responsible for delegating tasks out to each team member according to their ability as well as taking on a portion of the coding myself. Also, since I built the fundamentals of the program and held the master copy of the files I was also the one in direct contact with each group member for assistance on integrating things.
So let me break down what you're seeing in this short video (besides my Whistling). On the surface, you're seeing a projection of the screen from my laptop onto a canvas. There is (out of the picture) a Wiimote facing dead on to the canvas, and in my hand is a small IR LED attached to a 22 Ohm resistor and 2 1.5V batteries. The wiimote functions as a sensor that picks up the IR LED output. (Infrared light), this wiimote is paired to my laptop through a bluetooth dongle. This device is then found by C# software written by my group and Brian Peek's Wiimote Library.
The program pairs to the wiimote using Peek's library, and from there a wrapper class allows for points found from the Wiimote to be sent to the program. This wrapper class was my task in the group. The UI queries the wrapper class for another point and then decides to either draw, or to click a button depending on the points it recieves. There a few other things that I'd like to mention without talking about the details. The program is a completely multithreaded program. The UI runs on it's own thread, and the wrapper class is queried on a seperate thread. There a few timers that run during the course of the program, during calibration timers run to fill up streams of points that are then interpolated to configure the wiimote's point of view into one that transforms into the picturebox on the form.
After calibration, points are queued as well as written out to a data file, and whenever the UI asks for a point, a point is dequeued from the queue and shown on the drawing pane, or causes a click. A few windows 32 dll's are used to cause the mouse to follow the IR pen and to help aid clicking a button. There is a variable rate of points coming in from the queue, this is decided by a variable normally set to 10, that corresponds to a timer querying the queue every 10 milliseconds to sync up with the Wiimotes 100 report generations a second. All of this combined enables us to do what we did in that short video.
Subscribe to:
Posts (Atom)