 Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags. |
Best Practices
Description: In this tutorial you will learn how to search and use ROS best practices.Keywords: Quality Assurance Best Practices
Tutorial Level:
Contents
Context
Several contexts can be envisioned here:
- An application developer wants to develop components that could be used in other applications. The reuse could be done by him, his team or eventually external collaborator.
- A team of Developers want to agree on programming policy to ease their collaborative work.
- A Developer desires to produce code of quality by applying agreed best practices.
Problem
How to develop a ROS code so that its reuse in other contexts is facilitated?
How to make sure that other developers can easily embed such development in other applications, but also contribute to its maintenance and evolution along time in a fluent way?
Solution
Look for best practices
Generally speaking, a key in developing code intended to be understood and reused by other Developers or Integrator is to reduce as much as possible the subjectivity in the implementation choices. Nevertheless all Developers do not have the same background and experience in software programing, robot programing or ROS. And even if they would have, there would still be a need for agreeing common practices for handling any problem. This is why it is a good practice (if not mandatory) to look for best practices during the development of any component or application. Unfortunately, there is not a unique place hosting all the good practices, and it still required to dive into several sources to find the relevant information we are looking for.
The main sources of best practices are the following:
● ROS Wiki
● ROSCon programs
● Team or developer best practices.
The ROS Wiki is a tremendous source of information, including for finding best practices. Yet, the page ROS Best Practices provides useful pointers on best practices in ROS, as a set of “statements of how best to achieve common tasks with ROS”. It mentions the existence of the ROS Enhancement Proposal(REP) which can be used to register best practices. It lists existing best practices, and also mentions the open points that would deserve a best practice description.
The wiki section on ROS Use Patterns and Best Practices also gathers best practices organized through abstract design patterns that are Conventions, Workspaces, Modularity, Communication, Parametrization, Logging and Robot Modeling.
The wiki section ROS developer´s guide is a good starting point for getting used to the common practices for developing components to be shared with the community.
Among other links, we can mention the pointers towards ROS Programming styles (C++, python and javascript), and the description of the Quality Assurance Process to be followed by a package to be included into the ROS eco-system.
Considering that the people are likely to have already considered a question we have, it is relevant having a look at the ROS Answers section of ROS. In particular, the tag best_practices can be looked for for getting answers related to best practices. See here the list of related questions.
Finally, bet practices can be searched as well through the information provided by individuals or Developer teams.
Several presentations done at ROSCON (2017, 2016, 2015) provide good insights on best practices that could be used. Some developers groups give access to the best practices they gathered and follow, like:
● The Autonomous Systems Lab of ETH Zurich
● The Artificial Intelligence and Robotics Laboratory from Milano, which provides also a generic ROS node template that can help to define new nodes.
Consider Automation Tools
Several high-level tools are existing for automating the creation of nodes and packages.
The advantage of such automation tools is that it reduces the code production by using hidden code templates or skeleton.
If the proposed templates fits the Developer needs, then the Developer can focus on the core added value of a component, and let the automation tool prepare the rest of the architecture.
The ROS package generator
The ROS package generator is a work from Tecnalia developed in the context of the European project ROSIN.
This package generator is based on templates that can contemplate the whole creation of ROS packages. Most of the templates currently available only request the developer to define the desired interface, and all the package configuration, node architecture including ROS communication means, are automatically created thanks to the template. The developer only has to focus on the insertion of the component intelligence.
Template for cyclic nodes, pure service servers and test packages are provided. Advanced designers can also design their own node template, using the proposed generation tools, or jinja (or both).
Documentation is accessible from the github repository, and in the related paper at ICINCO 2019.
ROSLab
ROSLab is a High-level Programming Language for Robotic Applications.
The code is maintained by the Precise Lab, but has not been updated for two years.
Examples of use are available at Nicola Bezzo´s website.
ROSLab is a high-level programming language based on blocks and links dragged on a java workspace which generates the skeleton code for robotic applications involving different types of robots.
Components can be connected though their communication interface.
Once generated, the Developer can implement the core code, having all the package and node skeleton automatically created.
The code generation is done using the ROSGen component, which is implemented in Coq.
ROSLab seem to be an interesting solution for roboticist Developers with limited knowledge in programming language and ROS, and want to quickly develop applications.
ROSMOD
ROSMOD is a work from the Vanderbilt University.
As it can be seen on the github account, the development is still active, and an online demo is available here.
An extensive documentation is also accessible on github.
ROSMOD is a Robot Operating System Model-driven development tool suite, providing graphical tools for rapid prototyping and deploying large-scale applications.
It follows a component-based approach structure and is said to be a refinement of the ROS component model.
The ROSMODE tool-suite is intended to reduce the amount of time and effort they spend installing, configuring, and maintaining applications.
Nevertheless, it requires agreeing with the proposed model of component, that is slightly different from the traditional ROS one, which may be acknowledged only by advanced Developers.
Bride
Bride is on the main outcomes of the European project Brics.
Bride stands for BRICS Integrated Development Environment.
It allows for a definition of component interface and behavior using an abstract representation. enabling automatic model validation and code generation, where appropriate. It also provides a clear separation in between framework-specific (like the component interface) and the framework-independent code (like the core component computations).
Bride is integrated as an Eclipse plugin, in which the Developer can graphically design nodes together with its communication interface with the ROS world.
The development is following the spirit of Component-Based Software Engineering, targeting quality, technical and functional reusability (see the paper).
Considering that a software component is defined to be a unit of composition with contractually specified interfaces and explicit context dependencies only, brics stresses in its implementation the clear distinction in between the interface and the implementation of the component functionalities.
From the definition of the interface, trough the Eclipse plugin, or directly through a xml description, brics prepares the ROS node structure, defines the communication tools, and prepares in a distinct file the skeleton of the code to be filled by the user.
The concepts followed by brics seem to be of major importance for developing stable components with clear interfaces.
Unfortunately, the developments have been stopped two years ago and are confined to ROS indigo.
Furthermore, the life pattern implemented in the generated ROS core module cannot be adapted to Developer needs, and would require good skills in java and eclipse plugin for being adapted to specific needs.
Rosnode 2.0 life-cycle
In addition to the relevance of defining well the interface a node provides to the user, it is also crucial making clear what is the life-cycle of the node once launched.
Even though part of it can be deduced from the interface definition, critical aspects may not be easily inferred from such description, such as when the node computation starts, can we and should we stop and resume the node activity during the application, …
A particular care is placed on such aspect in the design of ROS2, essentially in the concept of managed nodes.
The inheritance mechanism is used to associate to nodes a common life-cycle, with pre-defined interaction mechanisms. This way the monitoring of the deployment, initialization, pausing and resuming of any node launched is made easier since all managed nodes follow the same policy.
Managed nodes execute following a known state machine which state indicates whether the node is unconfigured (just instantiated), inactive (configured but not running), active (performing its computation) or finalized (before destruction).
The implementation of a managed nodes requires implementing the different transitions from one state to another.
The advantage of such model is that, if well-spread in all nodes, the monitoring of an application is eased since all nodes follow a common methodology and can thus be triggered or consulted on their status in a common way.
The use of a component is thus less dependent on the implementation proposed by the Developer.
This definitely ease the collaboration in the community as well as the reuse of components in other applications.
Even though ROS2.0 is not yet deployed, such mechanism and philosophy is a good practice to consider when developing nodes, even in the current ROS structure.
Related patterns
- Submit a patch
- Regression testing (unit tests)
- Code review
- Accepting a pull request
- Standards and patterns
