I have decided that I am going to hold off on any further SIFF blog entries until the end of the festival, unless absolutely necessary. At the end I will try and do some sort of SIFF 2005 retrospective with reviews, pictures, etc. Until then, back to fun hackery.
Woke up this morning at a loss for what I could plan for the afternoon’s ROV build meeting. The last few build meetings have been “light” on the building, as we have been waiting on a number of parts to arrive. The meetings have been productive in terms of firming up the ROV design and doing fundraising. Two of the contacts made through cold calling people in the phonebook have really paid off. Novaray robotics has donated $2000 worth of 12 conductor neutral buoyancy cable and a very nice pressure housing that will serve as the camera/electronics box. Novaray in turn introduced me to a company called Seal Technologies. The have a very nicely equiped computer controlled machine shop where they can make just about anything (they currently are turning out ultra high precision parts for laser systems). Not only have they offered to do free machining for us (they are already doing some modifications on the pressure housing), but the owner has offered to teach a “machining bootcamp” for the kids this summer. Anyways, back to being at a loss. I went out to the mailbox and found a few pleasant surprises (as well as the usual bills and junkmail) waiting for me. The LED clusters (36 white LEDS on each board) that I ordered for the ROV had arrived, as well as an OBDII reader for the car.
I brought the LED clusters to school and Kevin and I proceded to “pot” them in some clear glass candy dishes using acrylic casting resin. The resin sets totally clear (unlike most epoxies) and without bubbles. The only real downsides that I have observed is the stuff stinks to high heaven and takes several hours to cure to a point where it has much mechanical strength. We ended up using up maybe a third of the resin. We may use it to seal some cable passthroughs or fill some of the electronics comparments with it entirely, so I will probably be taking a trip to Michaels to pick up some more of the stuff.
While waiting for the acrylic to set, Kevin and I checked out the documentation for the 2003 “edubot” controller that we will be using as the brains of the ROV. We originally intended to use a FRC controller, but it is too big to fit in the pressure housing, so we scrounged around and came up with this instead. It is much smaller, but should have enough IO and processing ability for our uses. After googling around for a while, we managed to find documentation for it hidden away in a disused corner of the Innovation First site. Turns out that the controller is more or less a basic stamp. The last time I did any serious programming in basic was probably about 1987, so lets just say I am a little rusty. I aim to try and get some test code running on the controller sometime tomorrow.
After the meeting, I headed over to Vetco and picked up the lamp socket connectors used by the LED clusters. I also picked up some banana probes and alligator clips. While ringing up my purchases, I noticed a solitary CCD camera sitting in the back of the display case near the register. I checked out the spec sheet and they were pretty respectible. Most importantly, it didn’t have a ring of lights around the camera, as almost every “security camera” model seems to these days. Given that the camera is going to be behind glass in the pressure housing, any lighting coming for the camera itself just results in a hell of a reflection! Anyways, I added the camera to the pile and headed home with my wares.
Once home, I tested the camera out and found it to produce a very clear picture. Color accuracy, resolution, noise levels all seem much better than the SWANN security camera that I purchased prior to Atlanta. As far as I can tell, the only way in which the SWANN camera beats this one out is in its ability to use a wide angle lens. I haven’t measured the viewing angle on this one yet, but just eyeballing it I would say it has around a 40 degree FOV. I think we will use the SWANN for general navigation and have this one focused on the near field immediately in front of the ROV. Of course the true measure of these cameras will be how good an image they can provide using only the illumination provided by the LED clusters.
While waiting for it to get dark (so that I could test the cameras using only the LEDS), I went out to the car and installed the OBDII reader that arrived in today’s mail. For those not in the know, OBDII is a government mandated interface to your car’s ECU (Engine Computer Unit?). It can be found in pretty much all cars manufactured since 1996 (except for a few that run newer protocols). By hooking up a handheld reader device or computer interface to the OBDII port (which by mandate has to be within a few feet of the steering wheel) you can gain access to a wealth of diagnostic information. While you can’t alter any of the engine computer’s settings, the information provided by the ECU is invaluable for tuning purposes, early troubleshooting of problems/breakdowns and can be used to create a “digital dashboard” as well as do neat stuff like intelligently track gas usage. Installation of the unit from ScanTool was a snap, although I am going to have to go back tomorrow and come up with a more permanent mounting solution for the interface box and a way to run the cables out of sight. The unit immediately powered up on connection to the OBDII port and started spitting out data when queried by the manufacturer’s program. OBDII is actually a query based protocol. You basically ask the car for a certain piece of data and it spits it back to you. Because of the slow cycle speed of OBDII (on the order of 3-4 hz if standard compliant), it isn’t really practical to monitor more than 7-8 values in realtime. What is really needed is a program that allows you to specify an update interval or relative importance value of some sort to the various parameter that can be monitored. So, for instance, I could measure engine RPMs and speed once a second, but only monitor oil temperature once a minute. All the programs that I have tried thus far let you specify which parameters to monitor, but query them all at equal intervals. The good news is that there is a lot of third party software available for this particular unit, and a lot of sourcecode as well. In particular, ProScan, Digimoto and PCMScan look promising. Unfortunately, they are all commercial and none of the freely available things that I have tried so far are nearly as advanced.
After a fairly unnecessary trip to a gas station (my tank was still pretty full, I just needed an excuse to try out the OBDII), I returned home and tested out the new camera with the lights. While not as good as in daylight, the camera still picks up quite a bit of detail and color information from an object placed 10+ feet away from the lights, so I think it is going to be a winner. With an additional LED cluster (or better focusing of the light coming from these ones) I think we will have just about an ideal set up. I just wish Vetco had another camera, as we have really been planning on having 3 cameras onboard.