Design Requirements and Framework For A Robotic Infrastructure System
Design Requirements and Framework For A Robotic Infrastructure System
on CIRCUITS, SYSTEMS, ELECTRONICS, CONTROL & SIGNAL PROCESSING, Dallas, USA, November 1-3, 2006 37
www.uab.edu
Abstract: Robotic Infrastructure Systems will soon become an integral part of industry, offices, and our
homes. They will be able to be controlled remotely from the Internet, and have interfaces to many systems and
databases. However, current robots are mostly used for stand-alone manufacturing operations, toys, and
scientific research. In order to exist as part of the critical infrastructure, robots must be able to interact with
multiple users, authenticate users, track usage and users, and provide feedback to the user. The critical element
that will allow such functionality is the communications channel – which will most likely be the Internet. To
make proper use of the Internet, system architecture and protocols must be developed to support robots and the
unique functions they will provide to the users. This paper addresses the issues that must be accounted for in
developing architecture for robotics within the infrastructure. These issues are the basis for design decisions in
developing robotic infrastructure systems.
and continue to be developed, but mostly as cameras, thermometers, location detectors (of the
scientific experiments. It is based on these entire robot or the robotic manipulators), and many
experiments and the scientists’ conclusions that the other types. In order to provide these functions to
authors have developed the set of design issues that the user, RIS will include communications,
will need to be addressed when developing databases, actuators, and sensors. These may all be
architecture and protocols for robotic systems. self-contained on a robot, or they may be distributed
These systems have made use of technologies, amongst many elements that makeup the system.
protocols, and standards as they have become With this working definition, the following
available - including HTTP, CGI (common gateway characteristics are listed for RIS. Many of these are
interface), JAVA, and XML (Extensible Markup the basic characteristics of individual robots.
Language), VRML (Virtual Reality Markup
Language), and CORBA (Common Object Request
Broker Architecture). The development of these 3.1 Functions
systems has helped to identify two critical issues Functions will include manipulation and movement
involved in Internet controlled robotics. via actuators, feedback to users via force feedback
Security – Being on the Internet allows everyone or haptic controls, data collection or sensing, and
access to the communications channel. Robotic communications (to the controller, peers, or a slave).
systems for experimentation and science (such as
some listed above) might allow everyone unlimited
3.2 Control Architecture [4]
access. But, robotics systems in the infrastructure
• One to One – One user controlling one robot.
may have moving actuators that can be dangerous in
the wrong hands. Also, like other Internet systems, • One to Many – One user controlling more than
some robots may deal with sensitive data, such as a one robot.
medical diagnostics robot. And since robots may be • Many to One – Many users controlling one robot.
designed for remote maintenance, the use of • Many to Many – Many users controlling more
different security privileges will become an issue. than one robot.
Time Delay – Depending on the system, round
trip delays can be in the order of seconds for 3.3 Control Modes [4]
standard Internet systems to perhaps hours for space • Direct Control - User controls every single
based robots. This time delay may put the user in a action of the robot through primitive commands.
“move-and-wait” strategy. Further complications • Supervisory Control – Robot operates in an
with the Internet as the medium are the uncertainty autonomous mode and interacts with the user
of the delay or even the uncertainty of packet arrival when the robot encounters a situation it cannot
at all. Therefore robotic systems may have similar handle.
issues to VoIP (Voice over Internet Protocol) or • Learning Control – The robotic systems develop
Video over the web, in which the QoS (quality of effectiveness through learning either with the
service) becomes a key issue in the protocols. Like help of the user or through preprogrammed
VoIP, robotic protocols will not be able to rely on learning algorithms. Therefore, the robot might
the standard TCP/IP protocols alone to provide this begin in the direct control mode and move over
QoS. Furthermore, the delay based QoS parameters time to an autonomous system.
for robots will likely be different than those for
voice or video.
When robots move to widely deployed infrastructure 3.4 Administrative Features
systems, other issues arise. Some of these will be • Security – Authenticate users. Access privileges.
developed in section 5. Allowing different levels of security to different
users. Encryption algorithms.
• Billing – Since the RIS will be infrastructure
systems, usage based billing may be required.
3. Characteristics of Robotic Systems The RIS will have billing parameters and
Before getting into the characteristics of robots
protocols.
themselves, the definition of an RIS must be given.
• Data collection and data queries – Data collected
RIS will consist of all the elements required to allow
for one user could be retrieved when another user
users to physically manipulate in the remote
makes the same request at a later time. The
environment and collect data from a variety of
system will need to be able to store and query
sensors. Sensors would include devices such as
data. This storage of data could also be a security
Proceedings of the 5th WSEAS Int. Conf. on CIRCUITS, SYSTEMS, ELECTRONICS, CONTROL & SIGNAL PROCESSING, Dallas, USA, November 1-3, 2006 39
issue since one user might not want another using microscope and view slides of patients and make a
their data. diagnosis. This system allows a single pathologist to
cover several smaller cities without having to drive
from hospital to hospital.
4. Future Infrastructure Robotics
The infrastructures of existing systems yield some
important questions for robotics engineers. For 5. Design Issues for Infrastructure
instance, the medical field is based on medicine and Robotic Systems
medical practitioners. But in addition to the skilled The list of design issues below is based on the
workforce, a medical infrastructure containing MRI, previous research on Internet controlled robots and
CAT scans and other diagnostic and medical experiences from other infrastructure systems. Some
facilities has become standard to the practice of of theses issues have been discovered by
medicine. Similar situations can be seen in many researchers, while other issues are new
fields such as the transportation, communication, contributions. They have been compiled as a list of
and power industries. Industries have become highly design issues.
dependent on their infrastructures. The business
arrangements between the owners of the
infrastructures and the customers of the businesses 5.1 Establishing a communications channel
are critical to the existence of the relationships. It is expected the connections to RIS will be
Doctors do not typically own the advanced accomplished via the Internet, and therefore via the
diagnostic tools; they use the tools of service TCP/IP protocol. The initial connections and
providers. These service providers in turn bill the responses might be no different than typical Internet
doctors or the patient directly. Likewise, the airlines connections, but other protocols will be needed
do not own the terminals and often do not own many immediately after the connections are established.
of the services needed to keep the airlines running.
Remote controlled robotics will soon be playing
5.2 Security
a larger role as a type of infrastructure. Consider for
Users must be validated. Also, different levels of
example a Mars rover robot. If scientists could
permission will need to be established. These levels
connect to this robot through the Internet and
of security are no different from typical Internet
perform their own experiments, NASA could bill the
connections to databases and servers, but with
scientists for time used. While sitting at his desk a
robotics new issues of security do arise. One issue is
scientist could connect to the rover, learn the billing
related to having a robot perform a test and analyze
structure for time and functions, and then remotely
results. The system may need to store results for
dig into the dirt on Mars and do his own chemical
future use. Unlike a database system, where query
analysis on the soil. The sensors on the robot would
results can all be dumped and additional duplicate
be used to collect and send the resulting data back to
queries can be run with minimal overhead, robotic
the scientist, along with billing information. To
systems might have physically moved to another
perform such a scenario, several things must happen.
position and therefore cannot easily reconfigure
The scientist would have to be able to establish a
itself to run a test again. However, one user might
connection and be authenticated. Then, the scientist
not want their tests results shared with anyone.
would have to learn about the capabilities of the
Rules must be in place to determine the security
robot through some sort of service discovery
issues of sharing test results.
protocol, such as exists in Bluetooth [5]. The current
state of the robot, the position of all of the robotic
movements, the range of motion, the sensors on 5.3 Service discovery
board and their range and sensitivities would all Once connected to a RIS, the user will need to be
have to be communicated to the user. able to determine the types of services offered by the
While this interplanetary robotic control over the RIS. What sensors are available? What actuators can
Internet might be a ways away (Jet Propulsion be used? What are the ranges of motion? What are
Laboratory does have in the works an InterPlaNet the sensitivities of the sensors? Is force or haptic
plan [6]), many other situations might call for such (sense of touch) feedback available? What are the
functionality. The University of Alabama at initial positions or conditions of the actuators,
Birmingham was involved in a Telepath [7] project sensors, and the entire robot itself? Billing
in which a pathologist would remotely access a information might also be provided during service
discovery.
Proceedings of the 5th WSEAS Int. Conf. on CIRCUITS, SYSTEMS, ELECTRONICS, CONTROL & SIGNAL PROCESSING, Dallas, USA, November 1-3, 2006 40
5.4 User interface chemical analysis after taking a soil sample? Should
The user interfaces connected to RISs should the RIS decide to do it while waiting on that
automatically be rendered based on the type of command? Or does it simply hold the soil until told
interface the user has (PC with a web browser, PDA, differently, therefore blocking other requests?
cell phone, other). During service discovery, the - System diagnostics and self-healing. The systems
user might have the option of choosing of with should be designed with failure in mind, but at
which sensors and actuator he wants to interact. The different levels depending on how easy it will be to
user interface could then be automatically rendered obtain access and the cost of down time. Clearly
indicating the sensors and actuators and the initial space travel robots must have a great deal of thought
positions. into using self-healing and remote diagnostics and
repair. But all robots in the infrastructure will also
5.5 Multiple users queue need some level of remote maintenance to maximize
The RIS would need to be able to interface with availability.
multiple users. Similar to databases and other - Maintenance. How will software updates and
systems, but now the functions are not logical data other administrative activities be performed?
but physical systems. The physical nature of the RIS - Virus Control. What new types of viruses will
can create a great deal of latency since physical exploit RIS?
operations will likely take longer than queries. A - Batch processing and user scheduling. How will
session might also need to be 100% complete with the robot schedule users? Will it allow batch
the previous user’s session first before moving to the processing and notification of results as mentioned
next. Alternatively, some robotic functions would be previously? Or will the system notify users of a
mutually exclusive – such as a single arm to dig in scheduled time slot to access the system? How will
the dirt on Mars and a grasping of the hand on the these notifications take place? Email or other
arm. If user A is using the arm, then user B could TCP/IP based protocols?
not use the tools to grasp. Other functions might be
independent. For example, user A might have used
the robotic arm to pull a dirt sample, which might 6. Requirements Framework
have been given to another internal actuator to do Using the design issues and the potential future of
analysis. Now the robotic arm is free, but not the robotic systems, a framework of requirements can
whole system. Scheduling multiple users will be be developed.
more complex in this system than databases. Simple
FIFO or LIFO algorithms will not work. Additional • IP based – The main communications model for
complications arise since the entire robot might a new protocol would have to be IP based.
move, such as in the Mars rovers. If three requests • Standards – Since robots will be prevalent in
(x, y, z) are in queue to perform a soil analysis, but networks, a standard protocol model must be
request x and z are in the same physical location of built and adhered to by developers. This standard
the robot, then the system would want to perform would likely come from a group such as IEEE or
these first before performing request y. System the IETF.
specific optimization and resource allocations must • Protocol Suite – Since many elements have to be
be developed, yet common protocols must exist to taken into consideration (as covered in the paper)
interface these parameters to users as needed. the protocol will likely be a suite of robotic
protocols. The individual protocols will address
5.6 Other Concerns the various issues. One protocol may be required
- Completion of session. How do you know when a for delay control while another access to
session is complete? Will the user need to request common sets of databases and yet another for
the time slots, or detail all the operations before the service discovery.
first operation is performed? • Platform independence – The protocols must be
- Billing. Perhaps the systems will have several able to work under a variety of
billing policies. Billing per time used or based on hardware/software/operating system platforms.
types of functions performed. One thing is clear; an • Safety considerations – Safety concerns must be
RIS will have monetary value. built into the protocol which would allow the
- Learning algorithms. Since latency will always be communication of safety concerns (mostly due to
an issue, can learning algorithms be used to movement) over the protocol messages. Safety
determine frequent patterns? Do users always to a
Proceedings of the 5th WSEAS Int. Conf. on CIRCUITS, SYSTEMS, ELECTRONICS, CONTROL & SIGNAL PROCESSING, Dallas, USA, November 1-3, 2006 41
7. Conclusion
This paper has attempted to examine design issues
that will have to be addressed as robots move from
stand-alone system to become a part of an
infrastructure. Many of the design issues are similar
to those found in the development of other
infrastructure systems, such as databases and
networks. Yet the RIS brings new design challenges
along with their many opportunities.
References
[1] Goldberg, K., Siegwart, R., Beyond
Webcams: An Introduction to Online Robots, MIT
Press; 1st edition, 2001.
[2] Goldberg, K., Gentner, S. et. al., The
Mecury Project: A Feasibility Study for Internet
Robots. IEEE Robotics & Automation Magazine,
pgs. 35-40, March 2000.
[3] Backes, P. G., Tso, K. S. et. al., Mars
Pathfinder Mission Internet-Based Operations Using
WITS, Proceedings of the 1998 IEEE International
Conference on Robotics & Automation, pgs. 284-
291, 1998.
[4] Luo, R.C., Su, K.L. et. al., Networked
Intelligent Robots Through the Internet: Issues and
Opportunities, Proceedings of the IEEE, Vol. 91,
No. 3, pgs.371-382, March 2003.
[5] Bluetooth Special Interest Group (SIG),
www.bluetooth.org, Last accessed March 1004.
[6] InterPlaNetary Internet Project,
www.ipnsig.org, last accessed March 2004.
[7] Grimes, G. J. et. al., Remote Microscopy for
High-Resolution Real-Time Interactive Pathology,
Advanced Imaging, p13ff, July 1997.