Queue up an epiphany

So, I've been struggling with how I was going to implement the queuing system for rovlabs but here is what I'm thinking.

My idea is to create a cookie/session for everyone who enters the queue. When a user enters the queue they will get a pop-up "control box" that references the navigation page (a .php page). That page will process the ajax request and compare the users session ID with that of a list that will be stored in the database. Once the users session number matches that of who should be on active it will produce the navigation controls and notify the user that they are in control of the ROV.

Each directional change will cause a double-check of the users status and time left. Epoch time will be used to keep track of how long someone has been operating the ROV. If time runs out, then their next direction command will trigger a redirect back to a "thank you" page that asks for feedback before closing. A user can re-enter the queue at any time.

I am a little worried about the potential number of requests coming into the server. I might have to limit the queue itself, but it shouldn't show up as an issue unless the queue has a few hundred requests per second.

I will post a flow-chart asap.

CPAN rocks

http://search.cpan.org/~scott/Device-ParallelPort-1.00/lib/Device/ParallelPort.pm

Found a module in CPAN for PERL. I'll be integrating this with Ajax calls from the website.

NAME ^

Device::ParallelPort - Parallel Port Driver for Perl
SYNOPSIS ^

my $port = Device::ParallelPort->new();
$port->set_bit(3,1);
print $port->get_bit(3) . "\n";
print ord($port->get_byte(0)) . "\n";
$port->set_byte(0, chr(255));

DESCRIPTION ^

A parallel port driver module. This module provides an API to all parallel ports, by providing the ability to write any number of drivers. Modules are available for linux (both directly and via parport), win32 and a simple script version.

NOTE - This actual module is a factory class only - it is used to automatically return the correct class and has not other intelligence / purpose.
DRIVER MODULES ^

NOTE - You MUST load one of the drivers for your operating system before this module will correctly work - they are in separate CPAN Modules.

L - Direct hardware access to a base address.
L - Linux access to /dev/parport drivers
L - Run a script with parameters
L - Pretending byte driver for testing
L - Pretending bit driver for testing
L - Windows 32 DLL access driver

DEVICE MODULES ^

L - An example that can talk to a printer
L - Simple JayCar electronics latched, addressable controller
L - SerialFlash of bits - useful for many driver chips

METHODS ^
new
CONSTRUCTOR ^

new ( DRIVER )

Creates a Device::ParallelPort.

METHODS ^

get_bit( BITNUMBER )

You can get any bit that is supported by this particular driver. Normally you can consider a printer driver having 3 bytes (that is 24 bits would you believe). Don't forget to start bits at 0. The driver will most likely croak if you ask for a bit out of range.
get_byte ( BYTENUMBER )

Bytes are some times more convenient to deal with, certainly they are in most drivers and therefore most Devices. As per get_bit most drivers only have access to 3 bytes (0 - 2).
set_bit ( BITNUMBER, VALUE )

Setting a bit is very handy method. This is the method I use above all others, in particular to turn on and off rellays.
set_byte ( BYTENUMBER, VALUE )

Bytes again. Don't forget that some devices don't allow you to write to some locations. For example the stock standard parallel controller does not allow you to write to the status entry. This is actually a ridiculous limitation as almost all parallel chips allow all three bytes to be inputs or outputs, however drivers such as linux parallel port does not allow you to write to the status byte.

NOTE - VALUE must be a single charachter - NOT an integer. Use chr(interger).
get_data ( )
set_data ( VALUE )
get_control ( )
set_control ( VALUE )
get_status ( )
set_status ( VALUE )

The normal parallel port is broken up into three bytes. The first is data, second is control and third is status. Therefore for this reason these three bytes are controlled by the above methods.

Gantt Chart Update

Spoke with Greg, and some design elements might be axed, so he will getting more content responsibilities if that happens. I've updated and color-coded the gantt chart in the meantime.

---

Wet lab

Through some professional contacts Greg managed to procure a meeting with Neil Greenberg at the Aquaculture Research Center. We got a tour of the facility and discussed our capstone with him and what we would need. He was gracious enough to offer us a "small" tank (5 ft diameter, 4 ft deep) to do our testing and even maine card access to the facility when we begin "online" testing. This is very exciting. We should be able to get some large scale hands on testing earlier than anticipated.

Webcam problems

I recently created a way to embed the webcam (different server) through what will be the ROV Labs website, but it's not displaying properly on every system. Currently I'm using the mpeg-4 compression option embedded in the webcam, and streaming through a dummy file, but some versions of windows quicktime won't view it, and linux has no native quicktime applications.

To fix this I'm going to look into writing my own ajax query that will call a php script to pull a new image every 5 seconds. This will cause more load issues on the server, but it should allieviate concerns I have about having too many connections directly to the webcam.

Along with connections to the webcam, I plan to only show the 'Live feed" to those in the queue (last 10,and the driver) to save on additional bandwidth, as well as keeping the direct IP of the camera as obfuscated as possible.

You MIGHT be able to see the webcam here.

Site layout & Sitemap

---

(right hand div content defaults to the first item in the left hand sub menu, i.e. on the page Home, the content defaults to Be Innovative)

Home
   Be Innovative - Summary of project
   Be Inspirational - Summary of Aquarium Program
Pilot
   Be Curious - Watch web feed
   Be The Pilot - Enter queue for ROVEvolution
   Be The Best - Timeline of ROVs
Forums
   Links to ROV Labs Forums
DIY
   Be In Charge - Links to process, tools, supplies, etc
About
   Be New - Summary of New Media at UM
   Be Fun - Summary of our goals with the project
Site Map
   Be Sure - Links to other pages
Contacts
   Be Involved - Contact Info for us, umaine, aquarium
Bios
   Be A Fan - Links to both our portfolio sites / resumes / whatever

Webserver

Got the server configured and user accounts created for Greg. Hopefully we can move the rovlabs.com site over.

I'm currently working on streaming the webcam through the web server. Technically the webcam is a separate webserver on the same lan, so for security I want to make it accessible in only a very controlled situation. We'll see how that goes.

Here is the new server. We'll get the domain moved over as soon as we get the site up.

http://130.111.242.81

Web Cam and Server

Oh, almost forgot. I have a working independent server now. This will work as the web server for the aquarium on site, as well as the control system for the online ROV.

Here is a link to the webcam we'll be using. Currently it's just pointed out my dorm window...enjoy!

Testing site for the ROV itself.

Greg got in touch with Neil Greenberg yesterday, a faculty member on campus who has access to a testing tank. As of now, it seems we have permission to use the tank but we're going in on Friday to go over what exactly we need so we can get the required safety training for the equipment we'll need to use. This should really help with our wet tests, as right now we're forced to conform our ROV designs to that of something that will fit into a 20 gallon tank. I'll post more after our meeting.

Gantt Chart

Here is a rough plan from now until Spring Break. This schedule is subject to change.