Bench Talk

I try not to be a snob. Early on in my engineering career, I was taken down a peg or two after graduation. I had this shiny new degree I was ready to try out, but engineering is a lot more than academic knowledge. After a few months of working, I realized that there was a large amount that I did not know. All the subjects I took were preparing me to be an engineer. But you cannot discount the learning associated with doing.

Neil Armstrong’s favorite quote was "Science is about what is, engineering is about what can be.” STEM, and now STEAM (Science, Technology, Engineering, Art, and Mathematics) promote these areas for growth. Some might consider the “Art” in STEAM to be out of place, but I disagree. Engineers need cross-pollination, and have you seen some of the incredible art using open source technology?

Let’s face it; we’ve all tried to use the wrong tool for the job at hand at least once in our lives. Using a hammer on screws comes to mind as the most common misuse of tools and technology. I will admit it, guilty as charged. Picking the right Open Source Hardware tools and platforms is similar to the picking the right hand tool from our toolbox. Though there is typically enough crossover of functionality between the different types of tools, some are better suited for certain tasks than others. With increasingly more variety of affordable hardware tools coming to market, many makers are starting to ask, “What’s the right tool for the job?”

I recently commented to a colleague that engineers either learn by “letting the smoke out” of something (breaking it) or they can learn vicariously through another’s mistakes, if the mistake is catastrophic enough. I don’t have a lot of these, but I have noticed that engineering horror stories are effective training tools and often funny.

Throughout human history failure has been a bittersweet fact of life, and engineering is not exempt from this truth. Despite our best efforts (and sometimes, because of the lack thereof), engineering failures occur. The aforementioned examples are just some of the most highly publicized engineering disasters of the last 75 years. Sometimes, as we push the envelope in pursuit of success, things go horribly wrong. However, engineers should never use the reasons of those failures as an excuse. Instead, a failure should be viewed as a call to action, which brings with it the necessity to keep pursuing the root cause(s) of the failure. By doing this, we expand our knowledge and can reduce the likelihood of another disaster occurring in our future endeavors.

For those who don’t know, “24 Hours at Le Mans” is the oldest active sports car race in endurance racing. Think of it as the ultimate test lab for advanced technology. And there’s no trick to that name, this year’s race starts June 14th, 15:00 CEST (9:00am EST / 8:00am CST) and ends 15:00 CEST on June 15th. Driver, Crew and vehicle need to be at the top of their game to compete in this grueling test of racing and engineering.

I got to the end of my last blog and found myself so excited about the possibilities of Radio Frequency Identification that I could not help but sit down and do some thermal engineering to satiate my desire for some math and physics, the foundations of engineering.

The first robots I recall ever interacting with when I was young were Transformers. I suppose, if you were being REALLY generous, you could refer to them as semi-educational toys since each was a mini-puzzle that only kids younger than 13 could figure out. In fact, if I were this clever at 8-years-old, I might have convinced my parents to want to buy me more. But then, all I would have to show for it would be a box full of forgotten plastic robots that transformed into cars I could now sell on eBay. But there was a different group of transforming robots that I wish I had discovered in my high school days. Instead of buying them, you built them with a group of your peers. Instead of transforming into cars, they would transform your life.

Awhile back I was walking past the door to the lab where I work and noticed that there was a meeting going on to which I had not been invited. I guess they assumed the sophomore-level undergrad did not have much to contribute. It’s not that they would be wrong, but still it’s nice to be invited. As I walked into the room I noticed that I did not recognize one of the people, and he had a distinct accent. I went on to learn that he was Spanish, but is a professor at Aalborg University in Denmark, both of which might account for his accent. He was giving a presentation on Smart Grids, and since I am helping out with my professor’s Smart Grid research I figured I would stay.

When designing large, complex products the value of the principles and practices systems engineering is quite apparent. But what about when designing custom homebrewed electronics, are systems engineering practices valuable or overkill?