EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 113 of 197

::I III o ! typedef struct -PboFunc __ t { pboFunc_f ini t; pboFunc_f reinit; pboFunc_f on - , pboFunc_f cycle; pboFunc_f sync; pboFunc_f off; pboFunc __ f t enn; } #define PBO __ MODULE(xyz)\ typedef int ( * xyz##Func __ f)\ (xyz## __ t *);\ \ i nt xyz##Ini t(xyz## __ t *);\ int xyz##Reini t(xyz## __ t *);\ int xyz##On(xyz## __ t *);\ i nt xyz##Cycle(xyz## __ t *);\ i nt xyz##Sync(xyz## __ t *);\ int xyz##Off(xyz## __ t *);\ int xyz##Tenn(xyz##_t *);\ t ypedef struct\ ##xyz##Func_t xyz##Func_f xyz##Func __ f xyz##Func __ f xyz##Func_f xyz##Func __ f xyz##Func __ f xyz##Func __ f xyz##Func_f init;\ reinit;\ on; \ cycle;\ sync;\ sync; \ off;\ tenn;\ } xyz##Func_t ; \ \ const xyz##Func __ t\ xyz##Func={\ xyz##Ini t, \ xyz##Reinit,\ xyz##On,\ xyz##CycLe, \ xyz##Sync,\ xyz##Off,\ xyz##Tenn\ }-, II end PBO __ MODULE definition {\ and DH parame te rs are consta nt. In tead of reading these values from the robot, they can instead be hard- coded into the jJUTlW module, and out- put as configuration constants. There is no need to change any other mod- ule, since the gfwdkin and ginvkin mod- ules will configure themselves during initialization for the Puma based on the new values of NDOI, and DH. Improving performance of a Puma 560 Generic components are llsefu l for enabling rapid prototyping, but they may not always be computationally efficient. For example, the general- ized computation of the forward kine- mati cs (module gfwdkin) is based on the DH configuration constants and u ing matrix operations. This will nat- urally be slower than perform ing simi- lar computations for a specific robot, such as the Puma 560, where the DH parameters are constant. Unnecessal-y computations (such as multiply by zero or one, or computing sin(n/ 2)) can be eliminated . An HD computation component can be created to improve the perfo r- mance of an application. The j;fwdkin and pinvkin modules are examples of such compo nents. They compute the forward and inverse kinemati cs specif- ically for a Puma 560, and they exe- cute faster than their generic counter- parts. It is then desirable to replace gfwdkin with pfwdkin, and ginvkin with jJinvkin, as shown in Figure 3c, when- ever the jJUrlW HD interface compo- nent is used. In order for an HD computation component to replace a generic com- ponent, it must provide at least the same outputs and must not require any additional inputs as compared to the generic component. Even when an HD component is used, it does not eliminate the usefu lness of the gener- ic component. For example, in order to improve fault tolerance of an appl i- cation, the gene ric component can still be used as a standby module, o r as shown in Figure 3d, it can execute in paral lel with the HD computation 112 DECEMBER 2000 Embedded Systems Programming compone nt, albei t at a lower fre- quency, in order to provide consiste n- cy checks. Autonomous execution of a Puma 560 As an example of an application com- po ne nt, suppose that a custom autonomous traj ectory module ctmj is created to replace the te leoperation module tball, as shown in Figure 3e. The component can be in tegrated into the system by defi ning it as a PBO. Even though a module is applica- tion dependent, it does not have to be hardware dependent. If the hardware for the application is changed, the application compo ne nt does not necessarily have to change. Figure 3f shows this by replacing puma with rrnms, but not changing the traj ectory of the robot's end effector, as defi ned byetmj. Overview of framework Creating code using the PBO method- ology is an "inside-out" programming paradigm as compared to traditional coding of real-time processes, as shown in Figure 4. The u-aditio nal approach is used by most current RTOSes. Processes are created, each with their own mainO (or equivalent function name). The process executes user code and con- trols the Dow of the program. It invokes the RTOS, typically via a sys- tem call , whenever an RTOS service is required . RTOS se rvices include com- munication, synchro ni zation, pro- gramming time rs, performing I/O, and creating new processes. Because execution is under the control of the user, it forces the user to be responsi- ble fo r all of the reso urce ma n- agement, such as scheduling, commu- nication, and synchronization . Instead, to achieve the consistency needed to support component-based software, the RTOS must se rve as the resolll-ce manager. The RTOS has con- trol of execution at all times, and per- forms the communication, synchro- ni zation, scheduli ng, and process management in a predictable manner.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13