How did you get into electronics/engineering and when did you start?

My interests in electronics and electrical and computer engineering began to grow during my high school years. However, it was not until my junior year in college that these interests really began to expand into thoughts of a career in the discipline. I guess this would label me as a “late bloomer” compared to most self-proclaimed “engineering geeks” who are taking the blender apart when they are six years old. But, I was totally sports oriented in my younger years, so I left the blender dissections to others.

What are your favorite hardware tools that you use?

When dealing with hardware, I really prefer the digital side of things. Therefore, I am totally in my element with a breadboard, some digital logic components, a power supply, a logic analyzer, and a multimeter. I completely enjoy the process of creating a prototype capable of collecting analog data using some type of sensor, converting the analog data to digital data, processing that digital data, and finally creating signals to actuate something in the real world based upon that data. This flow ultimately defines the functionality of most embedded systems.

What are your favorite software tools that you use?

I don’t really have a favorite software tool. I have worked with many different software development tools and environments. Matlab, Simulink, Quartus II, and SolidWorks are great engineering tools. When it comes to code development, I am probably a bit different than most engineers in that I equally enjoy writing high-level code using a powerful IDE or writing assembly language without tool support. I have even hand-assembled code into its machine language equivalent and manually created the binary executables to be executed on an embedded system having no development tools or operating system other than a basic debug monitor. The low-level details of an embedded system are really cool, and in many cases the abstraction of these details created by using high-level tools removes much of the engineering. I enjoy the low-level engineering, and it is necessary for engineers to understand these low-level details.

What is the hardest/trickiest bug you have ever fixed?

The trickiest problem (not necessarily a “bug”) that I have ever worked on was a data acquisition system with analog-to-digital conversion using a 16-bit converter, a 5 volt input analog range, requiring 16-bit precision. The low bit for this application represented approximately 75 microvolts, and it was basically impossible to eliminate enough noise to get all 16-bits of precision. I tried all types of prototype boards, custom PCBs, custom shielding, etc. to no avail. Even the 60 Hz lights in the lab would create 2-3 bits of noise in the output signal of the converter. I even abandoned the required physical dimensions of the circuit and resorted to any and every possible means to reduce the noise. Eventually, I moved the circuit into a shielded lab room, i.e. a bank vault with 6-inch thick walls and every type of EM shielding known, but I was still getting only 14-bits of resolution reliably. In fact, the 15th bit would toggle if someone walked by the outside of the porthole window of the shielded vault. After weeks of tying to shield the circuit from noise, the project lead engineer determined that the original requirements for the project were not realistic given the budget and physical requirements of the system and that 14-bit resolution was all that was necessary. The lesson I learned was to make sure requirements are well thought out before starting a new project. Don’t take requirements at face value. Make sure you understand exactly what the requirements mean to the project and their impact on the overall project.

What is on your bookshelf?

My bookshelves are a hodgepodge of different things. As expected, I have lots of computer architecture books, digital logic books, embedded systems books, and real-time and parallel computation books. I even try to keep them grouped and organized by subject area, although not very successfully. My books range from 1980 – present since I am a packrat and don’t like to throw away books even if they are outdated. In addition to books, there are several shelves of lecture notes created and tweaked over the years. Then there are ABET specifications, some technical journals, a do-dad or two, a few small robot projects, and some students’ theses and dissertations.

Do you have any tricks up your sleeve?

It is not really a trick, but I am continually surprised at how few people use the systems engineering approach. This process advocates the decomposition of a large problem into smaller more manageable pieces. These smaller pieces are easier to handle and when completed their output can be combined to produce the overall desired functionality of the larger system. While this is a well accepted engineering methodology, most engineers I encounter (especially students) try to solve the whole problem at once. This leads to bigger blocks of circuitry or code to debug, longer testing times, fewer detected bugs, fewer intermediate results to build upon, and longer design times. This approach will add additional overhead to the project in the form of interfacing among pieces, but if the interfaces are well defined, the resulting benefits far outweigh the additional overhead.

What has been your favorite project?

My favorite project involved work done on the Automated Rendezvous and Capture system for NASA. This particular project involved development of an autonomous control system capable of docking two orbiting vehicles without pilot input. The work was performed at the Marshall Space Flight Center in Huntsville, Alabama while I was employed for NASA. This was a very cool project and involved some software and hardware development. The resources NASA had dedicated to this project were fantastic. These resources include the Flight Robotics Laboratory with its Flat-Floor Facility which is basically a huge air-hockey table used to float and maneuver full size mockups of the orbital vehicles under test. There is also the six-degree-of-freedom stuart table used for close range docking operations, and the Marshall Avionics System Testbed (MAST) simulation lab which has several state-of-the-art parallel computing platforms and a three-axis table. All of these facilities are linked via high-speed fiber to create a truly unique capability to simulate vehicle operations from launch through orbital operations to reentry and landing. Opportunities to work with such world-class facilities are rare.

Do you have any note-worthy engineering experiences?

Before joining the faculty at the University of Alabama, I worked for NASA for 15 years in the Engineering Directorate at the Marshall Space Flight Center. During this time, I worked on several really interesting projects mainly focusing on real-time simulation. Some of these projects included Automated Rendezvous and Capture, the National Launch System, and the X-33 project.

While at NASA, I was also a scuba diver in the Neutral Buoyancy Simulator for orbital operations training, specifically supporting astronaut training for shuttle and International Space Station missions. The most famous mission I was involved with was STS-61, the first repair mission to the Hubble Space Telescope.

What are you currently working on?

I am currently an Associate Professor in the Department of Electrical and Computer Engineering at the University of Alabama. As a faculty member, I have found that there is never a time when I am working on just one project. In fact, most of the time I am working on too many projects. Primarily, my research falls into one of the following three areas:

• Project 1: Embedded systems optimization. I am focusing on the optimization of embedded systems by integrating hardware accelerators to reduce the overhead introduced by the use of a real-time operating system. While real-time operating systems provide many services useful to the embedded systems designer, they also consume resources, specifically computation time, which are usually already tightly constrained for most embedded systems. This processing overhead can be reduced if various functions normally performed by the OS are off-loaded to dedicated hardware units thereby reducing the computation time required by the OS and leaving more CPU time dedicated to the execution of the application workload. This type of optimization is becoming more appealing given the increase in system-on-a-chip architectures and the improved capability of FPGA devices to handle more complex designs. Some potential areas where OS overhead can be reduced include task scheduling and bus arbitration. In one particular project, a hardware accelerator was designed and implemented that achieved speedups between 13-26 times over the software scheduler used by the OS. When integrated into the OS, some of this performance gain eroded, but significant speedups were still realized. [Potdar, S., Ricks, K. “Overhead Reduction for an Off-the-Shelf Real-Time Operating System”, ISCA Journal of Computers and Their Applications, Volume 17, Number 2, pp. 70 – 83, June 2010.]

• Project 2: Embedded systems education. I am always looking at ways to improve the curriculum and embedded systems education in general. I recently completed enhancements and an in-depth evaluation of the computer engineering curriculum at the University of Alabama [Ricks, K. G., Jackson, D. J., Stapleton, W. A., “An Embedded Systems Curriculum Based on the IEEE/ACM Model Curriculum”, IEEE Transactions on Education, Volume 51, Number 2, pp. 262 – 270, May 2008. This paper won the IEEE Education Society 2009 Best Transactions Paper of the Year Award. Sorry for the shameless personal promotion.] I am currently developing various educational tools to help undergraduate students learn embedded systems concepts from both high-level and low-level perspectives. It is hoped that these tools will complement classroom education helping students to gain knowledge of the low-level details and the high-level “big-picture”. At this point, these tools are still under development.

• Project 3: Autonomous robotics. I am developing techniques to coordinate groups of autonomous robots to perform coordinated tasks such as search and rescue. This research focuses on techniques and technologies suitable for low-cost robotics for both terrestrial robots and UAVs.

What challenges do you foresee in our industry?

Maybe the biggest challenge for this industry is addressing the shortage of U.S. engineers. The U.S. must increase its production of domestic engineers to maintain a leadership position in the world. However, this problem can’t be addressed by simply watering down the requirements of the discipline just to increase graduation rates. Instead, creative ways to capture the attention of a larger set of students are required, and improved educational processes are needed to help students master the material once they have entered the field.

What challenges do you foresee in electrical and computer engineering education?

There are many challenges facing electrical and computer engineering education that must be addressed. For example, the discipline is advancing at such a fast pace it is difficult to integrate emerging technologies into the curriculum. This also comes at a time when academic administrators are looking at ways to reduce the number of technical hours in the normal curriculum. Additionally, how does one integrate the use of technology into the classroom while maintaining and promoting academic ethics? How does the United States address its shortage of scientists and engineers by making the discipline more interesting to a larger group of potential students? Engineering education must address these and other issues in order to produce the number of qualified graduates that the US needs over the next few decades.

In what areas do electrical and computer engineering students need the greatest improvement?

The top three areas in which ECE students need improvement are: 1) testing; 2) testing; and 3) testing.

I have talked to many different ECE faculty members and industry representatives across the country over the last several years and testing is by far the most common answer to this question. Testing is an acquired skill that applies to both hardware and software. Unfortunately, most students do not appreciate the need to test their creations. In many cases, code is “delivered” that has never even been compiled (not even once). Circuits are presented that have never been powered. Students seem to have no understanding of how to create an adequate set of test data including in-range and boundary values. If testing is done at all, it is done using the simplest data set possible, no documentation is produced to describe the test performed, who did the test, how many tests were conducted, how the test results were combined (averaged, summed, etc.), or what the test results mean. This is a significant problem that academic institutions are struggling to address in the curriculum.

What are some of your interests other than engineering?

I am a big sports fan. I particularly like football, basketball, and baseball/softball. I also enjoy various other activities like hiking, camping, fishing, scuba diving, and karate.