Gas station without pumps

2014 January 18

Engineering Encounters Bridge Design Contest 2014

Filed under: Uncategorized — gasstationwithoutpumps @ 23:23
Tags: , , , , ,

Last year’s bridge design did not work well for the 2014 Engineering Encounters Bridge Design Contest (formerly the West Point Bridge Design Contest):

Bridge design costing about $169.9k in the 2013 contest.  Note: I've deliberately distorted the picture to make it difficult to blindly copy the design, as I had problems with middle-school students using my published designs to cheat on their homework.  The truss design I have here can be used as inspiration, but not copied directly.

Bridge design costing about $169.9k in the 2013 contest.

When I tried a similar design in the West Point Bridge Designer 2014, I couldn’t get the cost below about $172k, but a simpler design was cheaper:

$167.3k bridge design for West Point Bridge Designer 2014.

$167.3k bridge design for West Point Bridge Designer 2014.

This design is currently 12 of 41 in the open contest, so clearly one can do better. I don’t expect it to stay high on the leaderboard for long.  It would already be much worse than that on the consolidated board, since the top 10 on the open board only fall in the top 50 on the consolidated one.

I think that the contest would be more interesting to me if they had provided an API for testing bridges.  Then the challenge would be to write bridge optimization software that explored the design space much more thoroughly and tweaked the designs.  It might be possible to do that this year, as the source code is available from sourceforge.  I’m not interested enough in the optimization problem to try to interface to their Java code, but it might be a good way to make a college-level version of the Bridge Designer Contest.

Related articles

2013 September 3

My son’s first PC board

In Towards automatic measurement of conductivity of saline solution, I complained about not being able to use the KL25Z board, because my son was using it.  What he was doing with was building his first prototype for the light gloves project:

Here is his first PC board design, populated and mounted on the Freedom KL25Z board.  The 5cmx5cm board is a bit smaller than the KL25Z board is wide, so it only plugs in on one side (there is a screw acting as a spacer to keep it from being a cantilever).    He has not yet mounted the Bluetooth module.

Here is his first PC board design, populated and mounted on the Freedom KL25Z board. The 5cm×5cm board (the cheap size from Iteadstudio) is a bit smaller than the KL25Z board is wide, so it only plugs in on one side (there is a screw acting as a spacer to keep it from being a cantilever). He has not yet mounted the Bluetooth module.

The prototype board has many differences from the final design: no battery, no battery charger, no buck/boost regulator, no flash memory, no processor, screw terminals instead of jacks—even the LED driver chip is different, since the chip he plans to use is only available as a surface-mount device. But there is enough of the design here to start demoing and writing code.  They are hoping to keep the final board below 5cm×5cm, so as to get low PC board prices even in very small production runs.  That will mean all surface-mount parts, so I think I’ll have to get a hot-air rework tool so that they can assemble a prototype—I’ve been thinking that I might want one for myself to play with surface mount designs, so this isn’t really a hardship.

My son still owes me some money for buying him the PC board run, the screw terminals, the Bluetooth module and some heat-shrink tubing. It is a bit annoying that he isn’t old enough to get his own Visa card, so that he can do his shopping without me as an intermediary. (We’re not talking big bucks here—we’ve spent more on pizza for him when they work through dinner than they’ve spent on all parts combined.)

I’m pleased that he got his first PC board working on the first attempt—he did the design entirely on his own, though he did ask my advice about things like via sizes and how fat to make the wires. Since there can be moderately high currents for the LED driver, I recommended that he make the ground and power lines as fat as he could, and he decided to do a flood for each. The board looks quite nice:

The top view of the board with the screw terminal to be mounted on the top and sides, the header on the lower left, and the Bluetooth module on lower right.  The hole near the top right is for the screw that acts as a spacer.

The top view of the board with the screw terminal to be mounted on the top and sides, the header on the lower left, and the Bluetooth module on lower right. The hole near the top right is for the screw that acts as a spacer.


This is what the glove looks like with the five RGB LEDs lit up (I understand that the final design will have more LEDs—but the through-hole driver chip has limited pinout). They don’t have the user interface written yet, so the lights were set up by a quick-and-dirty Python script talking to the KL25Z board over a USB cable (which is also supplying power).


They have not implemented programmable flashing yet, but the pulse-width modulation (PWM) frequency is set very low here (much lower than what they intend to use in the final design), so that one gets a stroboscopic effect even with steady light settings, just from the PWM. That’s not my son in the picture, but the high-school student who started the project—my son has done most of the electronics and programming, but did not originate the idea.

The two teens spent a big chunk of the day wiring up the LEDs and writing a small test program, as they want to demo the glove tomorrow for the back-to-school event. It may also be an enticement for teens to join an Arduino/microcontroller club—look at the cool stuff you can learn to make!


Another view of the prototype light glove in action.

Once they got the demo working, they invited over a third member of the team to do some brainstorming about what else needs to be done (and how they’ll do it). It looks like they’ll be talking half the night.

Since it is clear that my son will be spending a lot of time on this engineering project this year, we decided to make it part of his official school work.  In addition to the engineering design work, he’ll also do some a paper for his econ course (on pricing the components and manufacturing, and setting a retail price for the gloves), and papers for a tech writing course.

His first tech writing assignment is to write up a description of the color space he decided to use for representation of colors in the program, and why he chose that color space out of the dozens available.  He spent a week thinking about color spaces anyway, before settling on a commonly chosen one—so writing up that reasoning for the other members of his team will be a good writing exercise.

2013 February 10

National Engineers’ Week

Filed under: Uncategorized — gasstationwithoutpumps @ 10:18
Tags: ,

Next week, 2013 Feb 17–23, is National Engineers’ Week.  (My apologies to the organizers, but I refuse to spell it without an apostrophe as they do.)

Thursday (2013 Feb 21) is Introduce a Girl to Engineering Day.

I’m not aware of anything that the Jack Baskin School of Engineering at UCSC is doing, but I’m just a faculty member, and we’re always the last to be told anything (and then generally in the form of “the deadline is tomorrow, drop everything and do it now!”). National Engineers’ Week seems to be organized mainly by international tech companies (heavy on the energy and transportation industries), and they’ve apparently not done much for involving universities in the program.

I don’t have anything planned for National Engineers’ Week myself, because I only found out about it a few minutes ago.

To be fair, I heard of it two years ago also and had similar grumbles about the lack of visibility.

2013 February 9

Becoming engineers

Filed under: Circuits course — gasstationwithoutpumps @ 20:23
Tags: , , , ,

In The Art of Becoming Yourself, Chad Hanson discussed the hard-to-measure cultural value of a university education.  I was particularly struck by his statement:

Educators spend a good deal of energy testing critical-thinking ability and, frankly, are frustrated with the results. One reason we have difficulty producing critical thinking is that we separate thinking from thinkers. We treat critical thinking as if it were a free-floating ability when, in fact, it is a function of oneself or one’s identity. Critical thinking is a way of positioning oneself toward a problem. For critical thinking to take place, students must first come to think of themselves as people who are willing to take a critical stance in relation to an issue.

This resonated with me because I’m trying to teach the bioengineering students in my circuits courses to “think like engineers“, but I had not thought of the problem in quite the way that Dr. Hanson put it.  My goal is not to have students “take a critical stance”, but to be able to solve problems that they have never seen before.

I’m really trying to make the students see themselves as engineers, rather than as students—to have them think of themselves as people who can look at a problem and decompose it into solvable subproblems, as people who are willing to explore possibilities without knowing that there is a correct answer in the back of the book, and as people who can design solutions.

I want them to think “let me look on the data sheet” and “let me measure that and see”, rather than asking “is this right?”

I want them to look at a breadboard that isn’t working, and start by checking each wire to see if it is consistent with the schematic, rather than just calling the TA or me over for help  (80% of the debugging I’ve done for students is pointing out that their wiring doesn’t match their schematic).

I want them to draw their own schematics, checking to make sure they know what each wire and component is for, not just copying and pasting someone else’s. I want them to check their schematics to be sure they haven’t shorted power and ground, and that every input and output is appropriately wired, not left dangling.

I want them to do quick sanity checks on every calculation or design decision, asking “is that consistent with what we know already?” and “are the units right?”

They’re all capable of doing these things, when told to, but they have not yet changed themselves to the point where they tell themselves these things without being nudged.

If they forget in a year how to compute the corner frequency of an RC filter, I’ll be only mildly disappointed—if they need it, they can look it up or rederive it in a few minutes.  But if they forget that they can rederive  formulas from a few simple principles, rather than having to memorize or look up solutions to every possible problem, I will have failed.  If they forget or don’t learn how to decompose problems into subproblems, or how to write a design report that can be understood by people who’ve not read any prior problem statement, then I will have failed.  If they forget to look at datasheets or to do consistency checks on their own work and that of their colleagues, I will have failed.

Dr. Hanson quotes Alexander Astin:

In his classic What Matters in College?, he concludes, “The student’s peer group is the single most potent source of influence on growth and development during the undergraduate years.” As educators, we assume that students enroll in our classes for the sake of the learning outcomes listed on our syllabi. The truth is that learning outcomes are actually a small part of the endeavor. The postsecondary ritual is a large and life-changing experience.

That suggests to me that it will take the students helping each other to make the change to thinking like engineers.  I can give them exercises and labs in which engineering thinking is valuable, and I can give them questions to ask themselves, but it may take the students asking each other these questions for the change in their ways of thinking to become part of who they are.

2013 January 30

Teaching engineering thinking

Yesterday I wrote

Maybe I should recommend some generic problem-solving books, like Polya’s How to Solve It, since it seems that the class has not been taught many problem-solving skills. I keep feeling that I’m teaching stuff that they should have had much earlier, but clearly haven’t, as if every teacher they’ve ever had has pushed off teaching the important stuff in order to cram in more factoids. There are times when I’m tempted to kick the can down the road myself, but these are all seniors, and it seems almost criminal to let them graduate as engineers without ever having been taught to think like engineers. I’m going to end up working them pretty hard, trying to get them up to speed in circuits, writing design reports, and how-to-think-like-an-engineer in just 7 more weeks.

I’ve been trying to pin down just what I mean by “how to think like an engineer”—something I’ll need to have at least some handle on before I can teach students how to do it.  I have a few vague ideas of what it means, but not anything crisp and clear enough to serve as a design guideline for planning my teaching.  Here are a few random thoughts:

  • Engineers pay attention to details.  It isn’t enough to have the right general idea—the execution has to be right also.
  • Engineering is about solving new problems, not memorizing solutions to old ones. It is better to have a few general principles that can be used over and over in different contexts than an encyclopedia full of formulas and protocols for every known situation.  If the problem has already been solved, it isn’t really an engineering problem.
  • Design is often about a tradeoff between conflicting goals, or between goals and constraints that limit what can be done.
  • Sanity checks are essential.  Every schematic, every wiring connection, every computation should be subjected to quick checks for consistency.  Some of the checks are easy: Does every 2-terminal component on the schematic have two connections to it? Is every pin on the chip accounted for—either wired up or labeled as not connected? Do the units for the computation match (ΩF=seconds, not Hz)? Does replacing the ammeter with a short-circuit change the expected behavior of the circuit?  …
  • Design is not a process of randomly trying things until something happens to work, but of carefully planning how things should behave.
    Don’t get me wrong—I’m not denying the role that chance and luck can play in engineering. There are occasional serendipitous events, where something works despite mistaken thinking, but that is rare. My first patent, the plucked-string algorithm that Alex Strong and I developed, resulted from just such a serendipity—Alex had been attempting to implement something and had mistakenly added an averaging of two adjacent samples. My main contribution was to figure out why that mistake produced much more interesting results than what he had originally set out to do.  But even with that initial serendipity, we spent a couple of years doing careful design—coming up with different software and hardware implementations for the plucked-string algorithm (which we called the Digitar algorithm, but is now more commonly called the Karplus-Strong algorithm).  I even took a  VLSI design course so that we could implement the algorithm as a custom chip—a course that shaped my career for the next 15 years.
  • Debugging is a process of thinking carefully about why the circuit, program, device, system, … is not doing what you want, and what modifications to it should change it in the desired manner. It is even less random than design—one has to build useful mental models of the failing system that explain the cause of the failure, then determine modifications that would fix that mental model, before trying fixes in the real world.
  • There are no right models, just useful models and useless ones.  (Even that’s wrong: there are more useful and less useful models, where the usefulness depends on what questions you need to ask of the model.)
  • Quick estimates from rules of thumb and extreme cases are handy.  A capacitor is an open circuit at DC and a short circuit at ∞ Hz, so low-frequency and high-frequency behavior of RC circuits is easy to estimate without much computation.
  • Empiricism rules: the answer to the question “Is this right?” is almost always “Try it and see!”

How can you tell if someone thinks like an engineer (or will learn to think like one)?

Some people point to kids who like to take things apart to see how they work, and say that they are budding engineers.  While taking things apart to see how they work is sometimes done by engineers, it isn’t the normal mode (they even call it “reverse engineering”, because it is backwards from what engineers usually do).  Scientists take things apart to see how they work—engineers put things together to make them work.

I posted about science vs. engineering 2½ years ago. In looking over that post, I see that even then I was thinking about the differences in training:

There is a distinct difference in the training one should give a student who is planning to be a scientist and one who is planning to be an engineer.  Sure, the basics are the same at the beginning (basic science, math, lab technique, computer programming, statistics, and so forth), but the engineer has to be taught how to design and debug, while the scientist has to be taught how to question dogma and discover new ideas.  These are not the same skills at all and both need substantial practice before people are competent at them.

For scientists, the tradition has been to devote the undergraduate years to acquiring basic knowledge, but not to practice being a scientist at all.  As a result it takes 5–7 years of grad school (and often several years of post doctoral training) to turn science undergrads into scientists. For engineers, the tradition has been to do 2–3 years of basic training, followed by 2–3 years of project work of gradually increasing complexity, culminating in either a B.S. or an M.S. degree.

The shorter training time for engineers means that it must be much more focused—you can’t hope that the students will pick up skills they need gradually as a by-product of years of doing something else (the way that scientists are trained). Instead, the specific design skills and group management skills need to be explicitly taught and practiced while the students are still undergrads.  This has a lot of consequences for curriculum design, as almost all junior and senior courses have to include design practice, and there needs to be at least one big project (preferably one too big for a single engineer to handle).  Explaining these curricular needs to faculty trained as scientists can be difficult—they want to leave all that to the grad curriculum or one-on-one training of postdocs.

I’m afraid that the bioengineering students in my circuits class have all been trained like scientists, with a huge number of courses in basic scientific knowledge, but almost no training in debugging or design practice. Hmm, that’s not quite fair.  Several of them have worked pretty intensively on debugging wet-lab protocols, though mostly in senior thesis projects, not in regular courses.

I can’t teach everything about “thinking like an engineer” in one course, even if I could articulate exacly what I meant by it.  I will try to give them problems that are puzzles, rather than rote application of formulas, and that emphasize design goals rather than analysis of what is already designed.  Since the traditional circuits course is almost all analysis with very little design, this makes the crafting of this course into an engineering design challenge: I need to create something new, not just copy exercises and lesson plans from elsewhere.

Unfortunately, I’m still wrestling with the precise design goals of the course and the constraints imposed by the time available and the prior training of the students. I had taken “thinking like an engineer” for granted earlier, for example, and not thought of it as a pedagogical goal for the course.  Now I need to rethink how I present material and how I get students to wrestle with it so that their lifelong habits of thought are shifted.  I was thinking I would be adding a couple of new tools (from circuit design) to their toolbox of mental models, rather than having them build a whole new toolbox.

Having to debug a course design is a lot like other engineering design challenges, except that I need to debug the course while it is running—I can’t turn it off, restructure it, and turn it back on again.  The problem I have right now is that my mental model of the material and how the students would interact with it is not quite right (I get too many surprises), and I’m trying to decide if it is a good enough model to continue with, or whether I need to find a substantially different mental model in order to debug the course.

Perhaps my new view of needing to teach “thinking like an engineer” is wrong—maybe the problems I’m seeing are not that fundamental, but are just unfamiliarity with the material, and that a little more practice to get comfortable with it is all they need.  The pedagogical interventions I’d need to do are quite different in these two views of the problem, and I’m not sure how to tell which mental model is more useful.

Does anyone who got this far in my post-midnight rambling have any suggestions for me?

Next Page »

The Rubric Theme. Blog at


Get every new post delivered to your Inbox.

Join 274 other followers

%d bloggers like this: