MRC II Software Design Notes
The MRC II software shall be as platform independent as possible. It will support Unix (Linux, RT-Linux) with the gcc compiler and Microsoft Windows with the Visual C++ compiler.
The target system shall contain hardware to interface to the robot system; either:
a) motion control board(s) that can accept setpoints at the trajectory rate (e.g., 100 Hz) and interpolate between them in joint space.
b) Passive sensor/motor interface boards that can accept setpoints at the servo rate (e.g.,. 1 KHz).
The target system shall be able to supply a reliable periodic interrupt, on the order of 100 Hz, for a trajectory control loop. This might require external hardware on Windows NT systems.
If passive (unintelligent) sensor/motor interface boards are used, the target system shall supply reliable periodic interrupts at the servo rate, on the order of 1-2 KHz.
All real-time periodic loops shall detect “overrun” conditions (i.e., inability of loop to complete execution prior to next invocation). Ideally, it should also be possible to measure the max. and avg. time use for each loop.
A robot may consist of multiple “joint sets” (kinematic chains). This is reasonable in cases where the kinematics can be decoupled (e.g., spherical wrist, RCM, etc.).
A robot may use more than 1 motion control board, but each motion control board will provide axis control for no more than 1 robot.
The trajectory control loop shall have access to sensor data that will be used to affect the robot’s motion (e.g., force sensor).
The software will have at least one real-time component (trajectory control loop) that is activated by a periodic interrupt. The interface between the non-real-time and real-time system will be via a mailbox. The non-real-time software will write the command to the mailbox and then wait (with timeout) for the mailbox to be emptied. The mailbox will be checked and emptied every invocation of the trajectory control loop. Motion commands will be stored in a queue; other commands can be serviced immediately.
Any error on one robot joint will affect the entire robot. If one joint loses power, all joints will stop and an error will be raised to the application.
The real-time loops will perform safety checking as well as polling of hardware status. If any real-time loop detects a problem, it shall perform a specific “reflex action” (e.g., power off robot motors) and then raise an asynchronous error (real-time event). The error recovery may require explicit action from the higher level.
Asynchronous errors cannot directly cause C++ exceptions. The following scheme can be used:
a) When the real-time software detects the (asynchronous) error, it sets a flag (error code, etc.)
b) The “mailbox write” function receives the error code when the non-real-time software submits the next command to the real-time system (e.g., motion command, position query, etc.).
c) The “mailbox write” function then converts the error code to a C++ exception.
The MRC II library will provide a “poll” command that can be used in application programs to detect asynchronous errors, ideally prior to any activity that modifies the external world (e.g., screen output) or periodically during any time-consuming activity. The “poll” command could be just a “nop” or “status query” command to the real-time software.
The software shall contain a “software oscilloscope” feature that allows capture of time-stamped real-time data (e.g., joint positions, forces, etc.). My preference is to have the application software control reading from the buffer, but it could also be possible to have the real-time loop “spew” the data at a specific frequency (this was actually requested by Bert, from Image Guide, for the robot status). This feature can allow the development of servo tuning software.
The software shall be designed to allow easy customization of the trajectory control loop (e.g., a researcher can plug in a new motion type that may use different sensors).
The kinematics shall be written to ensure consistency between forward and inverse kinematics (when closed form solutions exist). There are some open issues here regarding the handling of redundancy, multiple solutions, etc. We should also consider support for numerical (iterative) methods for inverse kinematics (serial manipulators) or forward kinematics (parallel manipulators). Furthermore, we should consider support for calibration models, some of which might couple the kinematic chains (for example, if we want to actively compensate for small errors in the RCM point that are due to mechanical misalignments).