A few weeks ago, in our “Environmental Embeddedness“ article, we discussed the Microsoft Windows Embedded Student ChallengE, where student design teams were asked to design and develop embedded systems capable of giving something back to the world – preserving, protecting, or enhancing the environment. This week, we caught up with one of the winning teams in order to get more insight into the kind of product development process that could go through marketing requirements definition, specification, development, debug, and testing, even generating the marketing rollout presentation with a new development team, all in a total period of less than six months.

In commercial product development, it is all too easy to fall back on the usual design cycles and habits. However, when the first design requirement is an inviolate deadline, and the design team has no experience to tell them that such a schedule is impossible, we start to see the power of today’s new tools, platforms, and methodologies in truly accelerating system design. In their award-winning project, Team Erebus, from University of South Florida, began with Microsoft’s simple and vague directive in January 2006, and by June had come up with a project idea, researched the requirements, developed specifications, completed the design, engineering, debug and testing of the system, and made their final presentation.

The project, titled “The Erebus Scarecrow,” was an embedded design for protecting both endangered birds and fish farms. Fish farmers raising exotic species of fish (an important industry in South Florida, at over $42M per year) have a major problem with endangered birds consuming their equally exotic (and expensive) fish. Nature, it seems, in dogmatically sticking to its “survival of the fittest” doctrine, has little respect for endangered species lists or aquaculturists’ profit margins. The students’ plan was to construct a system that would guard the fish ponds by using video cameras to detect the presence of an unwanted intruder, then use various methods such as noise makers and water cannons to frighten away the bird, thus preventing a frustrated fish farmer from potentially taking the situation into his own hands and causing significantly more harm.

For the students, Francisco Blanquicet, Albert Ng, Jimal Ramsamooj, and Scott Werner, it may have been just another semester of hard work burning the midnight oil to complete this complex project on time. For the industry, however, it’s a wake-up call. If you can’t get your new product ideas to market in less than two years, your competitors, like these young people, armed with new design methodologies and devoid of inertial engineering process baggage, will most certainly beat you.

We’re all engineers here, so we’ll fast-forward through the marketing phases of the project. Suffice it to say that, under the supervision of Dr. Ken Christensen, their faculty advisor, the team blasted through the process of identifying a need, mapping out requirements, and deciding if they could engineer something to meet those requirements. Most corporate marketing teams would not have yet agreed on a color scheme for their PowerPoint slides in the time it took these folks to be nailing down final requirements. In the amount of time your average big-company marketing director needs to narrow down the options for an offsite venue with a good golf course for the kickoff meeting and “team building exercise,” Team Erebus was putting finishing touches on their design specification and was well into their engineering work breakdown.

It is easy for us to get complacent in our day-to-day work habits.

Also intriguing is the ease with which these students fell into close-knit, effective habits in working as a team. Higher-level education has often been maligned of late for shortcomings such as failure to instill real-world engineering skills like teamwork into students preparing for a career in industry. While many institutions still spend most of the curriculum with a focus on individual projects, the University of South Florida’s program has embraced the reality of the importance of teamwork and has updated their curriculum to match. “Our overall curriculum has had an emphasis on teamwork,” explains Scott Werner. “Usually, we have done projects in teams of two. This was one of the first projects with four people. We found it a little easier to split up the tasks, but time schedules with four people were more difficult to coordinate, and more communication was required.”

As with many industry projects, the team had to plan around real world constraints such as hardware availability. “We didn’t have the box for the first month and a half,” recalls Jimal Ramsamooj. “We had to make the best use of our time so that we could get reports done by the deadlines.” Numerous teams, in fact, fell out of the competition because they just couldn’t get everything together on the incredibly tight schedules imposed by the competition, or because they bit off more in their initial specification than they could manage.

The Erebus team was careful to identify the most difficult engineering problems early on, coming up with an iterative design process that would let them evolve toward their final goals rather than taking an “all or nothing” approach with waterfall-style development. “We had an early version of the product within two or three weeks of getting the box,” Ramsamooj continues. “That gave us something we could begin testing in order to shake out the bugs. We had no idea that we would see as many problems as we found initially. We spent much of the remaining time addressing the various issues we discovered in our initial testing.”

As in today’s commercial embedded systems, the team found the image processing challenge to be one of the most difficult, both from an algorithmic and an implementation point of view. Developing a scheme that could manage real-time video feeds and differentiate between a bird of prey and other sources of movement in the image (humans, plants moving in the breeze, wind ripples on the water, etc.) proved extremely challenging. Compounding the complexity were factors such as inconsistent lighting at different times of day and in different weather. On top of those issues, the team quickly found that they needed more processing power for the video analysis than for the other tasks in the system. Does this problem sound familiar to anyone out there? OK, you can all put down your hands now and keep reading.

The team managed some impressive compromises to get the device to work effectively in practical situations. Not wanting the fish farmer to get doused by water cannons each time he or she walked out to the pond, and not having the compute resources to reliably differentiate a human at a distance from various predatory waterfowl up close, the team decided to have the system recognize an orange vest as a signal to the system to stand down. Unfortunately, because of the white-balance challenge imposed by changing light conditions, it was difficult to consistently recognize the color of orange in an image. The students conquered this problem by placing a reference orange color object somewhere in the field of view of the cameras, allowing a light-compensated color reference to help improve recognition accuracy.

The digital scarecrow system is, of course, applicable to many other situations where wildlife needs to be peacefully discouraged from lingering in areas where unpleasant interactions with humans might ensue. The team has considered use in vineyards, orchards, and other venues for scaring away animals considered pests in those areas. They believe that image processing offers much greater flexibility and accuracy in pest detection and recognition than other schemes such as motion detectors.

As embedded system designers, what can we learn from the students’ success? First, that we should always be willing to challenge our assumptions about the “normal” way to do engineering. Second, we should do our best to eradicate the infamous “Not Invented Here (NIH)” syndrome. The students succeeded in part because they were able to take advantage of pre-designed hardware such as Microsoft’s Ebox development platform and available off-the-shelf components. They spent almost all of their time on engineering tasks where they were adding significant value, not re-inventing technology similar to what was already available on the market.

On the software side, by taking advantage of an easily configurable OS like the embedded version of Windows, they were able to get most of the benefits of a highly customized OS for their application without having to do “from scratch” development. This gave them a robust set of software IP as a foundation for their project, eliminating the need for programming most of the low-level functions required in a typical embedded system.

Third, the early prototype development model used by the team tends to pay huge dividends. The faster you can get something working in the real world that is some facsimile of the system you’re developing, the earlier you’ll know the incredible scope of the list of items you didn’t consider when developing your specification. There is always a feeling of completeness at the end of a specification exercise – a sense that you’ve thought of everything that could go wrong and accounted for it. Once you have a prototype working, that feeling is usually shattered, replaced by a sense that you can’t imagine how you didn’t think of all these things during your initial design phase…

Finally, we need to accept the reality that software and hardware design are converging. In most embedded design projects, there is little clean separation between the engineering of the hardware platform and peripherals and the development of software. The two disciplines have become so intertwined, particularly with the constant struggle to decide what functionality needs to go into hardware for performance reasons and what can remain in software for flexibility and development efficiency, that putting two teams with separate skills in separate buildings and asking them to work independently is rapidly becoming a losing plan.

Kudos to the members of Team Erebus, and let them serve notice to the embedded development community in general. Engineering is a constantly evolving discipline. The more we root ourselves to established processes and procedures without being constantly aware of the reasons for those methods and constantly challenging the validity of those assumptions, the more we position ourselves for competitive extinction. There are no water cannons that will scare these young engineers away from the competitive market. Those of us with experience will have to stay sharp or face extinction.