Sensors Mag

Selecting a Network Protocol for Robotic Machine Control

August 1, 2005 By: Dan Mannisto, Machine Bus Corp. Sensors

Using a distributed control architecture for robotic machinery often proves to be an efficient and elegant solution, but beware: There are a number of critical decisions to make when selecting a suitable network protocol.

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.

1 2 3 

Add Comment

IIoT University

Deep Learning for Vision Using CNNs and Caffe: A Hands-on Tutorial – 9/22/16 – Cambridge, Mass


Sensors 2017 Call for Speakers

Sensors Midwest



Twitter Feed

Find It Fix It Forum

Sensors invites you to join the Findit-Fixit Forum, where you can get answers to your sensing questions—concerning technologies, products, methods, applications, and services--and also offer help to your fellow engineers. The Forum covers all kinds of topics, from the basics to the extraordinary.

Join the discussion!

© Copyright 2016 Questex, LLC. All Rights Reserved. Sensorsmag. Privacy Policy | Terms of Use

If you are having technical difficulties or considerations, please contact the webmaster.