Skip to main content

Big Picture vs. Details

So, $coworker_who_thinks_I_am_part_ninja and I think in different ways. I try to make my profiles as widely-applicable as possible, so they are robust enough to withstand insane changes. He makes his profiles as quickly as possible, so dev time is short.

Now, both are fine ways to go about our work. Lower dev time costs the customer a little less, while a robust profile will survive whatever the customer throws at it (and I have seen some Crazy Shit™).

However, the result of this is that I tend to analyze the system and account for variations, while he goes for the quick fix. My profiles take twice the dev time as his, but they have never failed in the field.

I am currently working on a 3D box-volume project, using two cameras to measure the three dimensions of a regular cardboard box. I have a small desk, so I am using a small (5" X 2" X 3") box as my initial test article, but the system may or may not be used by a large package-moving company to pack their trucks as tightly as possible, so it will eventually have to deal with a wide range of boxes. I am currently having trouble finding one edge, because there is not enough contrast there. I asked $coworker for ideas, and his suggestion was to have an array of tools, each triggering on a different type of box.

This is a problem for me for several reasons:

  1. I like the product to be apathy-proof, because the people who run it are not paid enough to care, so the less I ask the operator to do, the less chance there is that they will fuck with something, break it, and cost the customer both a service call from us and production.

  2. I have a weakness for elegant solutions. I could use a bunch of similar tools, but I would rather come up with a clever way to do it all (and change the baby) with one set of tools. (See my post about J. Random Hacker for the rationale behind this)

  3. His solution would break my intricately-interleaved tools, with one tool positioning another two, which combine in a fourth tool to give a fifth the necessary position and Region Of Interest to get the accuracy I want.

  4. His solution, because it would break my dynamic one, will only work on boxes close to the size of my test article, and will fail outside that narrow range.

The issue comes down to the fact that he is a detail-oriented person who focuses on finishing projects for the sake of them being done, while I am a big-picture hacker who focuses on beautiful, orderly, flexible, robust products for the sake of elegance and much less so on just getting the project out the door.

PS: I handwrote this post, so if you see weird characters, let me know. I am still working out which character sets I need to have trained, and some characters still overlap.


August 21 2008, 05:22:07

From Andreas:
Hi, I used to work at a VGR company, so here's a quick idea that we used for situations like this - it may or may not apply to your particular application, though:
Depending on the edge that's causing issues, simply mount a bright area-light (or wide-angle spotlight) off to the side to create a stronger contrast for the cameras. I've seen applications with lights mounted in 3 or 4 different places, triggered sequentially (with camera captures for each light) - this is incredibly robust, will handle all kinds of box rotations and box dimensions, but requires that there's enough space for all the equipment, enough budget, enough time for all the imaging, and a way to control an I/O port for the lights (RS232 works wonders).

August 21 2008, 12:28:52

Ah, thanks! Will make the suggestion to the guy who is taking the project from me (tomorrow is my last day for this year).