Wednesday, August 15, 2012

Monitoring the Charles River

Sophomore Year

My Sensor Buoy Adventures

 

Every Civil and Environmental Engineering major at MIT takes a lab class their second semester sophomore year loosely titled "1.102: Civil and Environmental Engineering Design II". A more descriptive title, although less likely to attract freshman to the major, would be "1.102: A Crash Course in Everything Course 6".

The class begins with a combination of lectures and labs meant to teach students circuit design and one rather obscure computer program (the name of which I have since forgotten. That kind of obscure). The effectiveness of this teaching method is then tested in the last month by throwing students into a fabrication project which ideally fuses computer, electrical, and structural engineering into a neat, testable package.

When I took the class I chose, along with three other people, to construct a sensor buoy for deployment in the handy river near campus. Of course, the final destination of the buoy was nowhere near as interesting as the capabilities we wanted to implement: thermistors, an anemometer, and wireless data collection so that information could be collected and analyzed in real time.

Spoiler alert: we were getting only a little in over our heads.

But at least we could be in over our heads systematically. The project breakdown was fairly simple:

The Structural Component

We put two people on design and all four on implementation.

The materials were fairly intuitive: PVC pipe framing with foam floatation devices surrounding the joints which contacted the water. The electronics were housed in a large, 6 in. PVC pipe set in the center of the structure.

I drafted some initial sketches of the design using some old sketch-up program I have long forgotten. Back in sophomore year, I was of the "do it reasonably well so it works" project mindset, and cared more about getting the relevant structural aspects documented quickly than making that documentation look pretty.

Hence the following, rather primitive diagrams:
Side view of buoy structure: pink pieces are foam blocks and the grey are PVC piles. Black components represent sensor locations.




Top view of buoy structure



As simplistic as they are, the diagrams served their purpose. Putting the PVC structure together was a fairly simple task. Then we began working with the foam.

The original idea was to cast foam blocks around the joints of the PVC to seal them from the water (more an extra measure--we were waterproofing them as well). However, our attempts to work with hand-poured polyurethane foam involved hastily-designed aluminum foil molds (engineering on the fly!), poor approximations of ratios, early weekend mornings (which may have significantly contributed to the first two), and a nice large stain on the concrete floor of the basement undergraduate lab.

We tried to clean that last one up.

And then we switched to pink foam blocks, cut everything to size, zip-tied it around the joints, and were much happier for it.

The Electrical Component

I have to say, this project began with good intentions. We were rather systematic about it; in the weeks we were wrestling with the exquisite mess pourable foam can make, we were also drafting and soldering a circuit to link the sensors to a microcomputer.

The microcomputer was a bit of a fanciful addition on our part. Apparently the challenge of combining a host of sensors with wireless data collection was not enough for this project; we also needed to toy with a technology that none of us, and none of the professors, understood well.

The microcomputer was found and purchased by something resembling group consensus, steeped in ignorance of what out of its capabilities we actually needed. Of course, the brilliant red board seemed harmless enough at first. When we connected all of the sensors and wireless chips to the microcomputer through our fabricated circuit board, we measured reasonable voltage/current readings and generally saw things run smoothly.

The circuit board was a little thing I found lying in a pile of discarded electronics at MITERs, the student shop of MIT. The rest of the circuit was similarly pieced together from things lying around; true to the MIT spirit, I worked on it mainly on nights and weekends when the student lab was not open.

It was drafted in Eagle, but again the diagram is a painful reminder of my inadequate grasp of circuitry (and, for that matter, Eagle). So you must contend yourself with this snapshot of the final product:

The final circuit board (digital compass for buoy orientation is the small chip on the left). Every component that looks like it is missing was actually housed in a sensor or a microcomputer.








A better picture. The thing with the antenna is the wireless transmitter. The red board is the microcomputer, and the blue-topped box is (of course) the battery.

A couple of tests confirmed that the circuit would route and moderate current appropriately, that the digital compass was orienting itself correctly, that the sensors were reading what we expected when connected to a voltmeter, that the battery could survive for the length of our planned deployment, and that the microcomputer could read voltage from the circuit.

With a week to go, the structure and electrical components were finished. My group had one question left to answer: could the microcomputer interpret the sensor voltage inputs as anything useful?

The Computer Science Component

I feel compelled to remind you (and myself) that my group had such good, systematic intentions at the start of this project. We had divided up the work: I nabbed the electronics, two others designed the structure, and one final member was put in charge of programming the microcomputer. Two out of three were completed without any major roadblocks.

One more task to go. One more week.

Thus it was about time for everything to effectively go to hell.

It turned out that the microcomputer could only be coded with C++. None of us, not even the person who had claimed some rudimentary knowledge, really knew C++. The same went for our instructors. Nor could we even figure out why the microcomputer refused to compile any sort of code or open-sourced program.

So, with a week left, it was up to myself and the final member to get this thing working. We spent endless nights in the student lab, alternating between attempting to learn C++ and taking a trial-and-error approach to the software.

We even asked a computer science major for help as a final, desperate attempt to pull things together. I have memories of late nights under fluorescent lights, tired and trying to keep focused on the C++ documentation glaring at me from my computer screen while the computer science major and my teammate argue over some piece of our thermistor code. Each time we wanted to test the software, we had to compile it on a flash drive and then transfer it to the microcomputer. It was a tedious method for debugging.

Needless to say, when the week was spent so were we. And the software was not ready for the buoy's deployment.

Deployment


Apparently the missing third of our project was not really a concern for the instructors. We were given time and resources to deploy it on the river anyway, despite its lack of data collection capabilities.


The buoy, in all of its nonfunctional glory.

Now imagine this with a computer somewhere on land, maybe 20 yards away, collecting data of calm, cool waters and mildly windy days. It was hard not to feel mildly proud of the two-thirds my group had accomplished. Alas, it was equally hard to ignore the third we had completely failed to produce.

This was one of the first times I had significantly failed to meet spec for a project, and it left quite an impression. Which is important in itself; better to get these lessons early on in my engineering education than later in my engineering career. 

And it turns out that is half the point of these overly ambitious student projects. So, as a final note, I give you...


Lessons Learned

  • Abandon hope of maintaining a systematic approach to a project. Be flexible, be prepared to be flexible, and deal with it.
  • Group members have lives outside of a project, even if I don't. Again, deal with it.
  • Don't allocate only one week to learn C++.
  • Pourable liquid foam requires precision to use properly.
  • Aluminum foil does not make an ideal molding material.
  • Student shops open at all odd hours are wonderful resources.
  • My best thinking does not occur at 3 am.
  • There isn't much that can get polyurethane off of concrete.


No comments:

Post a Comment