Monday, November 16, 2009

moar laz0rs

So, got the table bits lashed together and working properly now. Ugly end product that looks like a 7th grader put it together:



And the end result is thus:



Unfortunately, one of the lasers is misaligned, so you still get bright light shining off your thumb when it's not touching the screen unless your hand is at a (completely unnatural) 90 degree angle to the table.

Support is the next thing to work on, then it's time to look at the projection stuff. Ouch.

What I ended up doing:

1) just using the clay to hold the laser and adjust the pitch and yaw, then striped some hot glue across the top to control roll.
2) stapled the wires up along the sides to the top of the frame
3) hacked up quickcam for the shots as noted in previous posts

It turns out that the grooves that I cut were pretty much unnecessary.. the light seems to shine fine if the laser is flush with the acrylic. We slapped wet modeling paper clay into each corner and used some guides to calibrate the beam, and pushed the laser down into the clay until it just about dug a channel out from the front of the laser to about half way back. Then we left the clay to dry for about 20 hours before gluing the lasers in place.

For calibration, we simply used 4 red Solo plastic cups to provide markers for the beam and adjusted the beams by using a webcam with the lights turned down low. We didn't use the modified logitech because I wanted to be able to see where the beam was in relation to the cup. Some stuff I learned during calibration:

1) if the beam appears to be V shaped, it means you've got one side angled up and the other side is a reflection from the table top.
2) the just above the white lip of the cups is about where you want the line to be, or right below the bottom crease on the cup
3) for the line splitters on the laser, you want to make sure that the rough side is facing towards the laser lens, and the smooth side is pointed out. :( Instead of a focused 89 degree arc, we got a 150 degree arc that dimmed the closer you got to the center
4) don't be afraid to drop the camera down under the table to make sure that you've got the laser shining at the right place... ie, test each laser from the under the table POV

Sunday, November 8, 2009

laser table update

We ran into a problem with the lasers, or more specifically a problem powering the lasers a couple of weekends ago. Last weekend was still unable to solve it and was getting kind of frustrated... especially since construction time is limited to weekends and actually building this thing isn't nearly as interesting to me as starting work on the software/API.

I'd ordered a 3.3V/5V regulated breadboard power supply from sparkfun and a 5V/1A wall wart. After a couple of minutes of operation, the circuit would drop to 1.9V. Did some checking and found out that a heatsink on the thermal regulator could be applied, so we tried and got the lifetime up to 20 minutes. When I tried rewiring the lasers to share a parallel circuit to the power supply (like how I'd planned on rigging them up when it was time to deploy), the fsckers immediately started dropping voltage to 1.9 again.

Last night, we played a hunch and replaced the voltage regulator with a new one, and lo and behold, the lasers ran for 2 hours with nary a hiccup. We'd also swapped out the 22 gauge solid wire for 18 gauge threaded speaker wire, and hooked up each laser to a plug that could fit on the bread board. The end result is that all this can nicely be transferred to a PCB and mounted fairly easily. We also ended up replacing the 5V wall wart with a selectable voltage wall wart set to 7.5V... it just wasn't delivering the current at 5V for some reason.

On the actual acrylic side of things, I swung by Home Depot and picked up some 1x1x36 molding pieces, spray painted 3 sides satin black, and cut them down to size (along with a 45 degree angle on the corner) in order to use them as a safety rail for the lasers. The plan for calibration will be to use the modelling clay idea abratrarious suggested, and just glue the fsckers in place.

End result, the table looks more and more like some middle school shop project, but meh... that's what prototypes do.

Also started to notice that some of the superglued acrylic pieces are falling off. it's possible that I might end up having to just yank them entirely and bolt the table together. I think I see how this can be done without a problem now. I superglued the guard rails on to the acrylic, and we'll see how long those hold.

For the support, I'm thinking about just hacking together a dorm room table (some plywood, metal pipe, and metal fasteners), but instead of trying to cut a hole in the plywood, just flip the table upside down so the acrylic will be resting on the table's feet.

Finally, also worth mentioning the IR filter on the webcam. The webcam is a Logitech Quickcam for Notebooks, and it turns out that after you've remove the IR filter it's unnecessary to put your ambient light filter in the same spot. I was able to refocus the camera, and drop the little square of floppy disk material down into the lens well without having to remove it's assembly and wedge it into the other side.

The plan is for laser calibration in the clay on Wednesday (holiday), and maybe take a stab at building the support system. After that, it'll be testing the effectiveness of the camera to see light blobs, and then finally figuring out what to do about project. Was still considering the fresnel thing, but it turns out that it's hard to find a 15" LCD on a shelf these days... will probably start scouring used comp stores around here to see what they got.

Minus the PC and the aggravation so far invested, project is still under $200 for materials, if the fresnel thing works, could probably beat $500 for the total.

Wednesday, November 4, 2009

massive software design fail and why a $1.2T health care bill is doomed to the same thing

I found out about the existence of this project when the company I work for was tasked to do some clean-up work on the training videos (note: the opinions expressed here are mine and mine alone and not those of my employer). For some background on AHLTA, I'd point you to this article. While the author wants to pin the blame on the "Bush administration", it's really the same story that's been played out time and time again in the quixotic quest to develop an electronic medical records system for a government run health care system (the military). The "Obama administration" is just as likely to launch the same failures (if not larger ones due to the increase in willingness to expand federal spending by adding to the deficit and creating more bureaucracies).

Today it was finally announced that the Army is halting deployment of the system, and my guess is that it's going to be scrapped.

Bottom line: around $30 Billion and almost 5 years for something that has absolutely zero utility, is completely user hostile, and cannot be re-used in any way. The money and time spent on the project are just gone. Poof. Game over, man. Game over.

The reason this boondoggle got to be so bad? Each time someone stepped up and said, "This is crap and it doesn't do what it's supposed to do" they were stamped back down by superiors who were afraid of how it would look if they admitted defeat and wrote off the money already spent on the project. Yeah, I'd be pissed off (as a taxpayer) if they had canceled the project in Sept 2008 when the price tag was $20 billion... but at least they would have saved a year and $10 billion off the effort.

But here's the problem. Technically, nothing went wrong with the development process of this system. Studies were done, requirements were gathered, development schedules were created, and contract officers signed off that the requirements were met. The contractors did exactly what they were told to do and produced exactly the software that the Army asked for.

Not the software they needed.

This is a $30B illustration of the absolute failure of old design philisophies, specifically the ones that rely on the end user to know both what their requirements are and what the language should be to describe them. Agile development techniques have cropped up in the private sector over the past decade and have found success in smaller businesses (or divisions inside of larger organizations) where the developers can maintain contact with the end users and subject matter experts to address design issues. Requirements-based development, however, forces developers to guess on design issues, or worse, leave the question to be hashed by a committee of people who won't be using the system, don't know the subject matter, and commonly don't even use the same terminology for the various parts of the system .

Because government contracts (and large enterprise projects) are so large and so much money is at stake, the decision to use agile development techniques is usually discounted. The bias seems to be, "Well, that's not the method we used to develop this other $10 billion project" and completely ignores the fact that that other project also failed to deliver software that the users truly need and has only succeeded because employees were ordered to use it and work around the problems.... if the project is lucky and isn't scrapped entirely after launch.

AHLTA isn't the first example of this, either. The FBI was forced to give up on a $10 Billion project to improve their information infrastructure. The IRS blew $20B. Even the concept of electronic medical records itself isn't new... it's been attempted many times under many different initiatives by various groups in the DoD since at least the 1980's.

The endemic problem here isn't the contractors, it's the fact that there is a bureaucracy that's left in charge of the project. There is no single person with the power to say, "This is fail. Try again," until the project is completed and the money is spent. Both structure of the contract -- and in the case of government project, laws -- prevent shifting the focus of software development from simply implementing a laundry list of pre-determined features into a user-needs oriented development model. That's why I believe it's a fallacy to pin it on any "administration". It's the mid-level officials who keep the same jobs between administrations that are jacking things up and sheltered from the consequences of failure to act.

What I find truly scary about all this is that we now have a bill sitting in Congress that allocates $1.2 Trillion for spending on health care for the public. A large portion of that money is meant to fund a switch to EMR for the public and its premise is that we can reduce the cost of health care if we can reduce the cost of managing health care information.

If we can't get this right for just dental coverage of 3 million people in the Army, how in the hell is this method supposed to work for 330 million across 50 states? Just at the IT level... forget the adminstrative stuff.