Skip to content

Developers Guide

Shikher Verma edited this page Jul 8, 2016 · 16 revisions

Code style

Cpp follow ROS Cpp Style Guide rigorously.
CMake follow Caktin CMake Style Guide.
Python code should follow pep8. Please see ROS PyStyleGuide for details. Use Anaconda plugin for sublime text editor for style check.
Bash Use this python script.
Roslint All pkgs (except commons pkgs which don't have cpp or py code) depend on roslint for static code analysis.
[Note - Utils directory contains scripts for formatting cpp, python, xml, CmakeList files. Since these are bash scripts I have also added formatting script for bash]


Documentation

We maintain two forms of online documentation for ROS packages:
wiki pages / External docs: This is the AUVWiki repo. Home for tutorials, design documents and other sorts of information. This is mainly for people running your code.
In general anything that people need to know outside source i.e. while only running auv code goes in the auv-wiki, anything else goes to package doc.

auto-generated code documentation Internal docs: This is mainly for people integrating with or editing your code. There are auto generated from source code comments using doxygen. Travis CI generated and auto deploys to gh-pages branch. Located at http://auv-iitk.github.io/auv/ . Look at sample commit to see how to add documentation. Also Doxygen manual is good for quick start.


Source control

We use Git. Read the wiki page on git.


Bug tracking

We use github issues on auv repo for tracking bugs.


(Still missing) Testing

We use two level of testing:
Library: At the library level, we use standard unit-test frameworks. In C++, we use gtest. In Python, we use unittest.
Message: At the message level, we use rostest to set up a system of ROS nodes, run a test node, then tear down the system.
ROS has established best practices and policies for writing and running tests.
Auv code is structured in layers, with each layer interacting with the other using actionlib. For testing each layer separately we use unit tests nodes which are part of the concerning layer itself.


(still missing) Standardization

Code should use ROS services, follow guidelines for their use:
use rosout for printing messages
uses the ROS Clock for time-based routines


Large data files

Large files (anything over 1MB, really) often don't belong in the auv repositories, especially if they are just used for tests. These large files affect the time that it takes to checkout the repository.

(still missing) Naming Convention

Please refer to ROS CppStyleGuide and ROS Conventions
Other than following ROS naming convention,
Topics and nodes should be names keeping in mind the ros namespace. For keeping it noob friendly, global names should be assigned to nodes and topics.
Package folder name should be same as package name.
Node file name, executable name and ros node name should be same.
Dynamic Reconfigure cfg files should be related to what it helps configuring.
Action files should be named after what action or task is done through them.
Launch files should be named after what state it will launch the nodes in.