Components: Servos

Do you speak Servo?

2014-10-31 16.51.15_sm

Various standard servo motors (about 180 degrees movement each). Click for larger.

Servo motors (both positional and continuous-rotation) are useful devices. Provide power, ground, and a relatively simple control signal, and the servo’s onboard circuitry handles all of the motor-control tasks, including a closed-loop feedback system to ensure the servo maintains the correct position or speed.

One nice thing about servo motors is that they are easily controlled by a microcontroller with no additional control or current amplification circuitry needed. Constant DC power (typically, 5V-6V) is applied to the servo, and a control signal is provided to the (high-impedance) control line. One microcontroller, depending on application specifics and processor speed, can control as many as a couple dozen servos.

In addition to traditional servos and continuous-rotation servos, small, efficient, and powerful DC brushless “outrunner” motors have recently become popular in many applications such as electric RC aircraft and quadrotor flying drones. Outrunner motors are essentially three-phase AC motors, driven by a custom controller. Conveniently enough, these controllers usually use the standard servo protocol, as well.

2014-10-31 16.52.06_sm

A brushless DC motor and its electronic controller. The controller receives control commands as if it were a servo motor, allowing existing servo motor microcontroller libraries to be easily adapted to control these motors. (Click for larger.)

In a nutshell, servos and similar devices are controlled by the following signal type:

  • 5V TTL (5VDC high, 0VDC low);
  • High impedance input, easily driven directly by logic;
  • 20ms (50Hz) period pulsed input;
  • ~0.5ms — ~2.0ms pulse width (varying the pulse width provides the control variable.)
Pulses to control a servo. Five 0.5ms pulses command full movement in one direction; five 1.5ms pulses command movement to the center; and five 2.5ms pulses command movement in the other direction.

Pulses to control a servo. Five 0.5ms pulses command full movement in one direction; five 1.5ms pulses command movement to the center; and five 2.5ms pulses command movement in the other direction.

One pitfall when working with servos is to think of this signal as a PWM cycle, and calculate servo position based on the duty cycle of the pulse. While technically correct, the “duty cycle” only varies from roughly 1% to 4% when ranging over the entire valid control input range of the servo. A duty cycle of 25%, for example, does not correspond to 25% power, as it would for a motor driven directly by a PWM signal. Rather, a 25% duty cycle pulse train would probably not be understood by the servo controller as a valid signal at all. It’s best to think in terms of pulse width, since changes in pulse width (within a small range) correspond to changes in servo behavior. Even the long 2.5ms pulses are still only 12.5% “duty cycle.”

 

 

Posted in Components, Digital, Electronics, HOW-TO, Robotics | Comments Off

FreePCB Arduino Shield Template

Having been too busy / lazy to sit down and learn Eagle CAD or another “real” PCB program, I’ve been using FreePCB to make all kinds of PC boards on the LPKF board plotter at work.

With our increasing use of Arduinos (we’ve been using them in Senior Design projects for several years now, and are starting to teach introductory programming with them), we will almost certainly need to design Arduino shields in the near future.

Having looked online and not found an Arduino shield template for FreePCB, I decided to make one.

(Screenshot of template in FreePCB)

The template, rendered in FreePCB. (Click for larger.)

Here is the FreePCB template file. Remember to save a copy before you modify it with the components and traces for your design.

“Share and enjoy!” (CC:BY-SA)

 

Posted in Arduino, Design, Digital, Electronics, Resources | Tagged , , , , , , , | Comments Off

User Interface Done Right

Advances in technology often make possible new, more efficient ways of doing things. This can certainly make our lives easier and more enjoyable. As with any change, however, there can be drawbacks. The operation of new devices is not always intuitive to users who have never seen it before. Novel devices should be designed with a naive user in mind: the device should teach the user how to use it — ideally, with little or no effort on the part of the user. This advice is especially relevant in situations when the use of new technology is forced upon users, such as in public restrooms. Infrared towel dispensers, which require the user to perform a kind of modern-day rain dance in order to obtain a towel, are increasingly prevalent. The benefit is that you don’t have to touch the dispenser to get your towel — but for someone who has never seen one before, they can be confusing at first. Sometimes, however, a small change in operation can make a device a lot more intuitive to use. A local community college recently installed touchless towel dispensers in its restrooms. These dispensers, however, extend a towel right away, replacing it immediately when it is taken. Even if a user hasn’t seen one of these before, they will probably understand that they are supposed to take the towel.  When they do so, the dispenser replaces it. Now the user knows how the process works, without ever having to figure anything out! 2014-08-07 17.32.55_sm

Posted in Design, Digital Citizenship, User Interface Design | Comments Off

How Not To Code

Recently, my friend Dan shared a thought-provoking picture of a quote by Martin Golding:

 

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." --Martin Golding

Words to live by.

When I first started writing programs back in the Dark Ages (1980s), I wasn’t even aware that coding styles existed. Not only did I probably break every applicable rule in the Embedded C Coding Standard — my code was usually cryptic, terse, and would have been very very difficult to scale.

Nowadays, looking through my code library, I can almost tell when I wrote a piece of code, based on how it looks. Here’s an example of some of my oldest BASIC code that I could find: (The file, helpfully, was called “T.BAS”)

5 PRINT TIME$
10 FOR X = 1 TO 1000000
20 P = 1 / X
30 NEXT X
40 PRINT TIME$

This is Dark Ages code for sure. No comments or other documentation whatsoever, single-letter variable names (the only reason TIME$ is there is that it’s built-in), and LINE NUMBERS. Fortunately, this program is very simple, so it’s an easy enough task to figure out what it does. (It’s a very simple benchmark for a division loop.)

Here’s how I might write it these days:

‘Division loop benchmark test program (FreeBASIC)
‘Notes time to execute one million divisions of size double
‘M. Eric Carr / eric(at)(email address)

‘Variable declarations
‘———————-
dim as double quotient
dim as ulongint curNum

‘Note the start time
print “Doing 1,000,000 divisions…”
print “Started at: “;time$

‘Run a loop of 1,000,000 divisions
for curNum = 1 to 1000000
quotient = 1/x
next curNum

‘Note the end time
print “Ended at: “;time$

end

This is a little better. It’s still flat code (no subroutines or other hierarchical structure), but it’s simple enough that such structure isn’t really needed. The documentation and intuitive variable names make it much easier to maintain, the output now tells the poor clueless user what is going on, and the global variables are at least declared.

Here are some other helpful tips to make your code more maintainable:

  • Use comments liberally. If it isn’t immediately obvious what a line of code does, document it inline with comments. In fact, it can be helpful to write the entire program in pseudocode, as comments, and then go back and fill in the mechanics.
  • Use intuitive, descriptive variable names. A variable named “x” can mean many things, but one named “currentOutdoorTemp” is a bit more descriptive. When using a compiler, this has zero runtime cost — the compiler will translate the variable names into memory locations automagically, anyway.
  • Use structured programming. If you have several pieces of information that belong together, consider using custom data types. If you have a program that is more than a dozen lines of code or so, it has probably become large enough to be split into subroutines. Doing so modularizes the task of programming, making the program easier to understand and far easier to maintain, modify, and scale.
  • Along with the “structured programming” theme, use as few global variables as possible. They can be modified by not only the main code, but by subroutines, making it potentially very difficult to diagnose what is happening. For multithreaded applications, this becomes crucial; any global or shared variables will require good, solid mutexes.
  • Don’t use GOTO statements unless absolutely necessary. These can often be avoided even when programming in assembly. (My own goal is to never use GOTOs, with the exception of a single GOTO at the end of the main loop, when coding in assembly.) GOTO statements can make code execution very difficult to trace.

…because all too often, the violent psychopath who will have to maintain your code — is YOU!

Posted in BASIC, Coding | Comments Off