It’s non-sense to compare ROS and RT-middleware
RT middleware is a collective term that means the middlewares for robots. Accurately speaking, the RT-middleware means the middleware which is based on the communication standards defined in the RT-middleware project, so currently, RT-middlewares are “OpenRTM-aist”, “OpenRTM.NET”, “miniRTC (and RTC-Lite”, “Gostai-RTC”, “OROCOS”, and so on. Therefore, it’s non-sense to compare ROS and RT-middleware because ROS means both the communication protocol and its implementation.
Currently the RT-middleware’s standard is one (RTC specification version 1.0), but some standards around the deployment are defined and shown soon.
It’s really important to have “standard”. If your middleware is based on the RT-middleware’s standard, it becomes quite easy to interconnect to the other middleware like OpenRTM-aist, because the definitions of the state machines and interfaces are the same.
ROS has a communication standard like XML-RPC API and TCPROS, but in the official website, the communication protocol’s forward/backward compatibility is not mentioned. I am sure that more abstract standard of the communication for ROS nodes makes it easier to develop more portable, lightweight ROS implementation.
OpenRTM and ROS
Here, OpenRTM and ROS are compared.
Distributed Control System
Both ROS and RTM are distributed control system.
In the distributed system, if one module are ceased to stop, the whole system might not fail (robustness). If the interface is commonly defined, the module can be re-used by the other developer easily.
OpenRTM-aist is RTC
- Each modules are named as RTC (Robotics Technology Component).
- RTC has “Port(s)” to connect to each other
- One process can have prural RTCs.
- Various languages are available and connectable
- Each modules are named as Node
- One process has one node basically.
- ROS nodes communicate pub/sub model.
Platform and Language
Both ROS and RTM are middleware which hides the implementation language and make it possible to connect with each other if different platform and languages are used.
OpenRTM-aist has a lot of porting
- Officially, Windows, MacOS, Linux (FreeBSD) are supported
- Some reports VxWorks, Toppers, Android, and so on
- C++, Java, Python are supported. OpenRTM.NET supports .NET framework
- My RTC-scilab enables you to make RTC by using scilab language.
ROS is for Linux
- ROS is for Linux. Of course Windows (cygwin) and MacOS is partly supported.
- The merit to use ROS is command-line tool and fast-and-interactive prototyping so Linux is enough and suitable
- C++, Python, and Java (rosjava) is supported.
Supports for languages are same in both platform, but OpenRTM.NET is much more universal tool.
OpenRTM-aist has more available platforms. Maybe someone says “Windows is necessary for robot system?”, but I think there is no reason for Linux either. Visual Studio is really sophisticated developmental environment isn’t it?
OpenRTM project provides some graphical development tools. Most of them are eclipse plug-ins, but they enables “designing”, “skeleton-code-generation”, “coding”, “documentation”, “compile”, and “deployment service”.
RTC-builder is a skeleton-code-generator. The code is OOP code and RTC’s code is a class implementation. The class is a class extended the RTC’s basic class (DataFlowComponent).
You should modify some ‘call-back’ functions.
RTC has no main function. Some initialization callback functions are prepared. In most robotic system, control is executed in periodic timing, so on_execute function is periodically executed. You can modify the on_execute code.
RTC can be launched from Manager. Manager is shown in the later section.
ROS nodes are managed by “Package”.
Package includes makefiles and dependency definitions, message definitions, launching setting, and documentation.
roscreate-pkg command helps to create package. rosrun command is really universal tool for lanching ROS node.
rosmsg, rossrv, rostopic and rosservice provide monitoring functions for Topic and Service.
In ROS, developers must create package first. Then, add node’s codes. rosmake command automatically generates makefiles for the node’s code, so the prototyping is really easy and fast!
However, the skeleton code is not generated. Developers must create their own nodes from scratch.
OpenRTM-aist, DataPort and SErvicePort
- OpenRTM-aist has DataPort and ServicePort
- DataPort sends/receives datas
- DataPorts which have the same type can be connected
- Original datatype can be defined by IDL definition
- ServicePort provides call and return sequence like CORBA remote service call
- Configuration is a function for configuring the RTC’s behavior.
ROS, Topic and Service
In ROS, data transportation is realized by “Topic”. Topic is like cloud service. Some nodes publish their topics, and some nodes subscribe their topics. In ROS world, no connections between nodes are thought (actually there are connections but you do not have to think of it;-)). If developers want to publish the same type topics, use name-space.
Service is provided for calling sequence. Topic can not provide ‘return value (result of calling)’ but service does.
Parameter is a similar function to configuration in OpenRTM-aist.
There are no significant difference between two. Data communication service is DataPort and Topic. ServicePort and Service in ROS provides the same type service;-)
Someone think that the pub/sub model is easier because their is no connecting process, but the remap (name-space) process is also annoying.
Both remap in ROS and connection in RTM can be automated using roslaunch and rtshell.
In OpenRTM-aist, RTC Daemon is provided. RTC Daemon is automatic loader of RTCs. Just modify the configuration file of the RTC-daemon. The Manager in the OpenRTM-aist library is the core function of RTC daemon, so you can modify the RTC-daemon as you like.
After launching the RTCs, OpenRTM system needs the connection process but RT System Editor and rtshell will help it. RT System Editor is GUI tool which helps manager’s functions, connections, activate/deactivate RTCs, and so on. rtshell is command-line tool. The rtshell can use the output file of the RT System Editor. Therefore, usually, in the developmental process, developers uses RT System Editor, and in demonstration or deployment process, use rtshell and shell (or .bat) scripts.
roslaunch provides execution of ROS node and remapping definition. ROS is much easier in the deployment process.
The execution context is the advantageous point of OpenRTM-aist. The execution context provides the state machine control service. PeriodicExecutionContext provides periodically called function (onExecute). Even when the RTCs are executed, the execution context can be replaced, so if your RTC is developed with the normal periodic execution context, your RTC’s execution context can be changed to the real-time execution context in the realtime Operation System like ART-Linux. This framework is also useful in the simulation. Your controlling algorithm can be launched in the simulated world. The extra trigger execution context can synchronize the simulated time in the simulator.
Summery: What is the ideal software platform for robots?
Considering these comparisons, we would result that ROS is easy tool for hacking and prototyping, and OpenRTM-aist is appropriate for water-fall type development and deployment. Actually, both middlewares are just framework so these characteristics are derived from the surroundings (tools and services).
I think in the recent robotics research fields, we are still proto-typing steps. I think the needed middleware should be more hackable, easy to handle, fast, and suitable for agile developments.
On the contrary, we should think we must give some treasures (legacy) to our junior researchers. Considering the lifespan of the softwares’ codes, RT-middleware might be more suitable to give our legacy to the younger people. In the RTM, coding styles are defined, which can be helpful for premature, young, and fresh student coders to understand.
Currently, I think the ideal platform software for robots is….
1. Can test robots in 15 minutes.
2. Customizable for intermediate users.
3. Can access the lowest layer.
The 1st point is very important even if the user has high technical knowledge, because it can be stressful for both the user and their boss if the robots do not move for several days;-)
The 2nd point can be a difficult point if the manufacturer does not have enough software knowledge.
In this step, it is not necessary to reveal all of the product’s function. Simple and comprehensive interface is needed.
Maybe some of the users in the 2nd step are not satisfied because some functions are still hided.
Therefore, the 3rd level access is desired. The uses in this step have high level understanding for the products and their goal is very clear, so the manufacturer can easily deal with them. Some open-source policy would be useful for this step. (Don’t think that the open-source policy is enough.)
Note that applying the middleware to your product can not be the solution, but they will be a framework to prepare those steps.
For example, imagine that you are providing the software component with open-source policy.
Some example software is provided in which the component is used. These examples must be tested in 15 minutes or so (step 1).
Then, the users try to re-use the component.
The component does not have to equip complete accessibility to your product’s function.
Then, if the users are not satisfied in your component, they will read your source code and extend its interfaces as they like.
This is very simple and ideal story, but I am sure that the middlewares must be ready for providing these frameworks…
I think that we need…
- Hacking, Agile tools for RTM
- Strict, Comprehensive standard for ROS