The number of classes and methods should be reduced to simplify the interfaces.
Class data should be made private/protected instead of public.
The “const” keyword should be used more often.
Duplicate data and code should be eliminated as much as possible, unless needed for efficiency (e.g., only one object should contain the joint limits, conversion factors, etc.).
I don’t think we need “preemptive” motions. I would add a “Stop” command; a pre-emptive motion would be implemented by “Stop” followed by the new motion. I don’t think we will need “preemptive” commands that do not stop the robot – things that would need this should really be implemented as new motions in the trajectory generator loop.
The mrcBoard class should encapsulate the board hardware; i.e., any status/control that applies to the entire board. It should keep the pointers to the mrcAxis objects. We will eliminate the motion commands from this class.
The mrcAxis/mrcJoint classes should be combined. They could also contain a pointer back to the mrcBoard class.
The mrcKinematics class should be moved “below” the mrcApi class so that kinematic functions are accessible to the trajectory generator. The mrcApi class will contain methods for forward and inverse kinematics. I don’t think it will ever necessary to duplicate the kinematics routines “above” the mrcApi class (i.e., in a client/server scenario), as long as the API provides full kinematic support (for example, instead of querying the robot’s position in joint space, you can query its position in a Cartesian frame). Graphical displays might also require a GetLink(i) method.
The mrcJointSet class should be significantly revised. With the existence of a trajectory generator loop, it will no longer be necessary to use the mrcBoard class to achieve coordinated motions. I would instead consider the mrcJointSet class to define a kinematic chain – i.e., a set of joints that can be considered a self-contained system (for example, the 3 Cartesian stages of the Steady Hand robot). This class should perhaps be called something else, like mrcKinematicChain or mrcRobot.
The API will support Cartesian and joint-level motions of one or more kinematic chains. A robot will consist of one or more kinematic chains. One possibility is to define mrcRobot as a composite class, as defined in the Design Patterns book. An mrcRobot could then be a single kinematic chain or a composition of kinematic chains.
The control parameters should not be limited to PID only. I have seen other useful parameters in the configuration file, but they don’t seem to be used much. We should consider a standard keyword-based configuration file (and parser).
We should consider the error handling mechanisms – i.e., whether to use exceptions or return codes or both. If we use return codes only, it is easy for the user to ignore it and get into trouble (for example, when submitting a sequence of motions, what should be done if one motion is outside the workspace?). Also, return codes cannot be used in some cases, such as operator overloading (e.g., to handle a “divide by 0”).