FIGURE 7.1 Inner view of a standard R/C servo motor.
In this chapter, I will show you what makes up a standard R/C servo motor, as well as how to control one. I have already provided a considerable amount of information in the three previous chapters on how pulse signals are used to control servos. Now it is time to reveal the inner workings of a servo motor so that you will understand how and why it operates as it does and be aware of its limitations and constraints when you are using it. This “reveal” will focus on how a specific pulse width translates into a specific servo-motor motion.
I will also discuss how a standard servo motor can be converted into a continuous rotation (CR) servo motor. CR motors operate a bit differently than standard ones do. The CR motor has the pulse width that directly controls the continuous angular speed or rotation instead of providing a limited angular motion as the standard servo motor does. CR servo motors are often used as replacements for conventional motors in which low torque requirements exist, such as for powering small R/C cars or boats. I always use CR servos to power my robotic projects, and they seem to function quite nicely.
The next section describes how I built a system to measure the pulse widths for up to three of the R/C channels. I will also show you how to display the results on a 4 × 20 LCD character display. This system uses the Parallax Board of Education (BOE) and can be made totally portable by powering it all from a standard 9-V battery. My discussion of the software includes quite a bit of information regarding pointers and indirection, which are often a source of confusion for beginning programmers. Also, in the software, I point out how a Spin program measures pulse width in a way that has not been previously shown in this book.
This chapter concludes with a discussion on two ways to extend the standard servo-control system to accomplish functions that enhance the Elev-8 platform. The first one controls the onboard LED lighting strips mounted on the bottom of the Elev-8 booms. The second one controls a tilting mechanism for a remote-controlled, first-person viewer (FPV), which can be attached to the bottom of the Elev-8. The actual FPV will be described in a later chapter. Now, I want to focus on only the servo-control aspect of this system.
Figure 7.1 is a partially transparent view of the inner workings of a standard R/C servo motor. I would like to point out five components in this figure:
1. Brushed electric motor—left side
2. Gear set—just below the case top
3. Servo horn—attached to a shaft protruding above the case top
4. Feedback potentiometer—at the bottom end of the same shaft with the horn
5. Control PCB—bottom on the case to the motor’s right
The electric motor is just an inexpensive, ordinary motor that probably runs at approximately 12,000 r/min unloaded. It typically operates in the 2.5- to 5-V DC range and likely uses less than 200 mA, even when fully loaded. The servo-torque advantage results from the motor spinning the gear set so that the resultant speed is reduced significantly, which in turn, results in a very large torque increase as compared to the motor’s ungeared rating. A typical motor used in this servo class might have a 0.1 oz-in torque rating while the servo-output torque could be about 42 oz-in, which is a 420 times increase in torque production. Of course, the speed would be reduced by the same proportional amount, going from 12,000 r/min to about 30 r/min. This slow speed is still fast enough to move the servo horn to meet normal R/C requirements.
The feedback potentiometer attached to the bottom of the output shaft is a key element in positioning the shaft in accordance with the pulses being received by the servo electronic-control board. You may see the feedback potentiometer clearly in Figure 7.2, which shows another image of a disassembled servo.
I will tell you more about the potentiometer’s function during the control-board discussion. For now, I will simply state that it forms part of a closed-loop control system that I introduced in Chapter 2. If you skipped that part, it might be a good time to go back and review the topic, as it applies to this case.
The servo horn is simply a plastic part that slips into grooves at the end of the output shaft and is used as part of a mechanical actuating mechanism. It is held in place with a very small machine screw. The shaft grooves ensure that the horn does not slip under load. Figure 7.3 shows a close-up of some typical servo horns.
The electronics board is the heart of the servo and controls how the servo functions. I will be describing an analog-control version, since that is, by far, the most popular type used in low-cost servo motors. I will mention the digital version at the end of this section and compare it to the analog version. Figure 7.4 shows a Hitec control board that is in place for the model HS-311 that I used for my demonstration system.
The main chip is labeled HT7002, which is a Hitec private model number as well as I could determine. This chip functions in the same way as a commercially available chip by Mitsubishi with the model number M51660L. I will refer to the M51660L in my discussion, since it is used in a number of other manufacturer’s servo motors and would be representative of any chip that is used in this situation. The Mitsubishi chip is entitled “Servo Motor Controller for Radio Control,” and its pin configuration is shown in Figure 7.5.
Don’t be put off by the different physical configuration between the HT7002 in Figure 7.4 and the chip outline in Figure 7.5, as it is often the case that identical chip dies are placed into different physical packages for any number of reasons. The M51660L block diagram shown in Figure 7.6 illustrates the key functional circuits incorporated into this chip.
Now I will provide an analysis that will go hand-in-hand with the illustration of the demonstration circuit shown in Figure 7.7, which was provided in the manufacturer’s data sheet (as were the previous two figures 7.4 and 7.5).
The analysis below should help you understand how an analog servo functions and why there are certain limitations inherent in its design.
1. The start of a positive pulse appearing on the input line (pin 5) turns on the set/reset (RS) flip-flop and also starts the one-shot multivibrator running.
2. The RS flip-flop works in conjunction with the one-shot to form a linear one-shot, or monostable, multivibrator circuit whose “on-time” is proportional to the voltage appearing from the tap on the feedback potentiometer and the charging voltage from the timing capacitor attached to pin 2.
3. The control logic starts comparing the input pulse to the pulse being generated by the one-shot.
4. This ongoing comparison results in a new pulse called the error pulse, which is then fed to the pulse-stretcher, deadband, and trigger circuits.
5. The pulse-stretcher output ultimately drives the motor control circuit that works in combination with the directional control inputs that originate from the RS flip-flop. The trigger circuits enable the PNP transistor driver gates for a time period directly proportional to the error pulse.
6. The PNP transistor driver-gate outputs are pins 4 and 12, which control two external PNP power transistors, which can provide over 200 mA to power the motor. The M51660L chip can provide only up to 20 mA without using these external transistors. That is too little of a current flow to power the motor in the servo. The corresponding current sinks (return paths) for the external transistors are pins 6 and 10.
7. The 560-kΩ resistor (Rf), connected between pin 2 and the junction of one of the motor leads and pin 6, feeds the motor’s back electromotive force (EMF) voltage into the one-shot. Back EMF is created within the motor stator winding when the motor is coasting or when no power pulses are being applied to the motor. This additional voltage input results in a servo damping effect, meaning that it moderates or lessens any servo overshoot or in-place dithering. I will also further discuss the Rf resistor when I cover the CR servo operation.
The above analysis, while a bit lengthy and detailed, was provided to give you an understanding of the complexity of what is constantly happening within the servo case. This knowledge should help you determine what might be happening if one of your servos starts operating in an erratic manner.
The word deadband, as mentioned in step 4 of the analysis, is worth further explanation. Deadband used in this context refers to a slight voltage change in the control input that should not elicit an output. This is a deliberate design feature created for the instance when you do not want the servo to react to any slight input changes. Using a deadband improves servo life and makes it less jittery during normal operations. The deadband is fixed in the demonstration circuit by a 1 kΩ-resistor connected between pins 9 and 11. This resistor forms another feedback loop between the pulse-stretcher input and output.
The last servo parameter I will discuss is the pulse-stretcher gain, which largely controls the error pulse length. This gain in the demonstration circuit is set by the values of the capacitor from pin 11 to ground and the resistor connected between pins 11 and 13. This gain would also be referred to as the proportional gain (Kp) in closed-loop control theory. It is important to have the gain set to what is sometimes jokingly called the “Goldie Locks region,” not too high and not too low, but just right. Too much gain makes the servo much too sensitive and possibly could lead to unstable oscillations. Too little gain makes it too insensitive and prone to very poor response. Sometimes, experimenters will tweak the resistor and capacitor values in an effort to squeeze out a bit more performance from a servo; however, I believe the manufacturers have already set the component values for a good compromise between performance and stability.
It turns out that there are almost no differences between analog and digital mechanical servo components. The mechanical differences, when present, are often related to using metal gears and ball bearings in digital units, which are more expensive than the analog units. However, the main difference is found in the electronic-control board. The analog control was explained in the previous section: analog-control circuits are used in conjunction with digital-logic and comparator circuits. No numeric calculations or analog-to-digital conversions (ADC) are done in an analog servo; hence, there is no need for the microcontroller chip that is present in the digital servo.
Figure 7.8 shows three views of a reasonably priced Dynamixel AS-12 digital servo. The ATmega8L servo with its controller board exposed and mounted at the bottom of the servo can clearly be seen on the right side of the figure. I have already discussed the ATmega8L chip in Chapter 5 because it is the common controller used in many ESCs. In this application, the chip does ADC as well as real-time numeric calculations to generate the appropriate power-control pulse in much the same fashion that the ESC did in response to its PWM signals.
The digital servo has several significant advantages and one big disadvantage as compared to the analog servo, all of which are listed in Table 7.1.
The digital servo outperforms the analog servo in all areas except power consumption, which can be a factor if your aircraft uses many servos. This is actually not that great a concern given the current availability of high-energy and high-capacity LiPo batteries.
I have also included Figure 7.9, which is an excerpt from the Fubata datasheet that shows quite clearly the relationship of the R/C control pulses as they apply to both analog and digital servos.
The analog servo is referred to as the “Standard Servo” in the figure. Also, Diagrams 1, 2, and 3 refer to the no-power, low-power, and high-power operating conditions, respectively. The analog servo is fixed at using the pulses that arrive at the nominal 50-Hz frequency, while the digital servo creates as many as six times that number of analog pulses in the same 20-ms time frame. This means that more average power is being applied to the internal servo motor, which results in more torque and a much faster response. Of course, more average power means more power consumption, which is the digital servo disadvantage.
One more excerpt from the Futaba datasheet is Figure 7.10, which shows a comparison of deadband characteristics, such as percentage of torque versus response time. What you are looking for in these characteristic graphs is a nearly vertical line indicating that the servo rapidly builds torque to the 100% level in a very short time interval. You can see from Figure 7.10 that the digital response is much better than the analog response. This is due to the controller continuing to optimize its performance and the much faster update rate that is in use in the digital unit.
Sometimes you will need a servo to act as a normal motor with the added advantage of being able to closely control both the speed and rotation direction. I have used continuous rotation (CR) servos for quite a long time in the robots I build for both classroom and personal use. You may purchase CR servos, or you can convert a standard servo to a CR type fairly easily. CR servos are almost identical in price to standard servos. I will explain the difference between the two, and you can decide if you want to convert or purchase a CR servo.
The standard servo has a mechanical stop in place on a gear that is part of the main output shaft. This tab restricts the output shaft to a fixed range of motion, usually 180°. Figure 7.11 shows this mechanical stop on a standard servo gear train set.
I would recommend snapping the tab off with a sharp diagonal cutter rather than filing it down. Ensure that you disassemble the gear set before working on it, since you don’t want any plastic shards or filings gumming up the gear train. Figure 7.12 shows the tab neatly removed and filed flat.
The next step in the conversion process is to remove the potentiometer by desoldering it from the circuit board. The potentiometer also has built-in stops, which would restrict the output shaft if it were not removed. The potentiometer must be replaced with a resistor-divider circuit that supplies the midpoint voltage to the one-shot multivibrator. Figure 7.13 shows an altered demonstration schematic with two 2.2-kΩ resistors replacing the potentiometer.
Now the control chip believes it is always at the center point, and when you supply an input-pulse waveform with more than a 1.5 ms width, the controller will drive the motor in a CW direction. Conversely, if the input pulse width is less than 1.5 ms, it will drive the motor in a CCW direction. Additionally, as you either decrease or increase the pulse width, the motor will rotate faster in the respective direction. This means that a 2.0-ms pulse width produces the maximum speed in the CW direction, while a 1-ms pulse width produces the maximum speed in the CCW direction.
The only disadvantage is that the motor will tend to creep if your resistor divider doesn’t produce exactly the midpoint voltage. Exactly how much is hard to predict, since the torque needed to meet operational requirements plays a part in actually moving whatever object is being powered by the CR servos. A large robot would likely not even move because of the minute creep signal that is created. I would definitely use matched or precision resistors in order to divide the voltage as precisely as possible.
Another way to address this issue is to alter the value of the deadband resistor (the 1 kΩ) to help eliminate the undesired motion. It would take a trial-and-error process to determine the correct value.
There is one final caveat that you should know. It is entirely possible that the plus or minus .5-ms deviation from the center 1.5-ms pulse width will not produce the full rotation speed change that is possible. This is entirely due to having too large a value for the feedback resister Rf. The value set for this resistor in the demonstration circuit is 560 kΩ. This may have to be lowered to 120 kΩ to achieve the full speed capability for pulse widths that range from 1 to 2 ms.
NOTE: This conversion process of changing standard servos to CR servos is applicable only to analog servos. I am not aware of any process to convert a digital servo. It may be possible but certainly would involve changing proprietary firmware, which is just not feasible.
It is critical to confirm the quality and values of pulse signals when designing a control system based upon those signals. The following system uses a BOE and an LCD to display three R/C channel pulse widths in real time. I used an ordinary 9-V battery to power the system in order to show that it has minimal power requirements. Figure 7.14 shows a pictorial diagram of the main components and how they are interconnected using standard three-wire servo cables.
In Figure 7.15, the actual test setup is shown running with three R/C channels being displayed on the LCD. I will discuss the displayed data shortly.
The LCD display is an interesting peripheral. It uses a standard 4 × 20 character display with backlight control to help with the character visibility in various ambient lighting conditions. Normally, LCD displays are parallel devices, which means that they require a total of 8 to 16 control lines from a microprocessor to display data, depending on whether they are in a nibble (4 lines) or byte (8 lines) mode. The LCD I used for this setup has a Parallax-developed serial-to-parallel “back-pack” auxiliary board, which is shown attached to the back of the main LCD board in Figure 7.16.
This board uses only a single TTL serial line to accept data and display it on the LCD. I used a standard servo-control cable to connect it to the BOE. The secret to this simplified operation is the driver software that is discussed below.
The software running on the BOE is a modified version of a Spin program named RX_Demo. It was created and posted on Parallax’s website in their Spin software exchange they call OBEX. This site is a very valuable resource where you will likely find programs that will either directly match your requirements or need only slight modifications to do so. I slightly modified the original top object to take advantage of the built-in servo ports in the BOE configuration. I also reduced the number of R/C channels monitored from six to three, as that satisfied my requirements.
The project software ultimately involved eight Spin files with four of the eight filling what I will term utility roles. These utility files handled the LCD display, serial interface, and numeric conversions. Figure 7.17 is a PSerT screenshot of the beginning of the RX_demo program.
Please notice the Spin program hierarchy shown in the upper left-hand corner of this figure. You can easily see the relationships between the various objects. Essentially, the program named Debug_Lcd takes care of all the display functions needed in the RX_demo program. The RX program does the actual pulse-width detection and reports the results back to RX_demo. Finally, the Servo32v6 program handles any servo pulse modifications that are needed before being sent to the designated output pins.
Below is the RX_demo program listing for which I have included the original documentation as well as my own comments to help clarify the program’s functioning.
When the program runs, the welcome briefly flashes, and then the pulse-width data for three channels is continuously scrolled on the LCD screen. The values are in microseconds, meaning that a value of 1504, as shown on the screen, translates to 1.504 ms.
In the test setup, three of the R/C receiver’s channels were connected as follows:
1. Throttle to Servo 14
2. Aux 3 to Servo 15
3. Aux 1 (Flaps) to Servo 16
I then deliberately set each of the corresponding controls on the DX-8 transmitter to its midrange position, which is why you see values near 1500 displayed on the LCD screen in Figure 7.15.
The RX program that measures the incoming pulse width is worth discussing because it uses a different way of determining pulse width than has been previously covered in this book. The code for this is shown below with some clarifying comments after the listing.
The RX_demo and RX programs exchange data using a common technique called indirection, where variables represent the physical memory addresses of the data. In C and C++, these indirect variables are called pointers. It is a powerful and very efficient means to exchange data, but be aware that it has inherent dangers, since you can easily misuse a pointer and crash your program and maybe the whole computer. Two references are created in the RX_demo program, as shown below:
The array named pulsewidth has four “long” word elements that may be indexed as pulsewidth[0] to pulsewidth[3]. Data may be written to and/or read from these variable locations. Also, note that it was declared in a VAR block. The memory location variable reference is simply the name pulsewidth prepended with the “@” symbol. So using @pulsewidth tells the program to either store or read data beginning at that location. It is important to state that you should never use an actual physical memory address but simply use the logical reference name or pointer.
The next reference, named pins, also has four “LONG” word elements. Notice that the word “LONG” was capitalized in this declaration. This was a purely optional choice and was done to indicate that the pins array is constant and cannot be overwritten. The pins array was declared in a DAT block, meaning that it is data. It is a read-only data array. You certainly would not want to dynamically change the pin designations for your input channels. However, it can be referred to as pins, just as the pulsewidth array may be referred to as pulsewidth.
The following method call in the RX_demo tells the start method in the RX object where to find the data regarding the input pins and also where to store the pulse-width data corresponding to those pins. Note the indirection used in the arguments.
RX.start(@pins,@pulsewidth)
The Spin compiler is quite elegant and advanced, since it will automatically create the appropriate reference type based upon the contextual use. The start method signature is shown below:
PUB start(pins_array_address, pulsewidth_array_address)
The RX.start method call in RX_demo uses @pins and @pulsewidth to pass the starting array addresses. These are copied into the pins_address and the pulsewidth_address arguments respectively, making them pointers, since they contain addresses not real data. In C and C++, these arguments would have to be separately declared as pointers; however, Spin does it for you as needed. This is a very nice feature.
One more point before I get off my tangent regarding data indirection and pointers. Pointers can be treated as normal data; for example, assigned to other pointer variables or having simple arithmetic operations applied to them. The key point to remember is if you add 1 to a pointer, you are not incrementing the physical address but instead are instructing the compiler to use the next logical element in the memory storage area. Using the start method as an example:
From my teaching experience, I have learned that pointers and indirection have often been difficult concepts for beginners to understand. This is the reason why I presented such a detailed discussion regarding this somewhat complex topic. You really should understand this material in order to get the most from the software development whether you are using Spin, C/C++, or any other language that uses these concepts.
The start method also contains this very complex statement:
cog[i] := cognew(readPins(@long[pins_array_address][i*2], @long[pulsewidth_array_address][i*2]), @stack[i*20]) + 1
It is the instruction that creates several cogs to do the pulse-width measurements. This instruction is in a loop that iterates i from 0 to 2. Substituting 0 for i in the first iteration results in this:
cog[0] := cognew(readPins(@long[pins_array_address][0], @long[pulsewidth_array_address][0]), @stack[0]) + 1
This really odd expression simply translates as:
Start executing the method named readPins using the beginning data pointed to by the “pins_array_address” pointer and store the result in the first memory location pointed to by “pulsewidth_array_address.” Also, use all the memory needed for the cog located at the beginning of the “stack” memory area.
The index ‘i’ will increment to 1. Then the whole process will repeat with cog number 1, and it will use the next sequential pin number and store the result in the next sequential location in the pulsewidth array. The stack location is incremented by 20 due to the expression @stack[i*20], which ensures that the new cog has plenty of memory space within which to operate.
The readPins method is the heart of the RX object. I will not step through this method line-by-line other than to point out the liberal use of the waitPEQ instruction in this method. waitPEQ pauses the cog’s execution until a pin, which is being monitored, reaches a certain state, normally high or low. Of course, the system counter continues to run, thus accumulating a count directly proportional to the elapsed time. Therefore, the high and low times of a pulse are easily determined using this instruction.
The last portion of the program is concerned with the extended servo outputs that are handled by the Servo32v6 program along with the associated sub-object Servo32_Ramp_v1. This program is a clever extension that will allow you to control up to 32 servos, if you needed such a hefty requirement. I will not be discussing these programs though, since they are not used in either of the two servo applications I discuss below. Just be aware that operating a large number of servos simultaneously can represent a hefty current flow. Even the standard Hitec HS-311 analog servo can take up to 180 mA when operating at no load. The peak-current draw will, of course, go much higher if there is a torque load on the servo. That would mean about an average 3-A current flow, if you were by any chance, trying to run 16 servos at the same time. This is a heavy draw that could rapidly deplete a normal battery.
This project is actually a second revision of an LED-lighting controller that I built and installed on my original Elev-8. That controller is shown in Figure 7.18. It worked quite well and was based on the Parallax Basic Stamp II BOE. The LED transistor-driver circuits are located under the hardboard labeled Elev-8 seen on the left side of the figure.
This controller worked correctly as I mentioned above, but I was a bit disappointed that I could not dynamically control the light pattern once it was programmed. I made all the LED strips flash in a variety of patterns that just kept repeating, in a way that reminded folks who saw it of the Close Encounters of the Third Kind movie without the music.
The more I thought about it, the more I wanted to be able to send a signal to the quadcopter to dynamically change the lighting. One thought was to flash just the LEDs attached to the forward booms so that I could easily see in which direction the quadcopter was moving, especially as daylight faded. I also wanted to stop the flashing entirely in order to conserve battery energy. These ideas would lead to the following requirements:
• Forward boom LEDs flashing
• All LEDs flashing
• No LEDs flashing
These requirements meant that I needed an unused three-state control switch. By serendipity, the switch happened to be available on the DX-8 in the form of the Aux-1, or Flaps, control switch. This light control is an ideal use of the three-position switch because the Elev-8 does not and will never require flaps.
I tested the switch shown in Figure 7.19 and determined that it generated the following pulse widths for the three switch positions, as shown in Table 7.2.
The LED light strips cannot be run directly from the BOE because the current draw is too high. Therefore, I created four transistor driver circuits that control the four strips based on gate signals from the BOE, and eventually, from the QuickStart board. As I mentioned earlier in the book, the BOE would be my development platform. I would use it to eventually port all the control programs over to the QuickStart once I have confirmed that everything functions as it should. Figure 7.20 is a picture of the QuickStart board that will be used as the onboard lighting controller.
The following is a Spin program that I wrote to monitor the pulse width being received on the Aux-1 channel, and then, to modify the LED lighting scheme in accordance with the requirements. The transistor-driver circuit is contained in the header documentation; however, the special characters used to create the schematic do not copy over using the Word program’s copy and paste functions. Figure 7.21 shows a screenshot of the schematic portion.
{{
LED_Control
D.J. Norris (C) 2013
This program sets the LED lighting mode for the four LED strips attached to the underside of the Elev-8 booms. The mode is selected based upon the Flap switch position on the Spektrum DX-8 R/C transmitter.
The three possible positions with associated modes and pulse widths are:
See Figure 7.21, since as already mentioned, Word copy/paste does not work with the special characters used to create the Spin documentation schematic.
You should realize that the above code is totally useless unless referenced and used by the top object, which is RX_demo. I once again modified RX_demo to use the LED program, and I also added some logic to determine the appropriate LED lighting mode to call. This code listing is abbreviated without the header or license information. I also added comments in an italic font to highlight the LED_Control program changes.
All that you need to do to run this software is to load the new LED_Control and the modified RX_demo into the project, recompile it, and execute it (F11 key). Figure 7.22 shows the LED-development-test setup for the LED-strip control project. I captured all the LEDs being lit as the BOE was operating in mode 1. You may also be able to see that the DX-8 Aux-1 (FLAP) switch is in the middle, or 1, position, which commands that all LEDs flash. Also, note that the LCD display is showing the number 1505 in the rightmost column, which is the Aux-1 pulse width in microseconds.
The actual transistor-switching circuit board that controls the four LED strips and is mounted in the Elev-8 is shown in Figure 7.23.
The complete transistor-switching board may be installed between the Elev-8 boom ends, as shown in Figure 7.24. I have also wired all the LED-strip power leads to the transistor-switching circuit board in this figure.
Figure 7.25 shows the complete installation of the transistor-switching circuit board along with the QuickStart board. You can see that I used a solderless breadboard to connect all the leads from the transistor-switching circuit board to the QuickStart board as well as to the Aux-1 R/C channel.
I also temporarily connected the LCD screen to verify that the proper pulse signal was being received on the Aux-1 channel. You can see that the pulse width changed very slightly from 1504 to 1505 during the test I ran when the photo was taken. This slight change of one microsecond will not affect the mode selection because the program code uses a much larger test value before a mode change is made. I also deliberately made the decision to use a solderless breadboard to enable quick configuration changes, while recognizing that it is not as reliable as using solid mechanical connections. A critical flight-control problem would not arise if one of these connections were to fail during a flight, since it controls only the LED lighting.
One last thing I want to point out is some of the telemetry data being displayed by the DX-8 LCD screen, as shown in Figure 7.25. The screen shows the LiPo-battery voltage at 12.0 V, the left rear motor rotating at 1293 r/min, and the ambient temperature at 71°. Note that the r/min reading is incorrect for the reasons I previously stated in Chapter 6’s telemetry section. It really should be closer to 4300 r/min.
The first thing you need to know about this project is that no software is required because it uses only the standard R/C servo-control functionality. I have included this project to show how very simple it is to implement a standard servo actuator to support an enhancement to the Elev-8. The servo will tilt a video camera that is part of a first-person video (FPV) system, which is really just a fancy way of saying that there is a video camera mounted on the quadcopter to show you where you are going. I am using the GoPro Hero 3 camera that incorporates both video recording capability and real-time video by using a WiFi connection. Figure 7.26 shows a picture of the Hero 3 camera. I will not say much about it here, since I devote all of Chapter 8 to using video with a quadcopter.
This camera will be attached to the bottom of the Elev-8 with the lens positioned to look forward. This is fine for conducting ordinary flight and avoiding obstacles, such as trees or tall buildings. However, I wanted to increase the camera’s flexibility so it would be able to tilt downward and see the terrain and objects beneath the quadcopter while it was either hovering or traveling in a level plane. In addition, I was not concerned about panning the camera, since it is very easy to simply yaw the quadcopter if you want to shift the viewing direction.
After some thought and a bit of research, I came up with a simple tilting-platform design that I am sure has been done before by many others in a similar fashion. Figure 7.27 is a concept sketch that I used before proceeding with the design.
The fixed outer frame is designed for attachment to the Elev-8’s bottom chassis plate with some nylon spacers as well as appropriately sized machine screws and nuts. I used Lexan to build the frame and rotatable platform, since it is both strong and easy to work with. I used wood blocks, a bench vise, and a heat gun to bend the Lexan strip to the form shown in the Tilting Platform Assembly drawing, which can be found on this book’s website, www.mhprofessional.com/quadcopter.
A Hitec standard HS-311 was used as the table actuator because it seemed to have sufficient torque to turn and hold the camera to the desired position. Figure 7.28 shows the tilt platform without the camera attached to illustrate that it is a simple design.
My only concern with this project was that mounting the camera too far off-center would upset the center-of-gravity, since the assembly with the camera weighs 281 grams. This amount of mass mounted off center could make the quadcopter too unstable to fly. The fully assembled platform assembly with the camera in its water resistant case is shown in Figure 7.29. I mounted the assembly on wooden blocks to provide clearance and allow free camera movement.
The servo cable was attached to the DX-8 Aux-3 R/C channel to test the assembly. I used this control because it creates a continuously variable pulse width from 1.0 to 2.0 ms, which means a 0° to 90° range of motion for the rotatable platform. Figures 7.28 and 7.29 show the camera set at 0°, while Figure 7.30 shows the camera set at 90°. This range of motion corresponds to the Aux-3 knob set from fully CCW to fully CW.
If you look carefully at the Figure 7.30, you can see the portion of the BOE in the upper right hand corner that I used to supply power to the servo. The BOE was powered by a 9-V battery, which made for a very portable setup.
The frame for the tiltable platform was attached to the Elev-8 bottom chassis plate, using four 1-in 4-40 screws along with four 
-in OD nylon spacers, washers, and nuts. I aligned the frame to the plate and then used a Sharpie™ marker to locate four holes to be drilled through the frame top. Figure 7.31 is a top view of the bottom chassis plate showing the four attachment screw tops. You can readily see the four nylon spacers that support the tiltable frame in Figure 7.32.
My only caution is to ensure that the movable platform that holds the camera is not blocked in its range of motion by any of the mounting screws. I had to slightly notch the platform to allow some clearance for the screws so that the platform could rotate throughout a full 90° range of motion.
This tiltable camera platform project came out very well, and it is much less expensive than any commercial product that will provide a similar function. The total cost of the parts, without the camera, is less than $15.
I began this chapter by discussing what is inside a standard analog servo motor and how those innards function. This was followed by a comprehensive circuit analysis of the servo electronic-control board that receives an incoming pulse train and converts it to the equivalent actuator motion.
In a discussion of the digital servo, I pointed out that there was little to no difference between the analog and digital mechanical components. The main difference lies within the electronic-control boards. The digital version provides significantly more torque, and it is much faster at matching the changes in the incoming pulse train than its analog counterpart is.
I next showed you how a continuous rotation (CR) servo functions and also how to convert a standard analog unit into a CR unit. CR servos change motor speed and direction in response to the standard servo pulse train, which is very handy if you need a low torque and a low- to medium-speed motor. Otherwise, it is best to stick with a conventional motor that has a complimentary speed control unit attached to it.
Next I discussed a portable servo-signal analysis system that could display on a 4 × 20 LCD screen the pulse widths for up to three R/C channels. The software, which was run on a BOE, was thoroughly analyzed. I also included an in-depth discussion on the subject of indirection and pointers, a sometimes bewildering topic, especially for beginner programmers.
Then I covered two projects, the first of which was an LED-strip lighting controller. This controller is designed to be placed onboard the Elev-8 and controls each LED strip based upon the pulse width sent by the DX-8 Aux-1 (FLAP) channel. There are three separate lighting modes, since the Aux-1 has three positions. This lighting controller enhances the Elev-8 but does not affect its flight performance.
The second project was a tiltable platform that has a GoPro video camera attached to it. The platform is mounted on the Elev-8’s bottom chassis plate and tilts to enable the camera to view the ground while it is either hovering or in level flight. The platform is tilted by a standard analog servo that is directly controlled by the DX-8 Aux-3 channel. The camera platform may be continuously tilted from 0 to 90 degrees, since the Aux-3 control is a potentiometer.
The next chapter will show you how to set up and operate an HD real-time video system that uses the tiltable platform to increase the video coverage.
