a human-machine interface - The Robotics Institute
Contents
1. D B Volpe R A and Khosla P K Integra tion of software modules for reconfigurable sensor based control systems in Proceedings of 1992 IEEE RSJ International Conference on Intelligent Robots and Systems IROS 92 Raleigh North Carolina July 1992 9 Gertz M W Stewart D B and Khosla P K An Iconic Language for Sensor Based Robots in Pro ceedings of SOAR Conference August 4 6 1992 Houston Texas 10 Gertz M W The Onika User s Manual in progress Department of Electrical and Computer Engineering Carnegie Mellon University 11 Stewart D B and Khosla P K Chimera 3 0 Real Time Programming Environment Program Documen tation Dept of Elec and Comp Engineering and The Robotics Institute Carnegie Mellon University Pitts burgh PA 15213 e mail chimera cmu edu for a copy 12 Stewart D B Schmitz D E and Khosla P K The Chimera II real time operating system for advanced sensor based robotic applications JEEE Transactions on Systems Man and Cybernetics vol 22 no 6 pp 1282 1295 November December 1992 13 Stewart D B Volpe R A and Khosla P K Design of Dynamically Reconfigurable Real Time Software using Port Based Objects Technical Report CMU RI TR 93 11 Dept of Elec and Comp Engineering and The Robotics Institute Carnegie Mellon Universi ty Pittsburgh PA 15213 14 Schmitz D E Khosla P K and Kanade T The CMU2. T A from sensor X from sensor Y to actuator Z RLY iconic programs jobs gt real time tasks aa graphical interfaces Qo subroutine calls Figure 1 The reconfigurable software framework for sensor based real time operating systems Routines at one level are created by combining modified reusable routines at the adjacent lower level matically linked in based on the needs of each module in the configuration A configuration implements functions such as motion control world modeling behavior based feedback multi agent control or integration of multiple subsystems A job is a high level description of the function to be per formed by a configuration e g move to point x When the post conditions of one job and the pre conditions of the next are satisfied then a dynamic reconfiguration can be performed within the system We use the term action inter changeably with the term job A control subsystem is defined as a collection of jobs which are executed one at a time and can be programmed by a user Multiple control subsystems can execute in parallel and operate independently or cooperatively An application is defined as one or more subsystems oper ating in parallel An application may be composed of sub systems of other applications allowing for hierarchical decomposition of an application In the following sections we discuss the basic building block of our framework the control module 3 2 Control Mo
3. and manipulating the data which is received from and sent to those drivers These framework elements use C code which can be generated by using a VPL or other C generating program such as MATLAB as suggested in section 4 1 Onika currently does not interact with these levels in a direct manner Unlike higher levels the creation of routines from these building blocks needs to be done by a technically oriented user having extensive programming knowledge and an understanding of real time operating systems Device drivers and sensor interfaces are combined with other code to create control modules It is beyond the scope of this paper to define the legality of and modifications to combinations of sensor interfaces and device drivers and the interested reader should to refer to Stewart et al The use of the routines created by the sensor interfaces is dis cussed in the following section 4 3 Middle Level Details In the middle level interface upper level routines may be created by combining certain modified routines called tasks into control block diagram form Knowledge of textual coding is not required but merely a good working knowledge of control theory 4 3 1 Combining task routines The basic unit of combination at the middle level is the task As mentioned in section 4 1 a task is a modified con trol module The module code by which the tasks process with their input values is written entirely in text The tasks t
4. level need not know anything about textual programming controls or how the controlled ma chinery operates 4 4 1 Combining job routines The basic unit of combination at the upper level interface is a job A job is created at the middle level by combining tasks together see section 4 3 3 on page 6 This function ality is hidden from the upper level user however A job may or may not require a modifier depending on how it was defined at the middle level Jobs which require modi fiers are referred to as actions requiring an object whereas jobs which do not require modifiers are referred to simply as actions An action requiring an object icon must be fol lowed by exactly one object icon An object icon could be created for any state variable from the global state variable table A preference file defines the types of objects which Onika will recognize Objects can be created at both the middle and upper levels The user supplies both the object type and its value s All icons are presented to the user in a job dictionary Each icon s picture is framed in a structure which has a left and right edge of a certain shape and color These are indicators as to which type of icon can sit next to another Onika will not allow non interlocking icons to be placed next to each other All objects have certain values associated with them which can be changed by the programmer These can be viewed and changed both in the dictionary and in
5. re quirements In section 2 we discuss various HMI VPL systems which have been introduced in recent years In section 3 we dis cuss the software framework in which Onika operates In section 4 we introduce Onika a multilevel iconic program ming language IPL and human machine interface HMI We summarize this paper in section 5 2 Previous Work The problems associated with textual programming have been addressed on several levels in the past Researchers have created interfaces wherein routines for an existing programming language such as C are created by a higher level VPL gt Interfaces such as these are designed to be used by programmers with knowledge of the structured programming language in question They are best used for routines of lower to middle level rank Higher level HMIs have also been created for naive users 2347 however the scope of any given interface of this type is generally nar row The addition or major modification of routines con trollable by the interface is beyond the abilities of its typical user Traditional flowchart methods are often used in both higher and lower level VPLs Flow charts reduce the com plexity of textual code somewhat but can still be quite cryptic and do not efficiently use screen space Occasion ally pictures accompany or are used in place of the text as in Pict or HI VISUAL within a flowchart but this does not help to give syntactic clues for programming
6. reconfigurable modular manipulator system in Proceedings of the International Symposium and Ex position and Exposition on Robots designated 19 ISIR Sydney Australia pp 473 488 November 1988
7. software However direct use of the operating system which supports this framework requires users to be knowl edgeable about textual real time code For the naive user a novel human machine interface is required to fully use the system In the next section we discuss Onika our human machine interface for this software framework 4 Onika 4 1 Onika as an Interface The purpose of Onika is to provide an appropriate interface for each level of our programming framework Each inter face shares with the other interfaces the common concept of building higher level routines from combinations of lower level routines In theory there is no limit to the num ber of levels of programming which can be created by such a framework Although it would be impossible to create an interface for each potential level it is possible to use the same interface for closely allied levels This is particularly true at higher levels where the routines that define an ap plication are all goal oriented In Onika we have defined the following levels of programming the lower level also called the textual level the middle level also called the control level and the upper level also called the applica tion level Upper level routines are combined into routines which are also usable in the same upper level programming environment This means that no additional high level in terfaces are needed Onika provides both a robot interface and programming en
8. that the functionality of the module is implemented as a few basic components All of the data flow communication synchronization and scheduling should be handled automatically by the underlying operat ing system Our model of a control module provides a ge on any error after task receives on signal ERROR clear if SBS_ERROR returned spawn out consts on any error before task reaches off state WSBS_CONTINUE returned if SBS_OFF on in vars Legend block until specified event occurs out vars T wakeup call specified subroutine componer t of module copy state variables or constants into or out of global state variable table state of task Figure 2 Internal structure of a control module neric structure that is applicable to both periodic and aperiodic real time tasks A control module can have two kinds of input constant in put that needs to be read in only once during its initializa tion in const and variable input which must be read in either at the beginning of each cycle for a periodic task or at the start of event processing for aperiodic task in var Similarly a task can have output constants out const or output variables out var Both constants and variables are transferred through the global state variable table Two examples of state variables of the const type ar
9. the application workspace 4 4 2 Icon combination rules Applications are assembled from the icons displayed in the job dictionary This assembly is done within an application workspace Icons are inserted from the dictionary into the application If its edges match those of its potential neigh bors a new icon can be inserted between two icons If the icon matches its left neighbor but not its right a space is in serted between it and its right neighbor The proper bridg ing icon can be inserted later into this gap Figure 4 Certain of the icons shown in Figure 4 have been designed with the Intravehicular Autonomous Robot IVAR being designed at NASA Langley in mind This process contin ues until the application is completed to the user s satisfac _troikabot2 Not connected to RTOS Untitled Figure 4 The icon just inserted into the application did not match with the icon following it in the application flow A space was inserted for an object icon tion Icons may be inserted anywhere into an application provided that they interlock properly with their potential left neighbor Conditional branches parallel branches and other poten tial icons will introduce their own syntax needs These con structs have not yet been introduced into Onika in any form Applications created by combining jobs and modifiers can have icons assigned to them and be used in other higher level applications W
10. In Proceedings of the 1993 AIAA Conference on Space Programs and Technologies Sept 21 23 1993 Huntsville Alabama A HUMAN MACHINE INTERFACE FOR RECONFIGURABLE SENSOR BASED CONTROL SYSTEMS Matthew W Gertz David B Stewart and Pradeep K Khosla Dept of Electrical and Computer Engineering The Robotics Institute at Carnegie Mellon University Pittsburgh Pennsylvania 15213 Abstract The development of software for dynamically reconfig urable sensor based control systems is a complicated and tedious process requiring specialization in real time sys tems programming and an amount of time which may not be available for instance in a space laboratory The total development time can be reduced by automatically inte grating reusable software modules to create applications The integration of these modules can be further simplified by the use of a high level programming interface which can integrate modules developed at different sites We have de veloped Onika an iconically programmed human machine interface to interact with a reconfigurable software frame work to create reusable code Onika presents appropriate work environments for both application engineers and end users For engineers icons representing real time software modules can be combined to form real time jobs For the end user icons representing these jobs are assembled by the user into applications Onika verifies that all jobs and applications are syntactically
11. Nassi Schneiderman flowcharts used primarily for lower level programming are more compact than traditional flow charts and have an implied syntax They can be textually cryptic and difficult to read however There are other VPLs which use pictures and other visual cues in order to construct the program use non traditional flow methods Proc BLOX gt alower level VPL allows us ers to create Pascal like code by assembling blocks repre senting the textual code primitives in a jigsaw puzzle fashion The shapes of the elements preclude the possibility of assembling syntactically incorrect programs Other packages such as Lingraphica and ISHeE remove the text altogether and rely on pictures to determine the mean ing of the program ISHeE also uses the jigsaw puzzle for mat to convey syntax By making the visual representations more compact more of the program under development can be seen on the screen at a time 3 Details of Software Framework A multilevel interface requires a multilevel programming framework in which to operate Associated with our re search into multilevel IPL HMIs is the development of a multilevel reconfigurable software framework gt In this section we introduce this software framework and discuss its various components 3 1 Overview The real time components of our software framework il lustrated in Figure 1 are supported by the Chimera 3 0 Real Time Operating System The user interface an
12. Partial funding for David B Stewart is provided by the Natural Sciences and Engineer ing Research Council of Canada NSERC through a grad uate fellowship References 1 Myers B A Taxonomies of Visual Programming and Program Visualization Journal of Visual Languages and Computing 1990 1 pp 97 123 2 Leifer L Van der Loos M and Lees D Visual Lan guage Programming for robot command control in unstructured environments Proceedings of the Fifth International Conference on Advanced Robotics Ro bots in Unstructured Environments June 19 22 1991 pp 31 36 Pisa Italy 3 Mussio P Pietrogrande M Protti M Colombo F Finadri M and Gentini P Visual Programming in a Visual Environment for Liver Simulation Studies 1990 IEEE Workshop on Visual Languages Oct 4 6 1990 pp 29 35 Skokie Illinois 4 Ichikawa T and Hirakawa H Visual Programming Toward Realization of User Friendly Programming Environments Proceedings 2nd Fall Joint Computer Conference 1987 pp 129 137 5 Glinert E P Out of Flatland Towards 3 D Visual Pro gramming Proceedings 2nd Fall Joint Computer Conference 1987 pp 292 299 6 Glinert E P and Tanimoto S L Pict An Interactive Graphical Programming Environment Computer November 1984 pp 7 25 7 Chang S K Visual Languages A Tutorial and Sur vey IEEE Software January 1987 pp 29 39 8 Stewart
13. ation prevents the creation of the task and immediately calls xxxKill which can free any resources that had been allocated before the error occurred If an error occurs after a task is initial ized then the xxxError routine is called The purpose of xxxError is to either attempt to clear the error or to per form appropriate alternate handling such as a graceful deg radation or shutdown of the system If for any reason the task is unable to recover from an error the task becomes suspended in the error state and a message sent to the job control task that operator intervention is required After the problem is fixed the operator sends a clear signal from the user interface at which time xxxClear is called The xxx Clear routine can do any checks to ensure the problem has indeed been fixed If everything is fine to proceed then the task returns to the off state and is ready to receive an on signal If the error has not been corrected then the task re mains in the error state 3 5 Reusing and Reconfiguring Modules Our software framework is designed especially to support reusable and reconfigurable real time software The change in configurations can occur either statically or dy namically In the static case only the task modules required for a particular configuration are created In the dynamic case the union of all task modules required are created dur ing initialization of the system Tasks necessary for the firs
14. correct non ambiguous and complete They can then be executed from within Onika or can be saved as a stand alone program which can be exe cuted independently on the underlying real time operating system Onika can retrieve and use software modules cre ated at other sites with modules created locally While On ika has been fully integrated with the Chimera real time operating system in order to control several different ro botic systems in the Advanced Manipulators Laboratory at Carnegie Mellon University it can also function indepen dently of Chimera Onika will be used in connection with NASA Langley Research Center s Intravehicular Autono mous Robot IVAR space manipulator laboratory 1 Introduction The development of real time software for sensor based systems is an expensive process accounting for a signifi cant portion of total application costs This expense can be reduced by automating the software development proce dure To do this a user friendly high level programming environment designed for the creation of reusable real time software is required A programming interface of this type would not only allow for the rapid development of soft ware but would also considerably ease the process of de bugging real time code This would be especially useful Copyright 1993 by the American Institute of Aeronautics and Astronautics Inc All rights reserved when the manipulator is operating aboard a shuttle or space
15. d pro gramming environment for these real time components are implemented within Onika We define a control module as a reusable software module within a reconfigurable sensor based control system A control module executing in the real time environment is referred to as a task and hence we often use the two terms interchangeably Control tasks may be either periodic or aperiodic and can perform any real time or non real time function Periodic tasks block on time signals whereas aperiodic tasks block on asynchronous events such as mes sages semaphores or device interrupts A configuration is formed by integrating control modules from a library to form a specific configuration Device drivers and utilities such as math subroutines are auto iconic programming language _ Peat om oe ie configuration SS eet programmer Subsystem wW and editor __ job Q If Configuration R _ SSS C math and utility subroutine ibraries lt to from other subsystem KNN AS ma special purposi _processor F typed data in 4 typed data ii in Fa typed data out OTAN D gt ANAS KANAS CARAS sensor sensor _ actuator _interface X_ L interface Y A interface ZJ raw data in raw data in raw data out ANS PANN SSS i o device i o device i o device N drivery _ drivery J driverz Chimera 3 0 N g 4 B a
16. dules Each control module has zero or more input ports zero or more output ports and may have any number of resource connections Input and output ports are used for communi cation between tasks in the same subsystem while resource connections are used for communication external to the subsystem such as with the physical environment other subsystems or a user interface Each input and output port is a state variable and not a message port Whenever a task executes a cycle the most recent data corresponding to the input port variables is ob tained At the end of a cycle the new data corresponding to the output port variables is used to update the subsystems s state information A link or connection the terms are used interchangeably is created by connecting a port of one module to a port on another module A configuration can be legal only if every input port in the system is connected to one and only one output port see section 4 3 2 An output port may connect to multiple input ports A task does not have to have both input and output ports Some tasks receive input from or send input to the exter nal environment or to other subsystems using the resource ports Other tasks may generate data internally e g trajec tory generator and hence have no input ports Still other tasks may just gather data e g data logger and hence have no output ports 3 3 Control Module Integration In order to integrate m
17. e the degrees of freedom of a manipulator VDOF and its De navit Hartenberg parameters DH By changing only the robot interface module which supplies these values we can execute a configuration written for one manipulator on an entirely different manipulator The use of in consts and out consts by the modules creates a necessary order for initializing tasks within the configu ration Tasks which generate out consts must be initialized before any other task that uses that constant as an in const is initialized The rules are discussed in greater deal in sec tion 4 3 2 The code for a control module xxx is decomposed into sev eral subroutine components xxxInit xxxOn xxxCycle xxxOff xxxKill xxxError and xxxClear Refer to Figure 2 for a diagram of these components and how they relate to the state variable table transfers and events in the system A more detailed C language specification for this control module interface is given in Stewart et al The xxxInit and xxxOn components are for a two step initialization while the xxxOff and xxxKillQ routines are for a two step termination The two step initialization al lows the task to first be created but then remain in an off not executing state High overhead operations such as creating the task s context allocating memory initializing the local state variable table and initializing resources are generally performed in the initialization routine Once
18. g user input is found then any values it will need in the future as an upper level job will be determined from the modifier icon which follows its icon A job which requires a modifier is referred to as an action requiring an object whereas a job which requires no modifiers is simply an action The modifier of a job is referred to as an object Once a job routine has been created it is available for use in the upper level interface The use of job routines in the upper level is the subject of the next section 4 4 Upper Level Details Similar to the middle level interface the routines which may be used to create upper level applications are dis played to a user in one window and assembled for later ex ecution in another Modifying icons objects are displayed in the same window as the available routines Certain of these icons may have been retrieved from remote file sys tems if such file systems are specified in Onika s environ mental variables This provides an easy mechanism for modifying any given routine Jobs actions and objects are combined into a serial goal oriented application at this level The application can be saved at any time for later re call or modification During execution the task configura tions associated with the jobs in the application are loaded into Onika and Chimera The tasks are spawned and acti vated As each job is completed the system reconfigures into the next job Programmers at this
19. hemselves however are represented by a single block form icon having a certain number of input and output pins The mechanism by which the task performs its function is hidden from the middle level user A parameter file is associated with each task s module This parameter file completely describes the task When Onika is executed it loads in all available task parameter files on the system as well as certain user specified remote file systems listed in Onika s environmental variables It then creates icons on the fly for each task from information in the file These icons are presented to the user in an area known as the task lexicon To create a job by combining tasks desired tasks are selected on the lexicon and a copy is then be placed in the combination area This combination area is called the job canvas The specific rules for placing tasks on the canvas are discussed in section 4 3 2 When a task is placed on the canvas it is rendered at the point where the user lets up on the mouse button as shown troikabot2 Figure 3 Tasks placed on the canvas are automatically connected to the tasks already there in Figure 3 Onika then checks the pins of the new tasks and determines whether each has a similar variable name to other pins on the canvas If so then these pins are graphi cally connected to each other to illustrate to the user that these
20. hereas incomplete applications i e those with some object gaps unfilled cannot be executed on a system they can be iconified and used in other appli cations Incomplete applications can be implemented as actions requiring an object provided that any gaps within the incomplete application refer to the same type of object consistently 5 Summary Despite the fact the programming of sensor based control systems readily lends itself to a multilevel programming approach there has been surprisingly little research done in the area of multilevel interfaces for such systems Until the use of multilevel sensor based systems becomes wide spread and the various levels of the system are equipped with programming and control interfaces appropriate to the abilities of their potential programmers the use of sensor based robots will continue to be narrow in focus and diffi cult to implement The framework and interface presented in this paper constitute one step in the direction of achiev ing an completely integrated sensor based system which will expand the usefulness of robots in astronautics and aeronautics Acknowledgments The research in this paper is supported in part by Sandia National Laboratories NASA and the Dept of Electrical and Computer Engineering and The Robotics Institute at Carnegie Mellon University Partial funding for Matthew W Gertz is provided by NASA Langley Research Center through a GSRP fellowship
21. odules into a configuration a reliable method of intertask communication is required In our soft ware framework a state variable table is used to provide such capabilities Our mechanism assumes that each con trol task is self contained on a single processor and that a control subsystem is contained within a single open archi tecture backplane A global state variable table is stored in the shared mem ory The variables in this table are a union of the input and output port variables of all of the modules which may be configured into the system Tasks cannot access this table directly Rather each task has its own local copy of the ta ble called the local state variable table Within the local table only the variables actually used by the task are kept current At the beginning of each cycle of a task the variables which are input ports are transferred into the local table from the global table At the end of a task s cycle variables which are output ports are copied from the local table into the global table This design en sures that data is always transferred as a complete set since the global table is locked whenever data is transferred be tween global and local tables More details on the imple mentation of the global state variable table can be found in the Chimera 3 0 Program Documentation i 3 4 Generic Structure of a Control Module In order to provide automatic integration of the control modules it is necessary
22. ol systems Onika directly connects with the underlying real time operating system to coordinate the system s activities giving a user a control capability which has not previously been available in interfaces for sensor based systems Programming can be done interactively or off line Onika gives the user ac cess to a library of control modules which are parallel ex ecuting reusable software modules within a reconfigurable sensor based control system Each control module on the real time operating system is represented by a block form icon which can be manipulated by a mouse Using Onika these icons can be combined in a logical way to create jobs for the system to execute The interface is able to switch from one job to the next quickly in real time with minimal system delays The user is also able to use Onika to monitor and modify the real time performance and parameters of each routine running on the real time operating system Furthermore a combination of routines created at one level of Onika can be saved as a reusable higher level routine for others to use Thus routines at Onika s higher levels be come more specific making programming accessible for naive users without diminishing the programming scope for more knowledgeable users working at Onika s lower level Unlike other interfaces both levels of users naive and knowledgeable are presented with an interface appro priate for their programming abilities and application
23. r to take full ad vantage of all the capabilities of the hardware e Reconfigurable software is useful for supporting multiple applications on a fixed hardware setup e Generic graphical user interfaces and programming environments for robotics and automation appli cations require that the underlying control system be reconfigurable Other major advantages to designing applications to reuse reconfigurable software even for systems which do not have to be reconfigurable include the following e Reusable software Any software that is developed for a reconfigurable system is inherently reusable It is therefore not necessary to redevelop every part of the system when designing a new applica tion Consequently the development time for ap plications is significantly reduced e Expandability Existing hardware can be upgraded or new hardware or software added to the system with reprogramming the application e Technology transfer A module and hence the tech nology implemented within that module can eas ily be transferred to another institution which is also using the reconfigurable software frame work Technology transfer is thus very straight forward even if different institutions are working on very different applications or have very differ ent system setups Onika has several abilities which increase its effectiveness with respect to other interfaces and programming environ ments for real time sensor based contr
24. station where the primary users may not necessarily be specialists in the field of robotics Much of the expense and tedium of software development is caused by the limitations of textual code To use a textual language properly the programmer must undergo expen sive training The deciphering debugging and use of real time textual code is particularly time consuming espe cially when the code is cryptic non portable and uncom mented In the past researchers have created visual programming languages VPLs to address the problems of textual coding 23 45 6 7 However these interfaces have been in general either very high level and narrow in scope or low level and cryptic Furthermore these inter faces have not been designed with the specific require ments of real time programming in mind These requirements include the need to switch from one job to the next with minimal time loss the need to modify the code of a job while it is executing and the need to coordinate many jobs running in parallel In this paper we discuss the development of a multilevel iconically programmed human machine interface called Onika and the software programming framework in which it resides Our primary motivations for designing such a software framework include the following e Reconfigurable hardware such as open architecture computer environments e g VMEbus and reconfigurable machinery e g RMMS 5 require reconfigurable software in orde
25. t configuration are turned on immediately after initializa tion causing it to run periodically while the remaining tasks remain in the off state At the instant that we want the dynamic change in controllers we send an off signal to the tasks not required in the next configuration and an on signal to those that are required On the next cycle the new tasks automatically update their own local state variable table and execute a cycle of their loop instead of the now unused tasks doing so Assuming the on and off operations are fairly low overhead the dynamic reconfiguration can be performed without any loss of cycles For a dynamic reconfiguration which takes longer than a single cycle the stability of the system becomes a concern In such cases when the dynamic reconfiguration begins a global flag signals to all tasks that a potentially illegal con figuration exists Critical tasks which send signals directly to hardware or external subsystems e g the robot interface module can go into locally stable execution in which the module ignores all input variables from other tasks and in stead implements a simple control feedback loop which maintains the integrity of the system When the dynamic reconfiguration is complete the global flag is reset and the critical tasks resume taking input from the state variable ta ble The software framework described in this section allows the user to create reusable and reconfigurable real time
26. t input to be connected to a variable output To avoid such a possibility a series of connection rules have been devised These include all types of inputs may connect with each other that is share the same state variable no type of output may connect with another to avoid race conditions and inputs requiring initial values in const may not connect to outputs which do not supply them out var Although a task might be considered connectable in the state variable sense it still may be unplaceable due to conflict of modules or names This is because the task names are used for task identification Furthermore run ning a module twice concurrently would be redundant and a waste of system resources Tasks within the lexicon which cannot be legally placed on the canvas due to name or module conflicts are dimmed and made unselectable 4 3 3 Creation of higher level routines Before the combination of tasks can have be saved as a job there must be exactly one output instance of each state vari able used in the configuration As mentioned in section 4 3 2 this is ensure that each module can receive meaning ful input When the user saves a configuration as a job for high level users Onika must determine whether or not the job routine to be created will require modifiers or not In order to do this Onika checks the configurations for tasks which re quire user input such as the end location of a trajectory If a task requirin
27. tasks are now connected in the supporting real time operating system see section 3 4 Onika can be actively connected with the real time operat ing system In such a case as each task is dragged to the job canvas it is spawned on the supporting RTOS The user can toggle the state of activity of the task can move the task s icon around on the canvas without affecting the sys tem otherwise and can delete and replace the task The user may bring up a panel within which he or she may change the modifier values specified in the parameter file both in the lexicon and on the canvas Furthermore a com bination of tasks on the canvas can be saved at any point for later recall 4 3 2 Task combination rules Within a task any state variable can be declared as any of the following in const out const in var out var in both or out both Those of the const form are constants which are read or written at the initialization of a task and never again accessed by that task Those of the var form are read every task execution cycle and so the values are assumed to change Those of the both form read or write some initial value from the state variable table but the values are as sumed to change thereafter It is possible that one task may declare a state variable to be constant while another might declare it to be a variable This might lead to certain prob lems It would not make sense to have a task that expects for example a constan
28. the task is created it can be turned on executing and off quickly Every time it is turned on only a small amount of initialization is required to place the task into a known in ternal state which is consistent with the rest of the system The xxxOn routine can also be used for enabling inter rupts and setting up post conditions for the task set The xxxOff routine is useful for disabling interrupts placing final values on the output ports ensuring that other tasks will not be adversely affected when the task s execution is halted and to save any internal state or logged data onto more permanent storage The xxxKill component is used to terminate a task and free up any resources it had previ ously allocated The xxxCycle component is executed every time the task receives a wakeup signal For periodic tasks the wakeup signal comes from the operating system timer while for aperiodic tasks the wakeup signal can result from an in coming message or other asynchronous signalling mecha nism supported by the underlying operating system Before the xxxCycle component is called in vars are transferred from the global state variable table into the local table Af ter the xxxCycle component finishes the out vars are transferred from the local to the global table Until now we have made no mention of errors which may during the initialization execution or termination of a task By default an error generated during initializ
29. vironment for the middle and upper levels of programming It also uses lower level programs to define middle level routines Onika 1 1 runs on the Sun4 and interacts via Internet with the real time operating system Chimera 3 0 which itself runs on a single board computer in a VMEbus gt 3 Onika can also retrieve and immediately use both middle and up per level routines from any other machine on the Internet provided that the remote machine from which the files are being retrieved is running an appropriate server Thus code developed at different locations can be stored on a distrib uted file system and retrieved automatically by any site on an as needed basis The concepts inherent in Onika are independent of Chimera 3 0 and can be used with other systems For in stance a Macintosh version of Onika is being developed for the Intravehicular Automation Robot IVAR at NASA Langley Research Center The IVAR project is intended to produce a manipulator capable of performing microgravity experiments in space laboratories with little or no supervi sion This next sections discuss the interfaces at each level of Onika in greater detail including the rules for combining routines and modifiers into higher level routines 4 2 Lower Level Details Device drivers and sensor interfaces are the routines of the lower level of the system s programming framework Sen sor interfaces are created by combining various device drivers
Download Pdf Manuals
Related Search