A Spin on Balance – An Intern’s Perspective

February 3rd, 2012

For the past month, the team at Goddard Tech has let me probe around and get a feel for the world of design consulting. They taught me everything from creating SolidWorks models of concepts to using a Dremel to piece together a prototype. (I even helped out with a few different projects!) But the most valuable piece I’ve discovered is you can’t design reality (or imagination) without balance. Humor with productivity, details with the big picture, and engineering with art.

I might be stating the obvious, but it’s not always been the case.

For years, companies across industries have compartmentalized their employees. Engineers come up with mechanisms in one room at the same time that industrial designers are ensuring the product will sell. Then, the leaders of each come together to hatch out a union. The result is a well-that’s-not-quite-what-we-had-in-mind scenario that probably cost the company more time and money than it should have.

Goddard tech is a unique design firm because they’ve mastered the intersection of mechanical engineering and industrial design. The desks of the ID guys are scattered between the engineers’ and everyone can see what others are working on over their cubicle (which comes in handy if you need to ask someone for a caliper or want to share a humorous article). If you ever visit Goddard, you’ll see their orange walls, overflowing dry-erase boards, and people CAD-ing to the classic rock from Phil’s speakers. They’ve got an awesome dynamic which reflects on their work.

The practical skills will be useful when I return to another MIT semester, but getting to know the Goddard team made the experience.

DSC_0339

To Prototype, or Not to Prototype? – Phil Bussone

February 1st, 2012

Should I make a prototype?  The answer is almost always yes.  I am a little biased seeing that I have been making prototypes for clients for almost 20 years, but I can’t stress how valuable having a prototype is.  Whether it is a rendering of a new product color scheme (a paper prototype) or a fully working demonstration model the value is enormous.  Being able to evaluate a design or just piece of a design before going to production will help smooth out the design process and will help one save from making costly mistakes.  People will be able to make good decisions as to looks, function and performance from using a prototype.  This will make for a better product in the long run.

The article will help you help you understand the true value of prototyping and gives some great tips on how to implement prototyping!

http://zone.ni.com/devzone/cda/tut/p/id/8752

 

 

Diversity Derives Pools of Perspective – Justin McCarthy

January 20th, 2012

Justin’s response to http://productdesignhub.com/2010/01/putting-innovation-at-the-heart-of-your-business/ -

Just as diversity keeps an ecosystem healthy, the strength of brainstorming comes from each new perspective added to the group.  Each member leverages their expertise to help inform and inspire the other members, from sheet metal fabrication right through celebrating the intricacies of the end user.  A friendly environment that welcomes insight and rewards creativity will produce the largest variety of ideas. From that mass of ideas, not only a solution to the current problem, but new directions and new products can be identified.  From my experience every product, every environment is linked in some way, input from every sector is always valid and will always add to the strength of the effort.

Fallacies of FEA, Speculation on Problem Formulation – Vipul Negi

January 13th, 2012

Vipul Negi Visual Data

As a Mechanical Engineer ,and having done quite a few recent projects with a lot of FEA needed, I would like to shed some light on common fallacies while using this tool.

A result in FEA is only as good as the problem formulation. Select an inaccurate loading or constraints, improper mesh size and material type and your results will be way off. To compound the problem most of the times you don’t have empirical data to compare it against and so the wrong analysis result starts guiding your design.
Everyone knows how that ends up.

Here at Goddard we do a lot of Finite Element Analysis and we have engineers that have quite a few years experience setting up accurate parameters for the analysis to get the closest approximation while balancing criticality of the analysis result versus computational time.

The link below sheds light on the topics I touched above.

http://machinedesign.com/BDE/cadcam/bdecad3/bdecad3_5.html

Analysis aside its interesting how the author underlines the need of the person doing a Finite Element Analysis to have a formal training in understanding Finite Element Methods as well. Doing an FEA is much more than clicking buttons on the screen.

-Vipul Negi, Mechanical Engineer at Goddard Technologies

Product Specs – Do’s & Dont’s

January 5th, 2012

 

 

As a Product Development Engineer, I see product specs handled many different ways at different companies. When done right, product specs help coalesce and narrow down product features such that design, testing, and manufacturing ramp-up can flow as efficiently as possible. These specifications will Ideally culminate in the delivery of the right product for the right market at the right time. I have also seen Product Specs used incorrectly, resulting in significantly wasted effort, misleading information, or irreconcilable disconnects between “required” features and “required” Cost of Goods or retail-price. Whenever the topic of properly writing specifications (and functional specs in particular)comes up, I am always reminded of an old but timeless article written in 4 parts by Joel Spolsky of Fog Creek Software:

Part 1:  http://www.joelonsoftware.com/articles/fog0000000036.html

Part 2:  http://www.joelonsoftware.com/articles/fog0000000035.html

Part 3:  http://www.joelonsoftware.com/articles/fog0000000034.html

Part 4:  http://www.joelonsoftware.com/articles/fog0000000033.html

Even though Joel wrote the article with software development in mind, it also very much applies to device design and development as well. I always find it helpful to read it through Joel’s old article every now and again to remind me exactly why I invest the effort in writing clear and efficient product specs in the first place.

- Orlando Soto