The Arguments of Separation DA Robotic Software

Inertia and a certain degree of project patriotism are serious factors which can not be overlooked. There are several technical and non-technical arguments of the proposal why the DA software needs to be separated.
1. More difficult to write: writing libraries used in the context of more than one RSF are potentially more difficult because fewer assumptions can be made about the way the libraries will be used. Writing generic code is harder in general but the extra effort is worthwhile if it is outweighed by the benefits.
2. More work without an immediate return: a person writes a new driver of hardware in order to use it for his or her application within a particular RSF. This developer probably will not benefit directly from making the driver reusable easily in another RSF and, the argument goes, would be reluctant to spend the extra effort required. It could be said that separating drastically different types of software is good design practice despite the overhead of partitioned implementation and upfront planning. Currently the effort required to maintain mixed DA/RSF code in the frequent presence RSF changes is nontrivial. Reduction in maintenance efforts within the existing RSS projects is an immediate benefit which is independent from any reuse potential.

There are other technical choices which would have to be made when refactoring code from RSS projects. For instance, choosing the interface style e.q. C++ vs C, error tracing in RSF independent fashion, handling configuration options, and possibly many others.

These problems could be resolved over time and probably in several ways. It does not see an absolute need for uniformity. It would perhaps be a mistake to attempt to standardize on certain library interfaces up front, it would restrict potential contributors.

It is a few criteria list commonly associated with reusable code to evaluate different distribution options.
• Consistent and stable API.
• Ease accessibility.
• Ease of installation.
• Minimum number of dependencies.

No comments:

Post a Comment