The previous version of the MirrorLabs framework was centered around the ROS# (ROS-Bridge) extension released by Siemens. While this approach works (mostly) reliably within a local network, it does lack in flexibility. Flexibility not only in terms of adapting it to custom situations but also in using via the world-wide-web (WWW).
First and foremost, the ROS# integration will remain part of the MirrorLabs release package! Some of the functionality it provides are extremely useful for starting a new project, namely the transfer of object files (3D-model of the robot with correct angular adjustments). However, to mitigate the limiting factors, an alternative method for data communication is in development. Using MQTT (Message Query Telemetry Transfer), it is not only possible to transfer all kinds of data using webservers but also to integrate non-ROS devices seamlessly. MQTT is a light-weight message distribution system which based around the idea of having a central computing unit (“Broker”) which handles the distribution of data between publishers and subscribers (pub/sub) via dedicated topics. E.g. a publisher sends a data package A to the broker for topic B, the broker then forwards the data package to all devices subscribed to topic B. While ROS is operating in an almost identical fashion, the major difference is the added broker within MQTT. When using a ROS system, there is commonly a roscore component operational on the local machine controlling a robot. This roscore component is the ROS-equivalent of the broker in MQTT, however, the MQTT-Broker can be deployed anywhere, on the same PC, somewhere in the local network or using a webserver. In particular, the later two options make it a viable alternative to ROS#! (E.g. a smart factory could theoretically be controlled remotely!)
Additionally, the integration of ROS# in unity can be quite cumbersome if anything non-standard is in development. While it is possible to do so (it is open source), it may require advanced knowledge to get started with the matter. This is a major focus for the MQTT-alternative! The aim is to maintain the speed and reliability of ROS# while lowering the entry level for users. Besides a multitude of examples, functionalities to decrease the amount of coding necessary to develop custom projects has priority. With increasing amount of development an equivalently increasing amount of standard/common devices will be included, such as sensors (temperature, pressure, proximity, etc.), sub-systems(Grippers, handles, control surfaces etc.), and many more.
So far the development is showing first fruits, where most of the already demo-builds included in previous Mirrorlabs updates could be realized using the alternative MQTT framework. Furthermore, we tested our approach for simplification by allowing a student (non-software related course) to use a preview package for developing his prototype. After a brief introduction he was able to use it properly out of the box. In contrary, when using ROS# a more experienced developer required a multitude of the time to reach an equivalent result to the students work.
Another advantage of using MQTT is the relatively simple integration of an MQTT extension in ROS. The open-source mqttBridge for ROS can be integrated by simply downloading it and adjusting the .config and .launch files (which is a matter of minutes).
Comments