Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 111 of 197

that the name used to code the PBO can be independent of the name used for linking that. object to other PBOs. Configuration examples The flexibi li ty of creating applications using software components i demon- strated in this sectio n . Details of designing individ ual PBOs are given in a fo llowing section. Ca'rtesian control of tlz f' RMMS Figure 3a shows a configu ra tion , using modules from o ur sample li brary shown in Table 1, to perform teleop- erated Cartesian control of a reconfig- U1-able modular manipulator system (RMMS) .fI 21 The configuration of this ro bot is not kn own beforehand. Rather, its configuration is read from EPROMs embedded in the robot dur- ing initialization. From tJlat configura- tion, the rm11lS module o utputs its hardware configuration via the Nool' (numbe r of degrees) and DH CREATED I + , NOT spawn init ( >in-vars ( >out-vars t I on + + (, out-vars> + ON I off out-vars> \ + _ I off out-vars> + = State of task = Call user-defined method of object = Wait for signal; if signal occurs, execute state transition = SVAR communication; = Copy from global into local state variable table = Copy from local into global state variable table = Relationship between the" prongs" of the PBO and the user-defined methods ~ = Process flow lID DECEMBER 2000 Embedded Systems Programming wakeup • '1 ~ " • , (De navit-Ha rte n be rg parame te rs- a me thod of mathematically specifying the shape of a robot) configuration constants. The constants are used as input to tJle gfwdhin and ginvkin mod- ules that are configured for any robot based on NODI' and DH.f61 A teleopera- tion interface is provided by the 6- DOF trackball , and the cinterp module is used to generate intermediate tra- L.. j ectory poin ts fo r the robot, becau 'e the tball module typically executes at a much lower frequency than the other modules . The software framewo rk does not pose any constraints on the frequency of each PBO. Rather, as defined by the port-automaton theory, every PBO is an independent, concurrent process that can execute at any frequency. Whe neve r th at process needs data fl-om its input ports, it retrieves the most recent data availabl e. Whe n it completes its processing, it then places any new data o nto its o utput ports. A configu ratio n can be executed in .. .f either a single- or multi-processor e nvironme nt. In a multi-processo r environment, the control engineer only needs to specify which processor to use for each PBO. The communica- tio n be tween PBOs and syn- external signal chroni zatio n of their processes is oth- erwise iden tical, and fully transparen t to the con trol system engineer. Cart f'sian /f'if'o/)('mtion of a 560 Suppose that a Puma 560 robot is to be u ed instead of the RMMS. The rmms module can be I -eplaced with the puma robot in te rface module, as shown in Figure 3b. Since the Puma is a fixed configuration robot, its NoOl,'

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13