The OOMRM library has two complementary design goals:
The original design philosphy, the hardware API, was to create an external robotics library for the MRM designed like a generic processor. The aim is to provide very lightweight objects that are easy to use for beginning developers. This means that all external interfaces should make no references to internal processor specifics. Occasionally, this is compromised, but as little as possible. The operational section of each object contain processor specific information if necessary. Also, System specific objects are created as needed that are used to design the user interface but should never be needed to use the library.
Once the hardware is complete, we are now ready for the second design goal--control algorithms. Part of testing control algorithms led to the design of the OOMRM simulator; but the simulator is not needed to use the library; the OOMRM library's original design is still valid--as a hardware API under the simulator; i.e., most of the "O" objects (oDCmotor, oServo, oSonarDV, oCompassDV, oPWM, etc.). Its purpose is to ease construction of a small hobby type robot for robot Sumo or Maze solving competitions built using the 68332. The 68332 (MRM) is actually a great processor compared to what you get with in the PIC based robots like the basic stamp. Of course, the downside is the extra complexity in programming. Thus, the OOMRM reduces this complexity in using a 68332 based bot.
Recently, besides having an hardware API, the library began providing mechanisms for testing control algorithms. For instance, the A* algorithm for basic obstacle avoidance, and other algorithms.
Also, Recently I began incorporating some other ideas and code into a seperate library (jaus library) including a the start of a JAUS based serial protocol for communication with a host PC or another processor using a simple RS232 protocol (SCI). The serial protocol's aim is to be JAUS compliant, although practical consideration for smaller (cheaper) robots always override.
Reviewing my design philosophy, it seems I have recently compromised the "lightweight" as more of the recent objects demanded accuracy--encoder calculations. If you round, the error quickly clobbers you.
From a architectural perspective, the Software is organized into distinct layers as follows: hardware, root, abstract, and complex. The upper layers are sub classed from the lower layers reducing inefficiencies of scale. By sub classing, the upper layers can be very light; for example, the IR_base class inherits all of its working from the below layers, and simply consists of additional information associated with the location of a sensor on the robot.
There are two main benefits of a layered architecture. Firstly, it isolates where changes need to be made for porting code from one processor to another. Secondly, it guarantees that all static classes are properly initialized.
The best way to illustrate the concept is by looking at an example taken from
the 68332 processor. The IR_base class, for instance, has the following class
hierarchy:
We can see the bottom (or top in this diagram) layer consists of all the core hardware submodules oVBR (vector base register), oProcessor (CPU32), oTPU (Time Processing Unit), and oQSM (queued serial module); next, the root layer OOMRM occurs sub classing the hardware layer, followed by the oA2D. The oIR layer then subclasses from the oA2D and the IR_base subclasses from it and the sensor_base class to form final IR_base class. The root layer, in effect, creates a pseudo singly rooted object hierarchy to all hardware functions which should subclass from it—this has the effect of initializing the board to a common state only once, and all classes can count on this to have already occurred.
NOTE: root class should be declared as virtual public; otherwise, hierarchies with multiple root objects could result. Unfortunately, not all compilers support this.
the root layers simply provides a mechanism for encapsulating the whole board functionality into a root object which serves to initialize the whole system. Otherwise if you only declare what pieces you need, then it becomes difficult to guarantee that the whole system is initialized once, and only once to a sane stable place. The hardware layer consists of modules specific to a particular processor; both the interface and implementation will need rewritten when porting.
The hardware layers are composed of basic functionalities which although are somewhat low level, but the basic definitions are industry standards across the industry. Thus the interface to the abstract layer should remain portable, only its implementation should need rewriting. This layer includes: oA2D, oPWM, oSPI, oSCI, oUART, and the oSchedule. The hardware directory also contains the root layer (oomrm.cpp).
The Model layer provides a layer which should directly port into another processor's architecture without modification. This will work as long as we remain true to the premise that only the hardware layer contains hardware specific calls.
The JAUS layer provides a communication protocol base upon the JAUS standard.
For some reason, the classes/compiler allows you to declare either when using JAUS. This seems a compiler specific feature; for example, one can declare an IR_base rather than an jIR_base, but still use JAUS communication. For some reason the objects stored in the object list can sucessfully be recast and make the call jIR_base->JAUS_Message. To me it would seem that if you declared an IR_base, the pointer should have no knowledge of the JAUS_Message method in jIR_base. As mentioned, this may be a GNU feature, and it is best to probably declare what you mean to use.