PARSL uses XML syntax. Fig. A.1 shows the overall structure of a PARSL specification. All are optional except the <robot> section. The order is arbitrary.
An overall structure of robot specification is in Fig. A.2. Sections <sensors> and <actuators> are optional.
The <structure> section consists of a set of named groups, each of which has the form:
<gname elements = "e1, e2, ..."/>
where gname is the name of the group, e1, e2 etc. are elements of the group. An element can be a number, representing module's logical ID, or a string, represent a group name defined previously in the section.
The <sensor> and <actuator> sections have the same syntax as the <structure> section, with group names replaced by sensor or actuator names. The elements of a sensor or an actuator are the modules which have the named sensor or actuator. If an element of a sensor or an actuator is a group name defined in the structure section, it is assumed that all the modules of that group have the named sensor or actuator. Each named sensor or actuator has to be implemented. The current version has implemented "angle" (named angle), "accelerometer" (named accel) and "switch" (named touch) sensors, but no actuators. The accelerometer sensor has three arguments, named x, y, and z, respectively, indicating the accelerometer reading for x-, y-, and z- axis, respectively. The touch sensor has two arguments, named left and right.
The current reading of a sensor that is specified in the robot's description can be referenced in two ways: 1. global: $n_name_arg where n is the logical ID of the module, name is the sensor name and arg is the argument for the sensor; or 2. local: $_n_name_arg where n is the relative position of the module in the group, or with respect to the current module.
The mapping file has one node <hardware>, with one attribute "mapping".
<hardware mapping = "ID1 => PID1, ID2 => PID2,...IDN => PIDN"/>
where ID
is logical ID
defined in the robot section and PID
is correspondent hardware module ID. If "!" appears before the hardware
module ID, the hardware angle is negated with respect to the logical angle.
The <controls> and <parameters> have the same syntax and semantics. The difference between a control and a parameter variable is the way it is referenced and the way it is evaluated. Parameters are referenced by their names, control variables are referenced by their names with prefix $. Parameters are evaluated at the beginning of each execution, and control variables are evaluated continuously at every control loop. In the current version, four types of variables are defined: text, choice, slider or button.
<name init = "V" type = "text"/>
where name is the name of the variable, V is a real number indicating initial value.
<name init = "s" states = "s1, s2,..."/>
where s1, s2 are choices and s is the initial choice.
<name init = "V" min="L" max="U"/>
where name is the name of the variable, V , L and U are integers.
<name type = "button"/>
where name is the name of the variable. The initial value for a button is always 0, then toggle every time the button is hit.
The <main> section consists of a sequence of behaviors:
<main cycles = "C">
...
<bname time = "T" exit = "E" mname1 = "M1" mname2 = "M2" .../>
...
</main>
where bname is the name of the behavior defined in <behaviors>, C, T and E are expressions, mname1, mname2 etc. are macro names in the "macros" attribute for behavior bname, and M1, M2 etc. are strings or constants that replace the macro names in this composition. All attributes for a behavior are optional.
When there is no "cycles" in <main>, the cyclic mode is assumed. The default running time for a behavior is infinite and the default exit condition is false (i.e. never exit). The program sequentially runs each behavior, until its time expires or its exit condition becomes true. It runs for C cycles if non-cyclic, otherwise, it loops forever.
The <behaviors> section consists of a set of named behaviors. Each behavior has a name bname and optionally with a list of macros
<bname macros="mname1, mname2,...">
</bname>
Within a behavior, a set of sub-behaviors can be defined, each has the form
<if cond = "C"
...
<aname group = "gname" start = "S" offset = "O" phase = "P" period ="T" cycles = "N"/>
...
</if>
where C is a logical expression, S, O, P and T are mathematical expressions with real values and N is an expression with integers. The automaton named aname would only run while the condition is true. Without the explicit condition, the default is true. If "!" appears before a group name defined in the robot section for gname, the angles are negated. All attributes are optional. If "group" is absent, the automaton applies to the whole robot; default values for "start", "offset" and "phase" are 0; The default period is the nominal period of the automaton. If "cycles" is absent, the cyclic mode is assumed.
The <automata> section specifies a list of automata. There are three types of automata: table, record or state transition.
<aname type = "record" file = "filename"/>
where aname is the name of the automata.
<aname states="sname1, sname2,..." times="T1[E1], T2[E2],..." />
where aname is the name of the automata and sname1, sname2, etc. are names of the states defined in the <states> section. Attribute "times" is optional; when it is absent, 1 is assumes for all states. If there is "times", the number of states in "states" and the number of time elements in "times" have to be the same. The nominal duration for the i'th state in "states" is specified by the i'th time element in "times", i.e., it is T unless its exit condition E becomes true before T expires. The total nominal period for such an automaton is the sum of T' s. Both T and E are mathematical or logical expressions; T evaluates to a numeric value and E is Boolean. In the absence of an exit condition, the default expression is false, i.e., reducing to a time-driven transition.
<aname type = "table" states="S1;S2;..." times="T1[E1], T2[E2],..." />
where aname is the name of the automata, "times" has the same syntax and semantics as in state transition, Si has the form
t1A1, t2A2,....
where Ai is an mathematical expression and ti is an optional quantifier, describing the type of action. When t is omitted, linear interpolation between the current angle and A is assumed. Symbols #, ~, @ and : for t represent speed, slack, hold and instant move, respectively, for the corresponding joint. When t is absent, a linear interpolation from the current joint angle to A is assumed.
Every state referenced in <automata> has to be defined in the <states> section. The <states> section consists of a set of named states, each has the form:
<sname angles = "t1A1, t2A2,..."/>
where sname is the name of the state, and actions on that state are specified by attributes. In the current version of the specification, only "angles" are defined. Future extensions to other types of actuators and actions are easy to make. The elements in "angles" specifies the state vector, where Ai is an mathematical expression and ti is an optional quantifier, describing the type of action. When t is omitted, linear interpolation between the current angle and A is assumed. Symbols #, ~, @ and : for t represent speed, slack, hold and instant move, respectively, for the corresponding joint. When t is absent, a linear interpolation from the current joint angle to A is assumed.