Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 105 of 197

~ = o = n o fD ~ Configuration constants Variable input ports Port-based object ~~------~------~~ :1--:--_ Y1 n---.... ym Resource ports, for communication with sensors, actuators, and other subsystems Variable output ports rectangle, with input and output ports shown as arrows entering and leaving the side of the rectangle. Configuration constants are drawn as arrows entering/ leaving the to p of the rectangle. Resource ports are shown as arrows ente ring/ leaving th e PBO from the bottom. A PBO executes as an independent TABLE 1 Recon- gfwdkin ginvkin tball cinterp puma pfwdkin pinvkin Generalized forward kinematics Generalized inverse kinematics Trackball interface Cartesian trajectory interpolator Puma interface figurable Modular Manipulator System (RMMS) Compute Forward Kinematics based on the DH- parameters obtained during initialization of the module Computer I nverse Kinematics based on the DH- parameters obtained during initialization of the module A hardware-dependent interface to a six-degree of-freedom trackball Given the current measured position and the desired final position, compute the intermediate reference positions Hardware-dependent interface to Puma 560 robot Puma forward kinematics Compute forward kinematics for a Puma 560 robot Puma inverse kinematics Compute inverse kinematics for a Puma 560 robot Lion between objects is based on a structured bl ackboard design that operates as follows. When a process needs in formation, it obtains the most recent data avail- able from its in/Jut paris. This port can be viewed metaphorically as a window in your house; whatever you see out the window is what you get. There is no synchronization wi th other process- es and there is no knowledge as to the o rigin of the information tha t is obtained from this port. When a p rocess generates new information that might be needed by othe r p rocesses, it sends thi s infor- matio n to its outfJu t fJorts. An o u tput port is like a door in your home; you can op en it, place items outside for oth ers to see, th en close it again . As with the input ports, there is no syn- chro nizati o n with oth e r processes, no r do you know who might look at the information placed on the out- pu t po rts. In addi tion to th e independent process, the object is selected as a n ele- mental software abstraction. As stated by Wegner, an object is the atomic u nit of encapsulation, with opera- tions that con trol access to the data.l2 l J Th e term o bject does not imply "object-ol-iented design," which is an extension to objects to include polym01phism and inheritance. The ref- erences to obj ects in thi s arti cle are classifi ed as objecl-ba~'P(i dpsign, as defin ed by Wegner 's distin ctio n of that term and object-oriented design.l221 Note that obj ects wi tho ut inhe ritance a nd polymo rphism a re in e ffec t abstract data types (ADTs) , and are easily implemented in C; C++ is not necessal-Y· The algebra ic model of a port automaton and the software abstrac- tion of an obj ect are combined to cre- ate the PBO model, as depicted in Figure 2. A PBO is drawn wi thin a data-flow diagram as a round-corner 104 DECEMBER 2000 Embedded Systems Programming concurrent process, whose fun ctional- ity is defin ed by methods of a stan- dardized obj ect. In C, the objects are impleme nted as ADTs. Commu- nication with other modules is res trict- ed to its input ports and output ports, as described above. The configumlion constants a re used to reconfigure generic components for use with spe- cific hardware o r applications. In addition to input and output ports, we also defin e resource ports, which are needed to create an envi- ronment for multi-sensor integration. The resource ports are fo r modeling only to show the source or destination of data th at is exchanged with I/O hardware. In practi ce, the resource ports are implemented in a hardware- dependent manner, as the reads and writes of the I/O hardware 's registers. The resource po rts connect to sensors and actuators, allowing the PBO model to be used to replace the more traditional POSIX style of device dri- vers. Details of accessing the sensor or actuator are encapsulated within the PBO, resulting in an HD interface component. Modelling PBOs to have optional configuration cons ta n ts and resource ports allows the use of the same PBO model for different types of compo- nents. A sample library of PBO objects for robotic manipulators is shown in Table 1. The library represents a sub- set of PBOs that were created in a ro boti cs labo rato ry at Carnegie Mellon University.ll 91 An importa nt n ote a bo ut th e functi onal descrip tio ns of the mod- ules is that the framework is designed independent of th e granulari ty of functio nality in each PBO. The gran- ularity is defin ed by th e software

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13