Robotic machines are becoming a popular solution to a variety of problems. Examples include unmanned vehicles of various types that carry out military operations, surgical robots that assist in the operating room, robotic mining equipment that performs work too dangerous for human beings, and intelligent machine tools that save money while increasing quality. This new generation of robotic machinery differs radically from older industrial robots developed in the second half of the twentieth century. While the stereotypical industrial robot is a machine operating in a highly managed environment using open-loop control techniques, these newer robotic machines depend heavily on closed-loop control and often operate in unmanaged environments.
 |
Choosing Wisely
Robotic machine applications are becoming increasingly complex and, as a result, they often require a large number of sensors and actuators, each of which may have different interfacing requirements. This makes it difficult to find a single processor with the right combination of capabilities. An increasingly popular approach is to use a distributed architecture, where control functionality is spread among many processing units, resulting in a design that is typically more flexible, extensible, and reliable than a centralized control architecture.
You can implement a distributed control system using almost any form of communication and there are any number of network protocols to choose from (see sidebar "The Players"). It is tempting to grab whichever protocol you are most familiar with or use one of those supported by your PC, but many of these network protocols were developed for purposes other than embedded control and often don't meet the needs of most robotic applications. To increase your odds of a successful choice, consider the following factors when selecting a protocol for your distributed control system.
Topology and Communication Model
The network topology and communication model used by a protocol has a big impact on reliability. Network topology describes the physical arrangement of processing nodes in a network and a communication model describes the logical arrangements. Watch out for protocols that introduce single points of failure into your system. Any time a network depends upon a single component to maintain communication, it is vulnerable to systemic failure.
A bus topology is generally the most reliable because it doesn't depend on active components to propagate the data. This is not the case for some of the other topologies. For example, a star topology uses active components such as hubs, switches, and routers. If any of these components fail, then entire sections of the network will become useless.
Some network protocols dictate a communication model in addition to a topology. For example, the USB protocol requires a host controller to manage the network. If the host controller fails, then the entire network will fail. In the domain that USB was designed for, this is not a problem because the PC is always the host controller and if the PC fails then a functional network isn't of much value. The same is not true for a robotic machine, where this type of failure is unacceptable.
Maximum Frame Size
Some protocols specify the maximum amount of data that any one node can transmit at a time and this is important to consider when evaluating the degree of determinism a network protocol provides. Determinism describes how much certainty a designer can have that a specific operation will complete within an allotted period of time. The maximum frame size puts a limit on how long any one node can monopolize the network. Designed properly, an embedded control application rarely requires more than a few bytes to be transferred between nodes at a given time. For these reasons, it is best to stay away from protocols that either have a large maximum frame size or don't dictate one at all.
 |
Medium Access Control
Medium access control describes how nodes gain access to a network and what they do when there is contention (i.e., multiple nodes trying to communicate at the same time). If a protocol does not specify a method of medium access control then you will have to implement a method yourself. The typical homegrown implementation is some form of master/slave communication model. This can affect reliability because, as we saw during the network topology discussion, a failed master will cause the entire network to fail.
The method of medium access control also has an impact on determinism. A number of protocols implement destructive methods of medium access control where, when two or more nodes attempt to communicate at the same time, the entire frame is destroyed and communication is attempted at a later time. Predicting how often these collisions can occur is difficult, if not impossible, and under stress these systems can degrade, which quickly reduces the amount of transmitted data to a trickle.
Error correction. The environment inside most machinery is physically and electrically very harsh. A machine's electronic hardware can fail or its performance can degrade for any number of reasons and in the world of robotic machine control, this can mean disaster. Errors can take a number of forms, including data corruption, frames that don't reach their destination, and faulty nodes that disrupt the protocol. Avoid protocols that lack any form of error correction or cover only a fraction of the possible error conditions because if error correction isn't dictated by the protocol you're using, you will have to implement your own to make the system more reliable.
Implementation. Some protocols are implemented solely in hardware while others require a combination of hardware and software. Protocols that are implemented only in hardware have a number of advantages: They are typically faster and more reliable, they place less of a burden on your processing nodes, and they are cheaper than buying or developing a software protocol.
Some protocols are largely implemented in hardware but require an additional software component to be of much use (Ethernet, for example). While Ethernet is largely implemented in hardware it requires an additional protocol such as TCP/IP or UDP for it to be of much use.
Broadcast Communication
Broadcast communication allows you to address many nodes in the system at the same time. This may seem like a "nice to have" feature at first glance, but the first time you have to synchronize activities using a point-to-point protocol you will realize how useful it really is. It is impossible to achieve true node synchronization using point-to-point communications because messages must be sent to each interested node individually. For example, suppose your application requires you to synchronize an activity across three nodes. By using a protocol that supports broadcast communication, you can send one message and have it received by all three nodes at roughly the same time. A point-to-point protocol requires you to send an individual message to each node, one right after the other. The trick here is to send all three messages fast enough to maintain the illusion of synchronization.
 The Players |
Beware of protocols that have some form of broadcast ability but were designed primarily for point-to-point communications. The broadcast capabilities of these protocols are often inferior to those found in a protocol based solely on the broadcast principle. For example, Ethernet with IP is designed primarily for point-to-point communications. It does have broadcast capabilities, but it is limited to one address per subnet.
Maximum Number of Nodes
This feature depends largely on the requirements of your application. If you are searching for a good all-purpose protocol then pick one that can support approximately thirty to one hundred nodes. Fewer than thirty may be too limiting and over one hundred is usually unnecessary. If your application requires more than one hundred nodes, it's probably better to partition your network into segments to maintain speed and reliability.
Microcontroller Support
One of the reasons for choosing a distributed control architecture is to spread functionality among many small, specialized processors. There are some protocols that make using a microcontroller rather difficult, e.g., IEEE 1394. Watch out for protocols that don't have built-in microcontroller support or that use controller ICs requiring a large number of I/O pins from your processor. Also, if a protocol requires a software implementation, pay attention to the amount of memory and processing power the software will consume.
Maximum Data Transfer Rate
Since most embedded control applications don't need more than a few bytes of data to be communicated at any one time, data transfer rates are not an important consideration from a data volume perspective.
Some applications do have extremely tight real-time constraints and in these cases faster data rates will reduce latency. Be careful not to trade speed for other features that affect determinism and reliability. Most of the protocols with extremely high bandwidths are not considered deterministic or reliable by embedded control standards.
Maximum Network Length
Maximum network length is seldom a consideration. Most protocols will support lengths that exceed the requirements of the typical embedded control application. Do note, however, that maximum network length and maximum data transfer rate are inversely proportional, meaning that you cannot have both at the same time.
Summary
Selecting a network protocol for your distributed control system is a decision that will have both short- and long-term repercussions. By taking into consideration many of the selection criteria described in this article, you can eliminate many of the mistakes learned by others through trial and error.
Dan Mannisto is President of Machine Bus Corp., Evanston, IL; 847-864-1030, [email protected], www.machinebus.com.