Design Overview

The 'TaskContext' as a functional building block

Sarathi is composed of numerous Orocos Taskcontexts. A full description of an Orocos Taskcontext (henceforth abbreviated to 'TC') can be found in the Orocos documentation. For our purposes, it is enough to think of an Orocos TC as a software 'blob' that executes either periodically or non-periodically. Each TC can emit events and react to events emitted by other TCs. Furthermore, a TC provides functions which can either be executed in the thread of the calling TC (in Orocos terminology, these are called the 'Methods' of a Taskcontext) OR in the thread of the TC which defines the function (in Orocos terminology, these are called the 'Commands' of a Taskcontext). Methods are executed immediately when they are called (in the caller's thread) while Commands are queued up and run when the TC which defines the command is executed. Finally, each TC can have any number of buffered and unbuffered data ports, which can be connected to data ports of other TCs. These data ports can hold any type of data.

TCs can be turned 'ON' or 'OFF' by other TCs.

A distinct piece of functionality (for example, a path planner) can be executed inside a TC, whose periodicity, Methods, Commands and Data ports can be configured as necessary, for that functionality. Further, the TC can load its functionality from a plugin. Consider again, a path planner: Different planning algorithms can be implemented in different plugins and the planning TC can load a user-configured plugin at runtime. This makes it easy to swap out/in plugins without restarting/recompiling the system.

TaskContexts within the Sarathi system

The TCs within the Sarathi system are shown in figure1 below. This architecture is largely inspired by the design patterns described in The real-time motion control core of the Orocos project by Bruyninckx, H. et al

Array

Fig. 1: TCs within Sarathi

Functions of each TC are described below:

  1. SOAP Server: A non-periodic taskcontext responsible for managing communication with clients using SOAP messages. Forwards command requests to the Command processor
  2. Command Processor: A periodic taskcontext which executes commands received from the SOAP server (and optionally from other taskcontexts)
  3. Path Planner: Aperiodic. Upon receiving a goal position, the planner plans a path from current position to goal position. The result of a successful planning run is a set of key configurations which must be successively attained in order to reach the goal in a collision free manner. The path planner needs a scene description, which describes the robot and the obstacles in its environment.
  4. Trajectory Generator: Aperiodic. The path planner outputs a set of key points, without any consideration of the time at which each point is to be reached. Such a set of points, without any timing information is called a “path”. The trajectory generator imposes timing constraints which define the time at which each key point must be reached. The output of the trajectory generator is a set of keypoints, where each keypoint is associated with a time when it should be reached. This is called a “trajectory”
  5. Sequencer: (TBD: Periodic or aperiodic) This evaluates whether the generated trajectory is being executed as expected, and makes corrections if it is not so. The evaluation involves evaluation of application specific conditions and uses the output of the Trajectory Generator and the realtime and non-realtime estimators.
  6. Interpolator: Periodic. Generates a motion set-point every time it executes. Could use different methods like cubic splines, trapezoidal profiling etc.
  7. Estimator: Periodic. Could be a Kalman filter or Luenberger observer. Generates filtered sensor readings
  8. Parameter Estimator: Used to estimate parameters of models that other components rely on. Example could be identification of dynamic system load
  9. Exception and Events Processor: Periodic. Used for fault management and a catch-all for unhandled events in the system
  10. Free Motion: Aperiodic. Permits a total bypass of planning (and possibly motion control), in case it is ever necessary. This is for raw, low level joint motions
  11. Reporter: Periodic. This gathers data from other TCs in the system and outputs it in a continuous stream. External programs can subscribe to this stream to know the internal state of the system. Example could be visualization programs that show the planned path, current robot configuration and so on
  12. Robot Description Plugin: Aperiodic. Each robot being used needs to be characterized by kinodynamic constraints and several other attributes. Robot specific data enters the system through this plugin. It would be loaded at startup, depending on the robot being used. Among other things, it could provide links to functions in the robot manufacturer's API, which can be invoked for actual robot motion. This way, the motion control system in Sarathi can be bypassed in preference to the robot manufacturer's motion controller.

A minimal implementation

A minimal implementation would contain the following TCs: SOAP server, Command processor, Path planner, Robot Description Plugin.

The typical event flow would be

  1. SOAP server receives a Moveto(Destination) command, which gets queued up in the Command processor
  2. The Command processor dispatches it to the path planner
  3. The path planner plans a path from the current position to the destination, and outputs a set of key configurations
  4. The robot manufacturer's moveto() function is repeatedly invoked through the Robot Description Plugin with successive key configurations as destinations

Managing licensing issues through local hacks

Update: MPK is now dual licensed and can be obtained under the GNU GPLv3. Thanks to Mitul Saha for making this possible.

This section was inspired by the fact that the MPK library is ”..free for research and non-commercial use only.” This license is incompatible with the GPL, and as such, it is not possible to distribute the MPK library together with the Sarathi code. Also, it is unclear if linking MPK with Sarathi constitutes a violation of the GPL. In such cases, a hack would be to create a lightweight standalone 'server' program which acts as an MPK wrapper and executes as a separate process. The server shouldn't use any GPLed code and is not released under the GPL. The path planning TC then uses this server's services (over sockets, pipes and so on) to do the path planning. Since Sarathi and the server execute as two separate processes, there is no GPL violation.

This is a horrible hack from an architectural viewpoint, but till such a time as non-free software continues to exist (and unfortunately, most academic path-planners as of this writing are not free software (as defined by the free software foundation)) workarounds such as this might be necessary.

Please note that such methods are temporary solutions only and seriously compromise the integrity of the program. Whenever possible, free software alternatives to proprietary code must be used. Growing comfortable with these temporary solutions is effectively letting the “bad guys” win.