RHexLib Hardware Class Proposal

Through discussions between JayGowdy, UlucSaranli, AlRizzi, and myself, we addressed the outstanding issues of the RHexLib Hardware class. A few examples of the shortcomings of the currently existing structure:

• any addition of new hardware types requires a global change to the Hardware.hh, causing a large recompile because of many dependancies on Hardware.hh
• a list of pointers has to be managed within Hardware.hh, with non-existing pieces of hardware set to NULL to prevent them from being used.
• programming interfaces for specific types of hardware are managed within Hardware.hh, and all future instances of that hardware must follow the same interface, or else modify the interface in Hardware.hh (again causing a large recompile).

In order to move towards a hardware-agnostic RHexLib core, we devised a new design. The principal advantages of this design are:

• hardware types can be defined in files separate from Hardware.hh. Hardware.hh now only contains a skeleton of a hardware class, with methods to register hardware instances.
• as before, instances of hardware types can be subclassed for generating specific instantiations of hardware types (such as writing classes for two different types of encoders). Unlike before, however, subclasses can extend the parent's interface, to add functionality. A good example of this is having a normal 16 bit encoder as well as a 32 bit encoder. The class for the 32 bit encoder would have a default read function which would return a 16 bit number. But it might have another function, read32 which returns a 32 bit number. If the user knows (or can check) that they're using a 32 bit encoder, they can access this added functionality.
• in many cases, hardware types will be accessed by name. Modules will be able to connect to running instances of hardware by accessing their names, such as

  EncoderHW::lookupInstance("LegR1Hip")

  .
• While hardware types can be put within the core RHexLib library, they are not instantiated until the individual RiSE or RHex directory trees use them. RHex would register the 6 hip encoders (naming each one), while RiSE will register its 12+ different encoders. Using this hardware scheme, we can truly support different robot morphologies.

JayGowdy took the above ideas and put them into a simple example. Below is a tar.gz file which shows an example of declaring multiple hardware types and accessing them by name. There are a few key concepts from the C++ language and from software engineering that need to be noted (for the non-CS types among us):

• Template-based designs - one of the more advanced concepts in C++ is the use of templates. The core Hardware class uses a templatized design, allowing a single class to act as an interface to all of the possible hardware subclasses. Unlike RTTI (run-time type information), templates are resolved at compile time, so there is no performance loss by not hard-coding type information. Jay has abstracted all templatized interface code with macros, so the common RHexLib programmer will not even know he/she is using them.
• Singleton design pattern - the singleton is a common design pattern to ensure that only a single instance of a class exists. This is done in Jay's examples by having static methods and members in a Hardware class. For every hardware type, a single default instance will be created. No matter where you access this instance, it will always be the exact same one.

Example This is a very simple example using the sample Hardware.hh. You simply need a RHexLib tree on your machine (with libutils compiled at the very least) to get it to work. hardwaredemo.tar.gz:

E-mail Correspondences: a lot of e-mails were shared while discussing our options. I will try to put the more useful ones here on this page:

• Jay's e-mail describing the near-to-final Hardware class design: JayHardwareRedesignEmail

-- ClarkHaynes? - 29 Sep 2003