Current Status: Currently under development. Functional prototype in testing phase, undergoing usability analysis.
RC4 can sample up to five PWM inputs and control up to four
PWM outputs, independently or simultaneously. Various operating parameters can
be specified for the module, and various modes of operation can be specified on
a per-channel basis. The fifth input (referred to as "Channel 5") provides
pulse-width controlled event triggering.
The first-iteration prototype is seen here on its test bed with a Futaba 7-channel
receiver (with five channels connected to the inputs) and four standard R/C servos
connected to the outputs. The final RC4 board will be significantly reduced in size.
I hope to produce one version that conforms to Robobrick specifications.
One primary feature of RC4 is its fail-safe mode. This feature provides the core
functionality for switching between host control and radio control (R/C) in response
to loss of input signal, which is the fundamental reason RC4 was initially created.
Fail-safe is an integral part of RC4 and cannot be disabled. However, each channel can
be configured independently to ignore fail-safe mode or to respond to it in various ways.
RC4 uses an elegant, yet extremely reliable algorithm for detecting signal quality
to determine when to activate and deactivate fail-safe mode, even in environments where the
radio signal is susceptible to interference. Fail-safe mode also can be deliberately
activated either by issuing a command over the serial port, or by using the "Channel 5"
triggering feature.
When RC4 is powered up, it comes up in fail-safe mode by default. If signal is present, fail-safe
will disengage after RC4 determines a good signal is being received. This start-up delay is
approximately one second long. Once fail-safe is disengaged, it will re-engage after input signal
is absent for approximately one second. Advanced users can modify these delays to some extent,
although it is not recommended unless absolutely necessary.
Each of the four channels can be configured for various modes of operation. How a
channel behaves in fail-safe mode is determined by settings that are encoded within its
Channel Configuration Byte.
The mode of a channel is configured by setting or clearing bits within this byte which is
written to RC4 through the Write Channel Configuration command. Four configuration bytes are
required for a complete configuration; one for each channel.
The available modes of operation provide a versatile array of behavior patterns that can be creatively applied to many applications. An RC4 demonstration platform is currently under consideration to demonstrate how RC4 can be used to "train" a robot to perform a particular activity and to repeat that activity on command.
The table below lists the channel configuration modes that RC4 currently supports. It lists
the official name for each of the modes, and describes the behavior of each mode when fail-safe is
engaged or disengaged. Keep in mind that the different modes exist primarily to define how a channel
responds to changes in the fail-safe state. Therefore, certain states will exhibit the same behavior
as other states. In fact, there are only five unique states, or behavior patterns. Each unique
behavior is color-coded in the table for easy identification.
Channel Configuration Byte -- Per Channel Mode Name Behavior when... Fail-Safe is Disengaged (Good Signal) Fail-Safe is Engaged (Bad or No Signal) R/C Output responds to input, when present. Output is held at last good signal when signal is absent. Output responds to input, when present. Output is held at last good signal when signal is absent. R/C Fixed Output responds to input, when present. Output is held at last good signal when signal is absent. Output is held at last good signal received before fail-safe engaged. Input signal ignored. R/C Fail-safe Output responds to input, when present. Output is held at last good signal when signal is absent. Output responds to host. Input signal ignored. R/C Presets Output responds to input, when present. Output is held at last good signal when signal is absent. Output reverts to preset values retrieved from EEPROM. Command Output responds to host. Input signal ignored. Output responds to host. Input signal ignored. Command Override Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal. Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal. Command Fail-safe Output responds to host. Input signal ignored. Output responds to host. Input signal ignored. Command Protected Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal. Output responds to host. Input signal ignored.
Note that the behavior of Command mode is the same as Command Fail-Safe mode. This is because no
unique fail-safe behavior has been defined in the current implementation of RC4 for the Command Fail-Safe
mode. This may change in the future.
Also, if you closely analyze the behavior of the various modes, you will note that there is only a
subtle difference between R/C Fail-Safe mode and Command Protected mode.
In R/C Fail-Safe mode, the outputs are under host control when fail-safe is engaged, and as
soon as fail-safe disengages, the outputs respond to the R/C (PWM) input.
In Command Protected mode, the outputs are under host control when fail-safe is engaged, and
as soon as fail-safe disengages, the outputs respond to the R/C (PWM) input, too.
The
difference is in how quickly the channel switches between R/C and host control. In Command Protected mode,
while fail-safe is disengaged, the channel will return to host control the moment signal is lost,
and will once again return to R/C control the moment signal is regained. Note that if signal
is lost long enough, however, fail-safe will engage, leaving the host in control (in either mode).
To summarize: in R/C Fail-Safe mode, R/C control is only regained when fail-safe is
disengaged, and host control is only regained when fail-safe is engaged. In Command Protected
mode, any R/C (PWM input) signal will immediately override host control, and host control resumes
immediately when R/C signal is lost.
Command Override mode is very similar as well, except that fail-safe is not observed. The
channel output will immediately respond at any time to any incoming R/C (PWM) signal on the
input as long as a signal is present, then immediately return to host control the moment signal
is lost, even if only for a beat.
R/C Fail-Safe is the best mode for the most stable transition between R/C and host control,
since fail-safe will not disengage until a solid R/C signal is present, and host control
will not resume until fail-safe engages after a solid loss of signal. Engaging fail-safe through
the fail-safe-on-demand feature provides an additional level of reliability, because all PWM inputs
(except "Channel 5") are ignored in this state.
RC4 provides two command interfaces to the serial port, of which only one can be active at
any given time. Similar to how Robobricks have "shared" commands that are common among all
Robobrick modules, RC4 has a few commands that are common to both command interfaces. It is
through one of these common commands that the desired RC4 command interface is selected,
and this selection can be changed at any time. However, the distinction between the two
interfaces is extremely significant.
One command interface is designated the "Register Interface" (or "RI"). The other
command interface is designated the "Burst Interface" (or "BI"). The Register
Interface is best suited to slow hosts and all commands that return data return
only a single byte at a time. The Burst Interface is well suited to high-speed
hosts that can easily process longer data streams and will return multiple bytes
of data in response to many of the commands. In fact, one debug command (that will
not be available in release versions) currently delivers 176 bytes of data to the host.
[UPDATE: The Register Interface is being considered for complete removal
so that only one command interface remains. If this happens, an alternative mode of operation
will be implemented, providing Byte vs. Burst mode functionality for a single command set.]
The Robobrick identification bytes return information about RC4 in accordance with the Robobrick specification. The Robobrick ID for RC4 is 30 (decimal).
Shared RoboBrick Commands Command Hex Bit Number Send/Receive Description 7 6 5 4 3 2 1 0 Glitch FF 1 1 1 1 1 1 1 1 Send Glitch Command Glitch Read FE 1 1 1 1 1 1 1 0 Send Glitch Read Command g g g g g g g g Receive Returns 8-bit gggggggg glitch counter value ID Reset FD 1 1 1 1 1 1 0 1 Send ID Reset Command ID Next FC 1 1 1 1 1 1 0 0 Send ID Next Command i i i i i i i i Receive Returns next 8-bit iiiiiiii identification byte value Clock Pulse FB 1 1 1 1 1 0 1 1 Send Clock Pulse Command 0 0 0 0 0 0 0 0 Receive Returns zero - clock feature not implemented Clock Read FA 1 1 1 1 1 0 1 0 Send Clock Read Command 0 0 0 0 0 0 0 0 Receive Returns zero - clock feature not implemented Clock Increment F9 1 1 1 1 1 0 0 1 Send Clock Increment - No effect - clock feature not implemented Clock Decrement F8 1 1 1 1 1 0 0 0 Send Clock Decrement - No effect - clock feature not implemented
RC4 Robobrick Identification Bytes Offset Name Description RC4 Value 0 RBMajor ID Block Major Version Number 1 1 RBMinor ID Block Minor Version Number 0 2 BrickID BrickID 30 3 BrickRev Brick Revision (0=A, 1=B, etc.) 0 4 BrickFlags RC4 Features Code TBD 5 Reserved0 (use 0) Reserved for future use 0 6 Reserved1 (use 0) Reserved for future use 0 7 Reserved2 (use 0) Reserved for future use 0 8-23 UID0-15 128-bit Unique Identifier (Randomly Generated) Random 24 NameLength RoboBrick Name Length 3 25-27 BrickName Name of RoboBrick in ASCII "RC4" 28 VendorLength Vendor Name Length 13 29-41 VendorName Vendor Name in ASCII "CodeSmart.com"
RC4 Common Commands Command Hex Bit Number Send/Receive Description 7 6 5 4 3 2 1 0 Special Function E0 1 1 1 0 0 0 0 0 Send Special Function Command f f f f f f f f Send First 8-bit data byte ffffffff of function code(1) E0 1 1 1 0 0 0 0 0 Send Special Function Command again s s s s s s s s Send Second 8-bit data byte ssssssss of function code (1) Select Interface E1 1 1 1 0 0 0 0 1 Send Command Interface Selection & Baud Rate command. x x x x c b b b Send Select command interface c and baud rate bbb RC4 Mode E2 1 1 1 0 0 0 1 0 Send Set RC4 Operating Mode. x x e s c r b f Send Mode Selection Byte
(1) All RC4 special function codes are two bytes long. To perform a
special function, these two bytes must be written using the
Special Function command.
The command must be executed twice - once to write the first byte of the function code, and
again to write the second byte of the function code - before a function is executed.
Example: To save RC4 settings to EEPROM, four bytes must be written: E0 EE E0 02
Register Interface Command Byte: xxxwrrrr Bits Meaning xxx Ignored/don't care w Access Type:
0 = Read
1 = Writerrrr Register Address:
0000: Data
0001: Data Index
0010: Data Mode
0011: Channel Output Enable Bits
0100: Channel Command Mode Enable Bits
0101: Channel Passthru Enable Bits
0110: Channel Fail-Safe Enable Bits
0111: Channel Fixed Enable Bits
1000-1111: Reserved for future expansion
The Data Mode register determines what data within RC4 is addressed.
The Data Index register then specifies which relative byte is accessed
from that data. It represents an offset, where a value of zero indexes the
first byte. The Data Index value is automatically incremented after a read or
write operation and wraps around back to zero after the last byte is accessed.
The Data register acts as an indirect register. Reads and writes on
this register access the data that is referred to by the current settings in
the Data Mode and Data Index registers.
All valid values for the Data Mode register are listed, below (in hexadecimal). Writing
an invalid value to this register will leave its contents unchanged.
Data Mode Register Mode Meaning Access Data Bytes Rd Wr 00 Channel Data (channels 1 through 4) R/W 8 8 01 Channel Configuration R/W 7 5 02 Channel 5 Data R/O 2 2 03 Fail-Safe Operating Parameters R/W 4 4 04 Input PWM (Rx) Signal Configuration R/W 12 12 05-7F Reserved - Treated as invalid N/A N/A N/A 80-8F Invalid N/A N/A N/A
Some data modes are read-only (such as Channel 5 Data), in which case any attempt to
write to the Data Register will be ignored in these modes.
Unlike the rigid structure of the Register Interface, the Burst Interface command
structure is free-form. However, by convention, most commands are arranged so that
even-numbered command codes (bit 0 = 0) are read operations, and odd-numbered
command codes (bit 0 = 1) are write operations. Requirements vary for
each command, as some may require one or more additional bytes to
complete the command, and some will deliver one or more bytes of data
in return.
Some information available to the Burst Interface is not accessible through
the Register Interface. This is an implementation detail and may change before
the final version is released.
RC4 Burst Interface Commands Command Meaning Data Bytes 00 Read Channel Data 8 01 Write Channel Data 8 02 Read Channel Configuration Options 7 03 Write Channel Configuration Options 4 04 Read Channel 5 Pulse Width 2 05 Reserved 0 06 Read Fail-Safe Operating Parameters 4 07 Write Fail-Safe Operating Parameters 4 08 Read PWM (Rx) Signal Configuration 6 09 Write PWM (Rx) Signal Configuration 6 0A Read Channel 5 Function Selection 1 0B Write Channel 5 Function Selection 1 0C Reserved for future expansion 0 0D Reserved for future expansion 0 0E Read EEPROM Status 1 0F-CF Reserved for future expansion 0 D0-DF Reserved for testing & debugging 0
The hardware consists of a circuit schematic and a printed circuit board.
The schematic for RC4 is not yet available.
The printed circuit files for RC4 are not yet available.
The parts list for RC4 is not yet available.
The software for the PIC16F628 microcontrollers at the core of RC4 is
not available. Pre-programmed chips will be available from the author
at a later date, and they will be code-protected. Sorry!
Software for testing and controlling RC4 is not yet available.
Current pending hardware and software issues are noted here.
The following is a list of hardware design issues regarding the current prototype:
The following software issues are under consideration (many of these points may not make sense to anyone but me):
Documentation for RC4 is not available at this time, but the following is planned:
