RC4 Servo Monitor & Controller - Fact Sheet
RC4 is a 4-channel servo monitor/controller board that provides a variety of rich, robust
features that make it ideal for many autonomous and semi-autonomous applications. RC4 can be used
as a simple servo controller, or it can be plugged into a standard RC receiver to
monitor and respond to five pulse-width-modulated signals and drive four servo outputs.
Input or output pulse width measurements can be obtained from each channel during operation via a
serial interface. This serial interface can operate reliably at speeds up to
57600 bps without interfering with servo control signals.
RC4 provides the following notable features:
- Five PWM input channels and four PWM output channels. Ideal for R/C applications.
RC4 provides four main independent channels that are designed specifically to process signals that are generated by a typical radio-control receiver. Each of the four channels has one input and one output. A signal on a channel input can be processed, digitally, via the serial interface, and/or routed to the corresponding channel output. An extra input is provided - referred to as "channel 5", or as the "Trigger Input" - to support event triggering. RC4 can process input signals having a frame rate ranging from about 18ms to about 21.5ms (46.5 to 55.5 Hz) and only supports signals that are multiplexed one channel at a time.
Note that many PCM radios produce signals on more than one channel, simultaneously. Therefore, RC4 is unable to support this type of radio.
- Individually configurable channel modes & behavior.
Each of the four main channels can be configured separately to operate in one of eight different modes. The mode of operation for a channel can be changed at any time via the serial interface. Typically, the specific mode selected for a channel defines how the channel responds to input signals depending on the state of the internal Fail-Safe mechanism. The modes can be categorized into two general distinctions: command (or "host") modes and R/C modes. Command mode refers to channel outputs that are driven by commands sent via the serial interface. R/C mode refers to channel outputs that are driven by signals on the channel inputs. Regardless of what mode a channel operates in, any signals received on the channel inputs can be sampled in digital form at any time via the serial interface.
- Glitch-free operation at all times while accessing serial port.
Some commercial servo controller boards operate on a principle that allows their function to be interrupted when commands are issued via the serial interface, occasionally causing the output signals to be disrupted. If a servo is connected to a channel output, this disruption can cause the servo position to jitter. RC4 takes a different approach and does not allow the output signals to be disrupted in any way while commands are processed via the serial interface.
- 16-byte serial interface transmit and receive buffers.
When issuing a command to RC4 via the serial interface, RC4 may be busy processing a previous command request or taking care of other necessary internal processes. Therefore, RC4 uses a receive buffer to collect the commands that are issued until such time it can carry out the request (the response time is measured in milliseconds). Also, some commands are more than one byte long, so RC4 cannot process such commands until all bytes of the command have been received. RC4 can collect up to 16 bytes in its receive buffer at any given time. This helps maximize command throughput since the host controller does not have to wait for one command to complete before issuing another. Similarly, a 16-byte transmit buffer is used for returning command results. Some RC4 commands return multiple bytes of data. RC4 uses this buffer to place the results of a command so it can move on to its next task, alleviating the burden of having to wait for the host to receive the data. The contents of the transmit buffer are transmitted to the host via the serial interface. If another command is received before all the data is transmitted, any new data to be returned is simply added to the transmit buffer. The serial interface operates in full-duplex mode, which means it can send and receive data at the same time.
- Byte mode vs. Burst mode data-returns to accommodate fast and slow host processors, alike.
Data in the internal transmit buffer can be sent across the serial interface in one of two ways. In Burst mode, data is transmitted in a stream at whatever the selected bit rate is, until the transmit buffer is empty. Any data added to the transmit buffer is immediately transmitted. In Byte mode, data added to the transmit buffer is not automatically transmitted; only the first byte is. When a command is issued to RC4, the results of the command are written to the transmit buffer, and the first byte is transmitted back to the host. If more than one byte is in the buffer, the host must issue a "Read Next Byte" command to tell RC4 to send the next byte. Unlike Burst mode, Byte mode can only process the results of one command at a time. If a new command is issued before the transmit buffer is empty, the transmit buffer is cleared and the new data is written to the buffer and the first byte of the new data is transmitted.
- 333ns (13-bit) input signal sampling resolution, with +1/-1us accuracy on all inputs.
RC4 is driven by a 12 MHz clock, which allows it to process 3 million instructions per second. This equates to one instruction every 333 nanoseconds. RC4 is capable of detecting the edge of an incoming signal pulse with an accuracy of 3 instructions, or 1us. Therefore, the furthest it can be off from detecting the actual pulse edge is 1us. If RC4 detects the actual edge of both the leading edge and the trailing edge of the pulse, right on, or misses detecting both edges by the same number of cycles, the resulting measurement is exactly that of the actual pulse width. However, if one edge is detected right on, and the other edge is missed by 1us, this produces the +1/-1us error margin, as it can result in a measurement that is either 1us too long, or 1us too short. However, 1us is negligible to a servo.
RC4 can accept pulse widths as wide as 2.133ms to 2.570ms, depending on the programmed configuration. To represent these pulse widths as a digital value requires 13 bits of data, which is delivered via the serial interface within a 16-bit value. Regardless of the accuracy of a signal value, the value will always be represented as a 333ns resolution sample.
- +1/-0us output signal reproduction accuracy for twitch-free operation on all outputs.
Output signal reproduction is relative to the provided signal value. What this means is that the value that RC4 has for a given signal is reproduced on a channel output with +1/-0us accuracy. Therefore, if a signal value is provided by a host processor via the serial interface, the generated output pulse will be within +1/-0us of the given value. For a signal sampled from a channel input, the +1/-1us accuracy from input sampling is accumulated with the +1/-0us accuracy of the output signal generation, giving a total signal reproduction accuracy of +2/-1us of the original signal. This range of error is negligible to a standard hobby servo.
- Reliable signal sampling for input signal frame rates between 18ms and 21.5ms (46.5Hz to 55.5Hz), depending on configuration.
RC4 provides a pre-selected range of operating parameters for optimal operation for input signals that have frame rates between 18ms and 21.5ms. There are eight selectable configurations, each of which specifies operating parameters that can accept a particular range of pulse widths. If a particular receiver connected to the inputs of RC4 produces a frame rate that is less than 18ms or greater than 21.5ms, the ability of RC4 to process the input signal reliably begins to break down. RC4 will continue to function outside this range, but it will miss sampling some signal frames. However, frame rates between 18ms and 21.5ms can be sampled by RC4 with 100% reliability under normal operating conditions.
- Pulse width sampling between 900us (min.) and 2570us (max.), depending on configuration.
As mentioned above, RC4 provides eight pre-configured options for processing input signals of varying frame rates. Each of these options defines an absolute minimum and maximum pulse width range that defines a valid input signal. The absolute minimum pulse width that RC4 can sample in any configuration, is 900us. The lowest absolute maximum pulse width value is 2133us (for an 18ms frame rate), and the highest absolute maximum pulse width value is 2570us (for a 21.5ms frame rate). Most commercial R/C equipment operates between 50 & 55 Hz (18-20ms), so RC4 should be configured to operate as close to the receiver frame rate as possible.
- Eight serial interface speeds, selectable from 1200 bps to 57600 bps (including RoboBRiX compatibility).
Communication between a computer and RC4 is accomplished via the serial interface. Data exchanged on the serial interface is transmitted (and received) at one of eight selectable bit rates, including: 1200, 2400, 4800, 9600, 19200, 38400, 56000 and 57600 bps. RC4 is designed such that it can talk directly to a RoboBRiX master hub. RoboBRiX are distributed functional modules used in assembling robotic systems that use a compatible serial interface protocol that operates at 2400 bps. Therefore, setting RC4 to 2400 bps will allow RC4 to talk directly to a RoboBRiX hub. However, RC4 supports RoboBRiX data structures and commands at any of the eight speed settings.
- Configuration and signal presets can be saved to EEPROM to conform to your application.
RC4 was designed to be extremely flexible, providing many configurable options to conform to a wide variety of custom applications. The power-up defaults programmed into RC4 from the factory may not comply with the operating parameters you need. Therefore, RC4 provides a means of saving your custom configuration to EEPROM so that RC4 will power-up with settings that conform to your application.
- Reset and factory settings restoration under hardware or software control.
RC4 can be reset during normal operations either by a command issued over the serial interface (i.e. a "software reset"), or by a button connected to the reset input (i.e. a "hardware reset"). In either case, the power-up settings are restored and RC4 proceeds to function as if power was just applied. Similarly, if custom settings have been stored in the EEPROM and RC4 has become unstable as a result of saving incorrect settings, or you simply want to restore RC4 to the original factory pre-programmed state (i.e. a known state), this, too, can be accomplished via a software command, or by an external hardware button. In some cases (e.g. if incorrect EEPROM settings disables RC4), the only way to restore factory settings is by using the hardware button.
- Integrated "Fail-Safe" features to control behavior between R/C and host-control modes.
Fail-Safe is a built-in mechanism designed to provide reliable operation and fail-safe controls in environments where signals may come and go (and also just as a measure of safety in particular applications). Several settings affect how a particular channel will respond to changes in Fail-Safe status, including the programmed mode of the channel and whether or not Noise Rejection is enabled. The various combination of settings can be used to establish a means of automatically switching between a command mode of operation and R/C operation, based on signal activity. This could be used in an application that can switch between manual (R/C) control and autonomous behavior (driven by an on-board computer).
- Programmable Noise Rejection option for increased stability in "noisy" signal environments.
The built-in Fail-Safe mechanism provides robust operation, even in "noisy" or lossy signal environments. However, RC4 provides an additional Noise Rejection option that can be turned on or off to provide additional stability in environments where signal quality is exceptionally poor.
- Outputs switchable between PWM inputs and host control (e.g. to switch between R/C and autonomous operation).
This relates to the eight possible modes in which a channel can operate. The operating mode of a channel can be altered at will via commands sent across the serial interface, causing the channel to switch to a command control mode or to a mode that responds to the R/C inputs. Some modes provide automatic switching based on the presence or absence of signals, or depending on the Fail-Safe state. RC4 is very flexible in allowing the user to define how a channel responds to changes in input signal.
- Programmable triggering options for "Trigger Input", plus six hardware-selectable signal sources.
RC4 has a fifth PWM input known as the "Trigger Input." This input can receive a PWM signal (at any frame rate, really) and is a separate and distinct channel from the four main R/C PWM channel inputs. It's pulse width range is not limited by frame rate selection and can sample pulses much shorter and much wider than R/C signal pulses (up to 21.8ms wide). RC4 currently has a fixed, pre-defined threshold level that is compared against the measured pulse width of an incoming signal pulse. If the signal on one sample is wider than this threshold, then on the next sample is shorter than this threshold, a "trigger event" occurs. Currently, there is only one built-in event that can be enabled via the serial interface, and that is to use the Trigger Input to control the activation of the Fail-Safe state. The Trigger Input can be connected to one of six possible input sources by using hardware jumper blocks on the RC4 board. A dedicated "channel 5" input, available on the board, is typically chosen as the input source, but any of the four channel outputs, as well as the channel 3 input, are available as alternative selections. Channel 3 typically translates to the throttle input on R/C vehicles which is why it was chosen as one of the six sources - this enables events to be triggered based on the throttle setting. A host computer/processor can read the Trigger Input signals via the serial interface to respond to custom threshold settings and perform custom events as needed.
- Demand Fail-Safe mode activation via Trigger Input or software command.
Depending on one's application, it may be desirable to enter the Fail-Safe state in response to certain conditions. There are two ways to force RC4 to enter the Fail-Safe state. One is to issue a command via the serial interface, and the other is to enable "Fail-Safe On Demand" as a trigger event on the Trigger Input. These two methods are mutually exclusive, however, so if control is enabled on the Trigger Input, the software command will not work. The Trigger Input method is available as a hardware solution to envoke the Fail-Safe state, and the command method is available as a software solution for a host computer to envoke the Fail-Safe state in response to situations.
- Immediate vs. normal Fail-Safe activation control.
Through the normal Fail-Safe mechanism, RC4 performs some degree of signal processing to determine when the Fail-Safe state should be engaged or disengaged. Through normal signal processing methods, Fail-Safe will engage after a period of about one second when input signal is lost. If Fail-Safe is envoked either through the Trigger Input or via a software command, a configurable option determines whether the Fail-Safe activation will occur immediately upon request, or will behave as though signal has been lost and endure the normal delay time associated with signal loss. This option to immediately engage Fail-Safe only applies to the Fail-Safe on Demand functionality and cannot be applied to normal signal processing.
- Robust automatic serial interface recovery features to keep host communication open.
As in any complex device with a communication interface, there lies the potential of data transfer errors or other conditions that may lead to the internal state of the device being out of sync with the host, or to possibly wind up in a state where communication is lost, entirely. RC4 has built-in protection to prevent against this. If RC4 stops responding to commands from a host computer, the host can respond to this by simply ceasing all serial interface activity for a period of time (approximately 5 seconds). If enabled, RC4 will automatically reset the serial interface after this period of command inactivity in an effort to maintain or restore host communication.
- Selectable signal data and status information reporting options.
RC4 provides a rich set of commands for retrieving signal data and status information. However, it is possible for signal data to get out of sync with status information between individual commands that retrieve data and status. Therefore, RC4 can be programmed to select from various groupings of signal data and status information to be retrieved in response to a single "Read Channel Data" command. These reporting options can be changed at any time via the serial interface.
- Configurable Big-Endian or Little-Endian data exchange.
"Endianness" is a term used in computer hardware architecture design that refers to the order in which data bytes are stored in memory for values that are represented by more than one byte. The familiar desktop (Intel-compatible) "PC" computer operates in Little-Endian mode, which means the least significant byte of a value is stored in memory first (i.e. at a lower memory address) than the remaining bytes. It also means that data exchanged across the serial interface is sent least significant byte, first. In a Big-Endian configuration, the most significant byte is sent and stored first. RC4 accepts and delivers 16-bit (2-byte) values in response to several serial interface commands. The order in which these 2-byte values are expected and delivered is determined by the Endianness setting of RC4. RC4 can be configured via a serial interface command to operate in either Big-Endian or Little-Endian mode.
- Expansion headers for external LED indicators, reset buttons and future expansion.
The RC4 circuit board provides a 10-pin header to give access to some of the I/O pins on the microcontrollers in the circuit. This 10-pin header provides access to five indicator signals that can be used to drive LEDs that give a visual indication of RC4 activity. It also provides access to the master reset input, to which an external button can be connected. Also available is an input for inducing a factory restore operation to restore RC4 settings to factory defaults. The 10-pin header makes it convenient to locate these LEDs and buttons on an external panel outside of whatever enclosure RC4 is mounted in. Many of these same pins - as well as a couple additional pins - are available on an alternate in-line 7-pin header. Some pins are currently not implemented, but may be used in future versions of the RC4 firmware.
- Input signals can be intercepted and modified by a host before being routed to outputs.
RC4 can be used as a R/C signal sampler, or as a servo controller, or both. When a channel is configured to operate in a command mode, the channel input PWM signals can still be sampled. A host computer can read the channel input signals and write them back to RC4 to drive the outputs. Additionally, the computer could alter the signal values before writing them back, giving the host the ability to modify incoming signals "on the fly". One possible application of this technique could be in an environment where RC4 is used to drive a motor controller. The host can monitor the input signals and modify them to prevent the output signals from driving the motor controllers too hard, thus providing protection against high-current melt-downs of the motor controllers.
- Supports a mixture of various brands of R/C equipment (including Airtronics and Futaba, etc.).
In the early days of R/C, there were no standards for connectors for R/C equipment made by different manufacturers. Therefore, descrepancies exist between the different connectors made by these different companies, even today. For example, the polarity of Airtronics receiver battery and servo connectors is opposite that of Futaba's connectors, making it impossible to plug a Futaba servo into an Airtronics receiver, or visa-versa. RC4, on the other hand, provides on-board jumpers for selecting the polarity of the connectors used on the inputs and the outputs. The polarity of the inputs can be configured independently of the polarity of the outputs (however, all inputs will be of equal polarity, and all outputs will be of equal polarity). Therefore, an Airtronics receiver could be used to drive the inputs, and Futaba servos could be connected to the outputs. Or visa-versa. Or, RC4 can be used exclusively with one brand of equipment. Airtronics and Futaba are just two examples of the R/C equipment that is supported.
- Jumper-selectable options for separating RC4 mainboard, R/C receiver and servo power sources.
Power spikes on the lines that provide power to the chips on the RC4 main board can cause problems in some cases, possibly causing the microcontrollers to reset or wind up in an unknown (or very bad) state. Power spikes can be caused by servos if the servos are powered by the same power source as the RC4 microcontrollers. Therefore, RC4 provides a means of separating the power sources into three different segments, allowing the RC4 board, receiver and servos to each be powered by separate power sources. Or, RC4 plus the receiver can share a power source, with the servos driven by a separate power source. Or, the receiver and servos can share power, separately from the RC4 components. Either way, this alleviates the potential for servo activity to disrupt normal RC4 operation.
More detailed information about RC4 is available here.
General Theory of OperationRC4 splits its tasks between two PIC microcontrollers, PIC1 (a PIC16F648A) and PIC2 (a PIC16F628).
PIC1 handles all of the communication requirements. It provides a serial port command interface to allow a host system or controller to interact with RC4, as well as a custom high-speed two-wire serial communication interface for exchanging data between PIC1 and PIC2. PIC1 also provides input sampling for the Trigger Input.
PIC2 handles all of the PWM signal sampling and signal generation for each of the four input and output channels (the Trigger Input is processed by PIC1). PIC2 is really the central driving force behind RC4, dictating to PIC1 when two-wire communication cycles can occur, and maintaining a rigorous timing schedule to keep things on track and in synch. It manages all the signal processing dirty work. In fact, PIC2 is so dedicated to its job that it will continue to function, unimpeded, even if PIC1 is completely removed from the circuit (although RC4 would lose the ability to respond to the Trigger Input).
In order for PIC2 to provide the high degree of quality in gathering stable pulse width measurements, there are some built-in limitations. For example, the PWM inputs must be multiplexed such that only one input has a signal on it at any given time. Most standard R/C receivers work this way, delivering signals in sequence from Channel 1 through Channel 4. PIC2 is also limited as to how quickly it can turn around, after sampling input signals and generating output signals, to be ready for the next batch of input signals. Signal sampling begins to break down for input signals that repeat at intervals less than about 17.5ms. This is not a serious limitation, however, as PIC2 will continue to successfully sample input signals; it will merely skip missed input cycles if the frame rate is too short.
Input signal sampling and output signal generation occur at different times. Output signals are generated only after all input signals have been sampled. This means there is a slight delay between the time a signal arrives on the input and the time the signal appears on the output. This delay is different, depending on configuration settings, but typically amounts to approximately half of the selected frame rate.
For example, for an input signal with a period of 18ms, the output generation cycle begins 9ms after the first input signal is detected. Because of this timing, connections to RC4 from an R/C receiver must be grouped by adjacent channels (for example, you cannot connect channels 1,2,3 and 5 from an R/C receiver to channels 1,2,3 and 4 of RC4). The order in which the channels are connected is not restricted, however, as long as it is a grouping of four adjacent channels. For example, channels 1,2,3 & 4 of an R/C receiver could be connected to RC4 channel inputs 2,4,3 & 1 if this configuration was necessary for some reason.
RC4 will not work with some radios - such as some Futaba PCM radios - because they produce signals on multiple outputs, simultaneously. RC4 cannot support these radios, now or in the future.
One primary goal of PIC2 is to keep the output signal generation cycle on track, through thick and thin. If there is a problem with the input signals, PIC2 does its best to maintain a stable output. If no input signal arrives when expected, PIC2 aborts input sampling in favor of getting the output signals out on time.
Although there is a delay between input signal sampling and output signal generation, the period and waveform of the outputs remain unchanged from the input. If the input signals repeat every 18ms, then so do the output signals - they're just delayed 9ms later in time. For an 18ms configuration, if there is no input signal present, then the output signal period will change from 18ms to 19ms. This absent-signal period will always be 1ms longer than the configuration setting. For example, if RC4 is configured for input signals with a 19ms period, the output signals will repeat every 20ms when no input signal is present. This difference is due to how input signal timeouts are implemented in PIC2.
RC4 was primarily designed with servo-based applications in mind, so these minor differences in output signal periods don't amount to much as far as a servo is concerned. However, because of these delays and variances, RC4 may not be well suited for critical applications that rely on when pulses arrive from the source.
Another major objective of PIC2 is to deliver signal data and status information that is in synch with each other over the serial interface, so that status information obtained from PIC2 actually reflects the same signal cycle in which the channel inputs were sampled. This, too, is the reason that the Read Channel Data command has extended data levels available to it. Since PIC2 can interrupt PIC1, asynchronously, to deliver updates, two subsequent reads from PIC1 by the host over the serial interface (one to retrieve signal data and another to retrieve status) could wind up out of synch. This is because it is possible that PIC1 could receive an update from PIC2 between the time it delivers the signal data and the time it delivers the status information. Having a single command return both signal data and status information eliminates this possibility.
As with all systems, the #1 primary objective of RC4 is to survive. An incredible degree of innovation has been implemented to ensure that RC4 not only survives, but also remains functional, within its applied environment.
More detailed information about RC4 is available here.
Copyright (c) 2002-2007 by CodeSmart. All rights reserved.