As your company, Robot Archaeology, is aiming to produce a robotic system that reduces the need for labour when scanning a field for geophysical data, I have compiled a report listing both the advantages and disadvantages of developing your system within the ROS (Robot Operating System).
ROS is a flexible framework initially designed for writing robot software for use in research, but it is slowly becoming acknowledged as the chosen framework for use within industry. ROS aims to simplify the process of making sophisticated robots. It is what I would describe as a network compilation of packages that have been written by a diverse number of programmers, for a multiple range of robotic platforms.
Advantages of ROS within robotic projects:
1) Free and open source
2) Ample documentation
3) Built in a modular design
4) Easy to use message structure
5) Use with multiple programming languages
1) Currently only runs tested on Unix-based platforms
2) Can only have one ROS master
Free and open source
While the core parts of ROS are licensed under the BSD license, other licenses are commonly used in the community packages, such as the Apache 2.0 license and the GPL license. Each package in the ROS ecosystem is required to declare a license, so that it is easy for users to immediately determine if a package will meet their licensing needs.
ROS has a wiki website that houses all the documentation you will need to get your projects up and running (ros.wiki.org). This ranges from how to install ROS on your computer, to getting started tutorials. The ROS Wiki has over 22,000 pages of documentation, but if you are still stuck with your project then ROS has ROS Answers (answers.ros.org). This is a question and answer forum that has over 5,700 users, with 13,000 questions to date and a 70% percent answer rate. Just type in a detailed question with all the relevant information of your issue and you should get an imminent reply. ROS also has a blog with archives dating back to February 2009 (planet.ros.org).
Built in a modular design
ROS was designed to be as modular as possible and on the whole is done inside packages. Packages give you as users the opportunity to pick and choose the parts of ROS that would be of use and which parts to ignore. At their last count ROS had over 3000 packages announced to the public for them to gain access to.
Easy to use message structure
ROS packages gain access to a robots data over the ROS messaging structure. This is made up of Nodes, Topics, Services and Messages. A ROS Node is what gives a package data. It does this by communicating with other Nodes. Nodes can publish and receive messages to and from a Topic. Topics contain Messages. Messages are data, this can either be standard data i.e. a Float64 or a message specific to a device. A Service is similar to a Topic, except rather than blindly publishing and subscribing to one way messages, Services request to receive a message. For instance an example may be that if you wanted to read raw data from a sensor and then communicate that within ROS, you would write a script within a package, which that a Node, which publishes to a Topic, containing the raw data from your sensor.
Use with multiple programming languages
ROS has libraries that can interact with scripts written in Python, C++ and Lisp, but also has experimental libraries for use with Java and Lua.
Currently only runs tested on Unix-based platforms
ROS is only released for Unix-based platforms like Ubuntu, although there are beta releases for Mac OS X, Arch Linux and Ubuntu arm.
Can only have one ROS master
A nuisance of ROS is that you only have one ROS master. The ROS master is the core of ROS, it can only be on machine within each ROS network. The role of the Master is to enable individual ROS nodes to locate one another. Once these nodes are located, they communicate with each other via the peer-to-peer protocol. This means if the ROS master goes down, there will be no communication between the remainder of the ROS network.
As your goal of implementing a robotic system, that allows the integration between a robot and a pre-made sensor, I would be happy to recommend ROS as the platform to achieve this goal. The only cost, would be to gain Unix-based machines and train your technicians to be competent within the operating system. You may already have the machines and trained personnel and as Ubuntu is open source too, there will be no cost in software. On experience, it is relatively easy to use ROS to achieve your objective, given that your staff already are experienced with Python and C++. Once integrated you then have the option of making a contribution back to ROS by choosing whether or not make your work open source. If you do choose to use ROS with your upcoming project, given time and practice, I believe you would agree that the choice you have made, would have been a positive decision for the future of your Company.
...(download the rest of the essay above)