ROS for .NET Fans- High Level Architecture Overview
By Anna Sandler
Let’s talk about ROS (Robot Operating System) architecture.
The purpose of this tutorial is to cover the high level of ROS architecture and
get to know the basic ROS terminology.
The next tutorial will cover ROS concepts and workflow in deeper level- stay tuned.
ROS, who?
If you really ask this question- go away! :)
You might want to look here,
and come back after you’ve prepared your homework! :)
Installation
Please refer to this tutorial in order to learn how to install ROS or to get a ROS
pre-installed snapshot.
What is really ROS?
Try to look at ROS as a Service Oriented Architecture (SOA) environment for robots.
This environment can run on the robot itself, on top of its existing operation system,
or it can run on a remote computer.
The idea behind ROS is to standardize robot-apps™ development, code share, code
reuse, and enable a better interoperability among different apps and robots.
The implementation of this vision is very simple, each logical unit holds its own
service (process) which is accessible over the network.
These processes are called nodes in ROS terminology.
It sounds simple, right?
So how these logical units communicate?
Communication
Processes (nodes) communicate with each other by passing a strongly-typed
data over the network.
Communication can be either synchronous (blocking calls) or asynchronous (like an
event-driven programming).
Synchronous communication is done by extracting an interface for each method that
is opened for inter-processes communication. This method interface is called service.
Asynchronous communication is done by offering an event handler. Nodes that are
interested in being notified whenever the event is raised should be registered to
that event.
This event handler is called- topic.
Node must define a service or a topic
or both to allow other nodes to communicate with it.
Nodes, topics and services must be registered
at the orchestration level (master), which holds the complete list
of all the processes and their communication points in order to allow this kind
of communication.
Run time data sharing
Data can be shared by passing a strongly-typed data (message or
service message) between processes (nodes), synchronously
or asynchronously.
Message data type is basically a struct that its properties can be
primitive data types (int32, string, bool…), arrays or other messages.
Topic-base communication (asynchronous) uses a message
data type to pass data from the publishing node to all its subscriber
nodes.
Service-base communication (synchronous) uses a service message
data type to pass data among nodes.
Service message contains two massages:
- Request argument's message- the node that calls the
service initialize the request arguments.
- Return parameter's message- the node that offers the
service initialize the return parameters.
There is another option for a run time data sharing among nodes- a
global dictionary (key-value pair) heap-style object, accessible to all nodes.
This component is called parameter server.
Nodes are welcome to use unlimited CRUD operations (http://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
on the parameter server.
Packaging
All the Nodes that are servicing the same purpose should be organized
into one project. This project is called a package.
In addition to the nodes, a package contains a configuration
file with package description, author, license and more, multiple nodes
launch configuration file, compilation configuration, message type's
definition, service message type definition, auto generated files
(such a header files if it is written using CPP) and more.
According to Willow Garage’s well said quote:
“ROS packages follow a "Goldilocks" principle: enough functionality to be useful,
but not too much that the package is heavyweight and difficult to use from other
software.”
Stuck is the master piece of your work, the released version, ready
for installation. It is the solution that contains all your projects (packages).
Additional to packages, stuck also contains configuration
file and binaries.
Logging
There are two options for logging:
- Logging messages for screen output- debug, info, error and fatal messages.
- Log file- this file is called bag file. Bag file purpose
is to record all or partial messages from one or more topics. This information can
be replayed.
Summary for ROS terminology
- Node = A process;
- Service = A method interface (ASMX style) for a synchronous communication
between nodes;
- Topic = An event handler for an asynchronous communication among multiple
nodes;
- Message = A struct data- type that is passed to the topic;
- Service message = A Request- and- response messages that is passed
to the service;
- Master = An orchestration (Mapping table style);
- Parameter server = A global dictionary (heap- style) for data sharing
among nodes;
- Package = A project. Organizational unit for nodes, configuration
and more;
- Stuck = A solution. Organization unit for packages, configuration
and more;
- Bag = A logger for messages that are passed on a specific or multiple
topics;
Ros advantages
- This type of design allows a wide share of logic units among different applications.
- New functionality can be easily added to existing robot-apps, by adding new processes
(nodes) without the need of analyze a legacy code.
- Processes that are written in different programming languages can communicate using
the same protocol.
- Processes can run on various ROS platforms (robots) and be accessible across the
network.
- Most of the existing packages are licensed under BSD license that allows the user
distribute, change, reuse or commercial usage.
- More…;
ROS open issues
- Security;
- Intellectual property protection;
- Multi robot support;
- Variant robot platforms reuse;
- More…;
wifes who cheat
cheat women women who cheat on their husband