Tag: Engineering

KiCAD libraries

I’ve been using KiCAD for my schematic capture and layout tasks for about a year now, and I find it to be the best free tool that I’ve seen. In the interest of making it easier to share my projects, I’ve put all of my KiCAD libraries on github: https://github.com/mogar/KiCAD_libs

I tend to organize my libraries in pairs. One library of symbols and one library of corresponding modules. That way I know where to find the footprint I’m looking for.

I started out using a library that had been created from the SparkFun Eagle libraries. This has worked pretty well and has a lot of common components, but footprints are often messed up. I’ve been fixing them as I run into issues, but definitely check all footprints from the library before you use it.

The other libraries have parts that I haven’t found in the SparkFun library. Those libraries are better maintained, but I still suggest you double check everything before using any of those parts.

Rise: Support Your Health

I’ve been working hard for the past six months designing Rise, a new quantified self health tracker. It’s an accelerometer-powered device that sits on a person’s leg and helps them keep track of how much they’re sitting. Sitting, and being generally sedentary, have been linked to a whole host of health problems. Sitting too much can lead to blood clots in the legs in the short term, and diabetes and increased risk of heart disease in the long run.

The health problems that sitting causes are pretty simple to avoid: just sit less. Even getting up for just a few minutes every hour can have a marked impact on the health of the average office worker. So if it’s so easy to solve the sitting problem, then why did I spend so much time working on it?

It’s because sitting is insidious. People don’t notice how much they sit, and when they do notice it’s often because health problems are already starting to crop up. Rise, our sit tracker, will not only track how long a person has been sitting but send periodic alerts to let the wearer know its time to stand up and walk around for a bit. We’re building apps for both Android and iOS so that this is accessible to as many people as possible.

It’s been a fun project to work on, and a great extension of the research that I did when I got my Master’s. We’ve launched an IndieGoGo crowdfunding campaign to help turn the prototypes into final products. I’m excited to see how the campaign goes, and to see my work actually get out into the world and help some people. If you’re interested, you can check it out here.

In praise of requirement shift

One of the complaints that I’ve heard most often from engineers in various industries is about the requirements shift that often happens midway through a project. It’s a common refrain: “I had almost finished the project, and then my boss told me to do everything in a totally different way. Why can’t they just make up their minds?”

I’ve only ever worked at small companies where the design decisions were fairly transparent. With only two levels between me and the CEO, it was always pretty obvious why any change was being made. In general I haven’t had to deal with this issue very much in my career, but up to now I’ve been sympathetic to those people who have. A recent project that I worked on gave me some insight into requirement shift from a manager’s perspective, and I now have a lot more respect for projects that experience a lot of shift and upheaval.

A few weeks ago I decided to build myself a frisbot. My idea was to mount some photo-sensors a two wheeled chassis (each wheel would be a frisbee, hence “frisbot”). The bot would then be able to follow a light around. I had a good idea of how I wanted to design the electronics (finally using that MSP430 launchpad I got a while ago), but I wasn’t sure how I wanted to build the chassis. I was thinking a simple plank of wood with the various components mounted to it, but I hadn’t thought much farther than that. I convinced my friend Jared, who has an irrepressible drafting habit, to help me out with the mechanical design.

The two of us sat down and I showed him some videos of other frisbots, and showed him the different electrical components that had to fit on the chassis and we talked a bit about the design. Then we split up and got to work, I wrestled with the MSP430 DAC and he started drafting out the chassis design. Since I hadn’t really done much to spec out the chassis, Jared started asking a few questions about the chassis.

Him: How do you want the motors attached? Can we just mount them on wooden plates perpendicular to the base?

Me: Sure that works. Oh, but can you make them easy to remove so that I can replace the motors later if I want? And add some space to allow bigger motors in the future?

Later

Jared: Ok, the motors plates are done. And you were going to put the dev board here? (points to his design)

Me: Ya, that’s what I was thinking. Oh, wait! I might want to use a different microcontroller later, can you make the space for it larger?

We went through a few rounds of questions like this. He would ask for clarification, and I’d suddenly realize that we could do something slightly differently and make for a better or more flexible design. Admittedly, if I’d spec’d the thing out beforehand this probably would have gone a lot more smoothly. Jared, nice guy that he is, didn’t punch me in the face even after I asked him to change things for the fourth time.

The main point of this story is that the reason for requirement shift is because you don’t know everything you need to do until you’re actually working on it. That’s when a lot of questions get answered. Even if I had written down a full specification for the chassis beforehand, some of Jared’s questions spurred me to think of things that I wouldn’t have even considered beforehand, like adding a crossbrace to the motor plate. The act of making it changed what I thought was best and informed a lot of the design decisions.

Generalizing from this one experience, it seems that requirement shift on a project means you’re doing something new. If you’ve done it before, you know how to do it and don’t have to worry about changing the design halfway through. But if you’ve done it before, then it’s boring. One of the main reasons I like to design and build things is that it’s an educational and inspiring experience. If I only ever build things that I know how to make, then I’m not learning anything or doing interesting things. Even something that was once interesting can become mundane and boring after you’ve done it enough. Having to rethink a design halfway through is actually why I do what I do.

I think one of the main reasons that people complain about requirement shift so much is that in larger companies, the engineers are often isolated from many design decisions. They’re so removed from the design process that they don’t get to experience the wonder of discovery that happens when you realize you have to do something different. It’s not a problem with requirement shift, it’s a problem with openness in the company. This may be why startups don’t have a problem with it. Everyone in the startup gets to experience the fun parts of the design, so they don’t balk when things change.

If you don’t have requirements shift, you’re doing something easy and boring.

Engineers vs Pretengineers

I’m an engineer, and I have been one since the University of Washington bestowed upon me a bachelor’s degree in electrical engineering. I wonder, though, if my graduation was the day that I can point to and say “on that day I became an engineer”. Is engineer a status that is defined by some outside body, or by one’s actions and thought patterns?

Every once in a while I’ll teach a workshop or work a shift at Metrix Create:Space. Metrix is a hackerspace where people can come and build things, and the staff there are expected to help people build things. Since Metrix is the kind of place that people like me want to hang out in, it can be hard to tell if an employee is actually working or if they’re just there to build their own stuff. To fix that problem, staff at Metrix who are on the clock wear labcoats.

These labcoats have a name and title embroidered on them. Most of the labcoats have the title of “pretengineer”. The labcoats for people like me, who are accredited by some institution, have the the title “actual engineer”. Pretengineers and Actual Engineers don’t do different jobs at Metrix, and most Pretengineers don’t know significantly less about a subject than the Actual Engineers.

Some of the Pretengineers at Metrix make more things and have a much more technological mindset than some of the Actual Engineers that I know. What it comes down to is, for a place like Metrix there’s no difference between the two. Maybe an expectation of quality, but that expectation is met by everyone who works here, not just the people who have a degree in engineering.

I don’t think that being an engineer has anything to do with what some school or other has decreed you know. It seems to be more of an attitude towards problems. If the first thing you do when you see a problem is think about how to solve it with math and technology, then you are an engineer. It doesn’t even matter how much math or technology you know about, or how much skill you have. If you are willing to try the math and solve problems with technology and experiment until you figure out how to do it, then you’ll eventually learn everything that you need to know.

All a degree in engineering is good for is showing that you have some minimum level of skill, not that you’re an engineer in the first place. This isn’t necessarily a bad thing. In projects upon which lives depend, like bridges or pacemakers, you want to be sure that the person designing it has made (and learned from) all their mistakes already. Having some kind of standards body that recognizes people who are qualified to work on safety critical projects is all well and good. People who have followed other routes to excellence may not be able to be qualified by that standards body, even if they are already quite skilled.

My concern is that having such a standards body, or even having the hoop of “college graduate”, will push people who are actually already quite accomplished engineers away from the field. And that’s a shame. There are many valid ways of solving problems, but thinking that someone (yourself or someone else) isn’t capable of using one just because of some standards organization hasn’t approved them is severely limiting.

Open source movements, software and hardware both, are doing great things to make engineering something that everyone is allowed to do. The rise of maker and hacker culture is encouraging everyone to become engineers, whether they realize it or not. We’re moving more and more towards a world where everyone uses the techniques of engineering. My hope is that people start realizing this, and claiming the title of engineer with pride.

I’m an engineer. When I set out to solve a problem, I start by quantifying it and applying my technological tools to it. What do you do?