Software - Robot DHQ

Go to content

Software

Vision
Vision for Software

The software for our robot is "open" and may be used royalty-free but we ask that code developers give credit where credit is due. The specific licence is not mentioned here because the website owner is not an expert in such things but simply insists that the rights of the owner and creator must be respected.

Software will be published on this website and should meet standard quality criteria as established for the software. Software to be published on this website should be object oriented in the appropriate sense for embedded processing. The concepts of encapsulation, inheritance, polymophism and abstraction are translated into a hardware setting in this design.

Modules. Robot-DHQ software is organized into modules. Module code is intentionally limited in size and scope to fit in an Arduino Nano which has 32K of flash program memory. A lot can be done within that space but the principle of "division of labor" should be applied and multiple "independent" modules need to be developed to attain the Robot-DHQ vision.

Encapsulation. A module is a set of code running on an embedded microprocessor. In the first instance this in an Arduino Nano and the prime purpose of the module is to control one or more servos, i.e. servomotors. Other modules can implement communications, sensor fusion, specialized functions, etc. The concept of encapsulation in this context means there will be many specialized processing nodes and many nodes may execute the same program because they perform the same basic function.

Inheritance. As an example, a coordination module may coordinate the action of multiple servos. To a "higher" functioning module or coordination module the coordination module may "appear" to be acting like a servo module. In other words the function of the coordination module "inherits" the servo module functionality. This seems perfectly logical to the writer of these words so you might want to ask a question or suggest a way to further illustrate this concept.

Polymophism. A module that controls servos of the left arm has a clone that performs operations of the right arm. The modules are identical in terms of the hardware and software but the wiring and data of each is independent. This is the hardware analog of polymophism. Comments and questions are invited.

Abstraction. The logical operations are often merged and overlap because of the organization of the robot hardware and mechanics. Abstraction means the modules become more generalized and can be repurposed in multiple ways. Cohesion and coupling have to do with the interdependencies between modules, hardware, software and physical structural components. From an AI perspective a module that processes priorities for the purpose of keeping the robot balanced in the xy plane is the same as a module that operates in the zy plane and the module that maintains the correct posture while walking or running. This module would abstract the notion of balance and multiple instances of this node would exist in the physical world in the Robot DHQ robot.

In summary, the software for the Robot DHQ robot is modular and distributed over many processing nodes. Also, however complex the software may become, the user/designer can modify and experiment with a module with less fear that making a change in one place will have unintended consequences elsewhere.

Software in embedded systems is not known for its object oriented design but object oriented programming should be used when appropriate.

The core principles and essential characteristics of object oriented programming and design should be observed in the Robot DHQ design because the size and scope of the project require it.

Comment and suggestions in this regard are welcome and invited.
Back to content