Introduction to an introduction to servos

My last post about force and torque got kind of long, prompting some suggestions that I break it up into two separate posts. I didn’t do it because my sentiments about units and the common confusion of weight and mass applied to both topics. I want to move on to a thorough discussion of hobby servos, which is broad enough of a topic that it definitely merits a breakdown into multiple posts. That got me thinking about the order in which to present the material. So, this post is mostly about organizing and presenting information and not really about servos. The options for describing a complex system mirror the approaches available for design of complex systems, so my comments here should be somewhat relevant both to educators and to engineers. Plus, if you are an engineer trying to get help troubleshooting your system, you need to become an educator about your system, and you need to hit the right balance of big picture and details for your audience.

I also want to get a little more of the editorial content out of the actual servo posts so that they might function better as stand-alone tutorials. So, if you want to read only about servos and how they work, you should move on to the next post.

I have been emphasizing the abstractions involved in engineering, and so far, I have mostly addressed low-level concepts that I think of as fundamentals and tried to get readers to think about some of the details behind the abstractions with which they might be comfortable. The main reason for that tendency is that part of my goal is to encourage those who already have some familiarity with the material to get into more of a troubleshooting mindset (“what bad assumption is causing this problem?”) and to give them more appreciation for sound engineering (“let’s make sure we understand all of our assumptions and principles so we do not have any unexpected problems”).

The “fundamentals first” philosophy is a bottom-up approach, in which you start with details and build from there toward a complex design. Formal educations generally follow this approach: we learn letters and numbers first, then combine those into simple words and math expressions like “2 + 2”, and then we learn to combine the words into sentences and expressions into equations. Unfortunately, this kind of education takes many years, and many do not have the discipline to learn the fundamentals once they are out of a formal academic environment. It’s worth noting that people can communicate in words and sentences without knowing any letters, and since humans could communicate before development of formal alphabets, this kind of bottom-up learning might not be that natural. In a harsh and foreign world, being detail-oriented might not have been the best survival strategy.

The modern problem with bottom-up learning is that it can be boring. For those of us not inclined to dedicate our lives to studying the number of neutrons in dysprosium, the fundamentals are a means to a end, and we need to be reminded of that glorious end to remain interested. The challenge for educators, provided they have learned the basics themselves, is to provide glimpses of the bigger picture without getting too distracted by it. In the case of this blog, I assume you are reading it because you already have some big picture goals of your own, and my task is to provide some useful fundamentals without being so boring as to extinguish your dreams.

If you have the right personality and a bit of awareness about where you’re headed, a bottom-up approach can actually be a lot of fun, like a good mystery where early details keep coming together in ways that exceed your expectations. My best learning experience was learning about how microprocessors worked. I had played with transistors since sixth grade and with microcontrollers since tenth grade, but it somehow never really occurred to me that one could just use a bunch of transistors to make a microcontroller. It didn’t even really hit me until I was a good way through the “Computational Structures” course in my second year of college, even though I was thoroughly enjoying each lecture. My recollection is that the course was sometimes taught bottom-up, starting with transistors and going toward a microprocessor, and other times taught the other way around, starting with a high-level blocks of a processor and then breaking down each block. Combining small parts into more and more amazing machines had a thrill that I don’t think can be matched by starting with a complete system and then digging into the details. It looks like the free online version of the course is the bottom-up version; I highly recommend a class like this for anyone who has worked with microcontrollers and wants to learn more.

And yet, my plan for the servo posts is to begin with a high-level overview of servos and to gradually descend into the details. This is a top-down approach. Having just discussed the opposite alternative, the benefits of a top-down presentation should be obvious: the destination is front and center. The drawback to this approach is that the payoff tends to diminish with each level of detail we explore. (This leads to snide comments about those who study dysprosium.) As a result, students exposed to too much of this style might lose interest in the details and never attain more than a superficial understanding of complex systems. This lack of understanding might in turn confound selection of appropriate goals; I have many times seen beginners attempting projects way beyond their skill level. However, the top-down method is efficient for communication about large systems since it is easier to identify the relevant low-level components that might need more attention.

Bottom-up and top-down approaches are also relevant to engineering design. These might be represented by questions like, “what can I make with this cool part I just found?” and, “how can I make a device that does such-and-such?”. Each of these methods has its drawbacks, so practically speaking, we usually have to go back and forth between the two. It’s good to be aware of some of the common drawbacks of each so you do not get blindsided by them.

The bottom-up approach can suffer from a lack of unified direction and from complex interactions that can develop between low-level modules. Since we at Pololu mostly design components and sub-assemblies, this is a common problem for us and our customers. We strive to design the best module we can for the constraints we have, but we cannot optimize for every combination of parts, so a general-purpose motor controller and a particular motor we carry will not be as optimal as a motor controller designed specifically for that motor. The situation only gets worse as dozens or hundreds of parts from different manufacturers get integrated into a single system, and sub-systems that work independently stop working when combined. If you’ve worked on an interdisciplinary robot team, you might have experienced the corresponding problem where the mechanical engineers have a nice solution to their sub-problem and the electrical engineers have a nice solution to their sub-problem, but the two solutions don’t work together.

The weakness of the top-down approach is that it forces many assumptions of what is possible and hides simple but fundamental problems that might be difficult or impossible to overcome once they are finally encountered. A less generous way of putting it is that top-down design involves a lot of wishful thinking, which can lead to a rude awakening for those who did not learn the details of how to actually make one of those black boxes. I was on a team once where we made what I still think was an awesome electromechanical system (among other things, we effectively made our own big servo in it); what undid us was thinking we could pick up multi-threaded Java programming in a few days despite having no object-oriented programming experience.

Ultimately, to be a good engineer, you have to be comfortable jumping around between the big picture and the nitty gritty. I expect I’ll do a lot of that jumping around in this blog, especially as we develop some categorization scheme. I’m going to do a top-down presentation of servos, but if you’re building a robot, the servo is just a component, and thinking even a little bit about it could represent a bottom-up approach as far as your robot is concerned. And with that, I will stop procrastinating and start writing the actual introduction to servos.