UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Design and integration of controllers for simulated characters Firmin, Michael 2014

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2015_february_firmin_michael.pdf [ 6.01MB ]
Metadata
JSON: 24-1.0167045.json
JSON-LD: 24-1.0167045-ld.json
RDF/XML (Pretty): 24-1.0167045-rdf.xml
RDF/JSON: 24-1.0167045-rdf.json
Turtle: 24-1.0167045-turtle.txt
N-Triples: 24-1.0167045-rdf-ntriples.txt
Original Record: 24-1.0167045-source.json
Full Text
24-1.0167045-fulltext.txt
Citation
24-1.0167045.ris

Full Text

Design and Integration of Controllersfor Simulated CharactersbyMichael FirminB.Sc., Colorado School of Mines, 2012A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFMASTER OF SCIENCEinThe Faculty of Graduate and Postdoctoral Studies(Computer Science)THE UNIVERSITY OF BRITISH COLUMBIA(Vancouver)November 2014c© Michael Firmin 2014AbstractDeveloping motions for simulated humanoids remains a challenging problem.While there exists a multitude of approaches, few of these are reimplementedor reused by others. The predominant focus of papers in the area remains onalgorithmic novelty, due to the difficulty and lack of incentive to more fullyexplore what can be accomplished within the scope of existing methodolo-gies. We develop a language, based on common features found across physicsbased character animation research, that facilitates the controller authoringprocess. By specifying motion primitives over a number of phases, our lan-guage has been used to design over 25 controllers for motions ranging fromsimple static balanced poses, to highly dynamic stunts. Controller sequenc-ing is supported in two ways. Naive integration of controllers is achievedby using highly stable pose controllers (such as a standing or squatting)as intermediate transitions. More complex controller connections are auto-matically learned through an optimization process. The robustness of oursystem is demonstrated via random walkthroughs of our integrated set ofcontrollers.iiPrefaceThe CMA-ES algorithm discussed in Chapter 6 was originally created by N.Hansen and A. Ostermeier [14]. The variant adapted for this work originatesfrom [17]. An adapted version of this dissertation has been submitted tothe Computer Graphics Forum journal. Figures from this thesis labeledas “used with permission” are copyright and are reused with permissionfrom the authors of the cited papers. The rest of the work is original anddeveloped by the author Michael Firmin, who discussed with Dr. Michielvan de Panne.iiiTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 A Brief History of Animation . . . . . . . . . . . . . . . . . . 11.2 Physics Based Animation . . . . . . . . . . . . . . . . . . . . 21.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Controlling Simulated Humanoids . . . . . . . . . . . . . . . 52.2 Controller Transitions . . . . . . . . . . . . . . . . . . . . . . 72.3 Domain Specific Languages . . . . . . . . . . . . . . . . . . . 83 Language Features . . . . . . . . . . . . . . . . . . . . . . . . . 93.1 Motion Primitives . . . . . . . . . . . . . . . . . . . . . . . . 93.1.1 Proportional Derivative Control . . . . . . . . . . . . 93.1.2 Virtual Force Control . . . . . . . . . . . . . . . . . . 113.1.3 Inverse Kinematics . . . . . . . . . . . . . . . . . . . 123.1.4 Joint Symmetry . . . . . . . . . . . . . . . . . . . . . 133.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.1 PD Controller Modification . . . . . . . . . . . . . . . 14iv3.2.2 Virtual Force Feedback . . . . . . . . . . . . . . . . . 143.3 Hierarchical Phase-Based Structure . . . . . . . . . . . . . . 153.3.1 Phase Transitions . . . . . . . . . . . . . . . . . . . . 164 Language Specifications . . . . . . . . . . . . . . . . . . . . . . 184.1 Script Format . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.1 Phases and Transitions . . . . . . . . . . . . . . . . . 194.1.2 Primitives . . . . . . . . . . . . . . . . . . . . . . . . 214.1.3 Key Term Listing . . . . . . . . . . . . . . . . . . . . 255 Integrated Controller Graph . . . . . . . . . . . . . . . . . . . 275.1 Example Controllers . . . . . . . . . . . . . . . . . . . . . . . 275.1.1 Step-Up . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.2 Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Controller Robustness . . . . . . . . . . . . . . . . . . . . . . 335.3 Controller Transitions . . . . . . . . . . . . . . . . . . . . . . 346 Learning Transitions . . . . . . . . . . . . . . . . . . . . . . . . 386.1 Inspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2.1 Unknowns . . . . . . . . . . . . . . . . . . . . . . . . 396.2.2 Objective Functions . . . . . . . . . . . . . . . . . . . 406.2.3 Covariance Matrix Adaptation . . . . . . . . . . . . . 416.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.1 Walk to Forward Walkover . . . . . . . . . . . . . . . 426.3.2 Skip to Walk . . . . . . . . . . . . . . . . . . . . . . . 426.3.3 Walk to Stand . . . . . . . . . . . . . . . . . . . . . . 436.3.4 Forward Walkover to Run . . . . . . . . . . . . . . . 436.3.5 Forward Walkover over Box . . . . . . . . . . . . . . 437 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54vA Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.1 Stable Pose Scripts . . . . . . . . . . . . . . . . . . . . . . . 55A.1.1 Squat . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.1.2 Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.2 Dynamic Scripts . . . . . . . . . . . . . . . . . . . . . . . . . 56A.2.1 Backflip . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.2.2 Forward Hop . . . . . . . . . . . . . . . . . . . . . . . 57A.2.3 Forward Walkover . . . . . . . . . . . . . . . . . . . . 59A.2.4 Kip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.3 SIMBICON Style Scripts . . . . . . . . . . . . . . . . . . . . 62A.3.1 Simbicon Base . . . . . . . . . . . . . . . . . . . . . . 62A.3.2 Two Phase Simbicon Base . . . . . . . . . . . . . . . 64A.3.3 Walk . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.3.4 Fast Walk . . . . . . . . . . . . . . . . . . . . . . . . 65A.3.5 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.3.6 Skip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.3.7 Walk to Stop . . . . . . . . . . . . . . . . . . . . . . . 67A.4 Crawl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.4.1 Crawl . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.4.2 Stand to Hands and Knees . . . . . . . . . . . . . . . 69A.4.3 Crawl Base . . . . . . . . . . . . . . . . . . . . . . . . 70A.5 Handstand Scripts . . . . . . . . . . . . . . . . . . . . . . . . 71A.5.1 Handstand . . . . . . . . . . . . . . . . . . . . . . . . 71A.5.2 Handstand to Supine . . . . . . . . . . . . . . . . . . 73A.5.3 Walk on Hands . . . . . . . . . . . . . . . . . . . . . 74B Controller Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 76viList of Figures1.1 ASIMO and BigDog Robots . . . . . . . . . . . . . . . . . . . 31.2 Graph of currently implemented controllers . . . . . . . . . . 42.1 SIMBICON locomotion controllers . . . . . . . . . . . . . . . 62.2 Feature-based control applied to various characters . . . . . . 62.3 Example of feature based control . . . . . . . . . . . . . . . . 73.1 Example of a PD Controller . . . . . . . . . . . . . . . . . . . 103.2 Example of virtual forces . . . . . . . . . . . . . . . . . . . . 113.3 Example of inverse kinematics . . . . . . . . . . . . . . . . . . 134.1 Part listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Joint listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1 Integrated Controller Graph . . . . . . . . . . . . . . . . . . . 285.2 Step up script . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Step up motion . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Stand script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.5 Standing motion . . . . . . . . . . . . . . . . . . . . . . . . . 325.6 Robustness of backflip controller . . . . . . . . . . . . . . . . 335.7 Robustness of locomotion controllers . . . . . . . . . . . . . . 345.8 Motion sequence with environmental features . . . . . . . . . 355.9 Sequence of connected controllers . . . . . . . . . . . . . . . . 365.10 Random motion sequences . . . . . . . . . . . . . . . . . . . . 375.11 Selection of controllers . . . . . . . . . . . . . . . . . . . . . . 376.1 Walk to forward walkover transition . . . . . . . . . . . . . . 44vii6.2 Skip to walk transition . . . . . . . . . . . . . . . . . . . . . . 446.3 Walk to stand transition . . . . . . . . . . . . . . . . . . . . . 446.4 Forward walkover to run transition . . . . . . . . . . . . . . . 456.5 Forward walkover with obstacle . . . . . . . . . . . . . . . . . 457.1 Example from Inventing on Principle . . . . . . . . . . . . . . 48viiiChapter 1Introduction1.1 A Brief History of AnimationAnimation techniques have improved significantly since the days of hand-drawn scenes and characters seen in classic movies. Traditional animation,whether done by hand or computer aided, relies on the keyframing tech-nique. In keyframing, a series of key frames are defined that represent theoverall motion. Then, the frames in between these key frames are interpo-lated. In hand drawn traditional animation, the main artist would drawthe key frames, while the in-between frames would be filled in by others.Computer aided traditional animation leaves the job of interpolation up toan automatic algorithm.Keyframing has a few drawbacks: it is tedious, and it lacks physicalrealism, leaving this in the hands of the artist. In addition, interpolationcan create jumpy and awkward transitions between key frames.A more recent approach to animation is motion capture. In motion cap-ture, motion trajectories of actors are recorded and applied to the animatedcharacters. Because actions are performed by real people, this approachproduces physically realistic motions and is also less time-consuming thankeyframing for complex motions.However, motion capture also has a number of shortcomings. The hard-ware and software to record and edit motion capture data is expensive andtherefore not widely available to the public. Small errors in the recordedmotion data can be tedious to fix. Also, motions created using motion cap-ture are limited by the actions that can be performed by the actor. Tocreate superhuman motions would require a cumbersome amount of datamanipulation. The actor and animated character must also have similar1dimensions.1.2 Physics Based AnimationA newer approach to animation, physics-based character animation, at-tempts to solve the issues present in traditional animation and motion cap-ture. In this style of animation, a physically realistic character is createdwithin a simulated world. The character is given realistic masses, joints, jointlimits, and other physical properties. Motions are created by controlling thetorques at each joint throughout the simulation. This method guaranteesa physically realistic animation while allowing characters of any size andshape to be created. However, the difficulty in creating stable and repro-ducible control strategies has prevented its adoption outside of academia.For example, in the video game industry, physics-based character animationhas predominantly been used to create ragdoll motions for characters as nocontrol strategies are needed in this case.Robotics provides another driving force behind physics-based animation.A physically simulated character can be likened to a robot in that they areboth driven by torques generated at the joints. Many of the control strate-gies used to generate motions for a simulated character could be appliedto a robot as well. Locomotion controllers have been successfully createdfor robots such as the bipedal Honda ASIMO [2], and Boston Dynamics’quadrapedal BigDog [26].1.3 ContributionsPerhaps the most significant hindrance with physics-based animation is thelack of a unified standard for developing controllers. While there exists amultitude of approaches, many are never reused or reimplemented by others.This work strives to correct this by1. Designing a simple language to facilitate the authoring of a wide rangeof controllers for a planar character22. Creating a collection of controllers (see Figure 1.2) and motion se-quences using them.3. Providing an optimization framework to(a) learn new transitions between controllers(b) stylize or smooth existing controller transitions(c) determine how to modify a given controller or transition to ad-just to perturbations in the environment, character state, or goaltrajectory.1.4 OrganizationThe remainder of this thesis is organized as follows. In Chapter 2, wediscuss related work in the physics-based character animation and roboticsfields. Chapter 3 discusses the desired features of a control language. Adetailed description of our control language is given in Chapter 4. Next,Chapter 5 presents the controllers and motion sequences authored usingour language. In Chapter 6, we describe our optimization framework andresults obtained using it. Chapter 7 serves as a conclusion and providesdirections for future work. Appendix A presents the scripts for many ofthe controllers authored in our language, while Appendix B describes howthe hierarchy of controllers is represented and stored at runtime. Finally,Figure 1.1: ASIMO and BigDog Robots. Left: Honda ASIMO, Right:Boston Dynamics’ BigDog3the Accompanying Video demonstrates many of our controllers, motionsequences, and optimization results.Figure 1.2: Graph of currently implemented controllers. Diamond nodesrepresent dynamic actions while rectangular nodes are static poses. Solidarrows are na¨ıve transitions while white arrows are a result of the optimiza-tion scheme, and dashed arrows are corrective transitions that are utilizedupon failure of a controller4Chapter 2Related WorkThere now exists a wealth of literature on controlling motion for simulatedhumanoids. Our discussion is focused on three topics. First, we describe thecommon control primitives and techniques used by the physics-based ani-mation and robotics communities. Next, we describe previous work towardgenerating controller transitions and longer motion sequences. Finally, wedescribe how domain specific languages have contributed to other fields.A full review of the current state of physics-based character animationis beyond the scope of this thesis, and can be found in [11]2.1 Controlling Simulated HumanoidsOne classic approach to designing controllers is to break complex motionsinto simpler motion phases. This idea is commonly expressed as a finitestate machine and can be seen in many related works[16, 18, 19, 27]. InSIMBICON [37], Yin et al create a number of locomotion controllers bysplitting more complex motions into a small number of phases, which, whenrepeated cyclically, generate robust motions.Manipulation of a character’s joint space has been a common approachto physics-based simulation. Proportional derivative controllers, which pro-duce a torque to achieve a user specified angle at each joint, can be seen inmany works [15, 16, 37]. Virtual force control through Jacobian transposehas been crucial in the development of controllers for both robotics [24, 30]and physics-based animation [5, 13]. While many existing control frame-works operate primarily in joint space, others attempt to abstract motioninto high-level tasks or features. In feature-based control, motions are tiedto character features such as the center of mass or global angle of rotation5Figure 2.1: SIMBICON locomotion controllers. Controllers created primar-ily through PD control. Reproduced from [37] with permission.[1, 9, 21]. This approach generally involves an underconstrained inverse dy-namics problem, in which an optimization, constrained to the laws of motion,is solved at every timestep with objective functions related to the high levelfeatures. The free variables at each step are the spatial body accelerations,joint angular accelerations, and control torques. As this method uses ab-stract concepts, such as the center of mass, it can be extended to charactersof varying shapes and sizes, as shown in Figure 2.2. Another approach in-volves the creation of physics-based controllers from motion captured dataand has been explored in [7, 19, 29]. Our approach attempts to improveupon previous works by unifying the common features seen in physics-basedcharacter animation into an intuitive language for authoring controllers.Figure 2.2: Feature-based control applied to various characters. Feature-based control can be easily extended to characters of varying shapes andsizes. Reproduced from [9] with permission.6Figure 2.3: Example of feature based control. A jump motion is createdusing feature-based control to manipulate the center of mass. Reproducedfrom [9] with permission.2.2 Controller TransitionsWhile a great deal of research has been put into creating robust controllersfor various motions, significantly less work has been put into finding stabletransitions between them, especially for motions with little to no similarfeatures. The learning of a designated transition controller from motioncapture data has been explored in Sok et al’s [29]. In [19], Lee et al.’scontrollers track reference motion capture data. Controller sequencing issupported by combining two reference motions, and warping the second tocreate a smooth transition.In [6], Coros et al. transition between similar locomotion controllersfor quadrupeds by linearly interpolating between the two. Recent worksincluding [5, 22, 31, 36, 37] show how successful transitions between similarlocomotion controllers can emerge with little extra work.However, transitions between more dynamic or different controllers canpose a much harder problem. Ha et al. explored the idea of planning out asequence of poses in order to transition to the desired pose at the beginningof a new action in [13]. The works of [10] and [35] focus on creating tran-sitions between a small set of carefully designed controllers. In the former,Faloutsos et al. attempt to determine a set of pre-conditions for a givencontroller that would result in a successful transition to it. Transitions be-7tween the complex, highly dynamic tasks of running and obstacle clearanceare explored in Liu et al’s Terrain Runner [20]. In [12], Ha et al. create tran-sitions through a concatenation of separate controllers. Here, they optimizethe controller to be transitioned to with respect to a family of transitioningcontrollers, then choose the most likely candidate controller from the family.Creating robust transitions between different controllers can allow aphysically simulated character to be manipulated through higher-level, taskbased control. For instance, the user can specify a simple task such as walk-ing to a given point, and the framework would figure out a sequence ofcontrollers to achieve this goal. This idea is explored by Coros et al. in [4],using locomotion controllers as input. Alternatively, da Silva et al achievecomposition of controllers using an interpolation scheme, linear Bellmancombination, in [8].In general, these approaches have been limited to connecting controllersthat are similar in style or structure, such as locomotion controllers. Littlework has been done in transitioning between highly dynamic motions, ormotions that are drastically different in style.2.3 Domain Specific LanguagesExisting domain specific languages or tools have been shown to greatly in-fluence their fields by simplifying the design process, and engaging a muchbroader community into the problem solving process. Examples of this in-clude Renderman [32] for rendering problems and FoldIt [3] for protein fold-ing. The Robot Operating System [25] is a general set of software librariesand tools for helping to build robot applications.8Chapter 3Language FeaturesIn our work, we aim to consolidate common features into one easy to usescripting language that can be used to author a wide variety of motionsfor a simulated humanoid. In the following sections, we describe the basicstructure of controllers designed in our language, discuss the motion prim-itives we have chosen to include, and present various feedback rules thathave been incorporated. This chapter presents an overview of the conceptsused in designing our language; for an in-depth description of the languageand its syntax, refer to Chapter 4.3.1 Motion PrimitivesAn important consideration when designing a language is the choice of fea-tures that will serve as the basic control primitives. We want these featuresto be simple enough that somebody without extensive knowledge in the fieldcan use them effectively, but still expressive enough so that the language canachieve its purpose. For our language, these primitives correspond to thebasic actions that the character can take in any given phase. In addition, wewould like these primitives to be based on concepts that are already widelyutilized by the motion control community. Here, we describe many of thesimple motion primitives that a user can specify in our language.3.1.1 Proportional Derivative ControlThe Proportional Derivative (PD) Controller is denoted byτc = kp(θa − θd) − kdθ˙a9Figure 3.1: Example of a PD Controller. The controller is applied to theright shoulderwhere τc is the calculated control torque for a joint, θa the joint’s current an-gle, θd, the desired angle, and kp, kd position and velocity gains, respectively.PD controllers have long been one of the primary motion primitives used incontrol research. They are simple enough to allow novice users to specifya desired joint angle in the local frame, while also allowing expert users totweak the gains to attain better results. Our PD Controller implementationalso allows the user to specify a time for the desired angle to be realized.The system linearly interpolates the desired joint angle between the initialand goal angles over the given time.Additionally, the user can specify a desired angle for a given body partwith respect to the world frame. An example usage of this is to keep thebody upright by specifying a desired angle on the upper torso. The userspecifies which joint(s) should be active to help realize the desired angle.103.1.2 Virtual Force ControlThe Virtual Force primitive allows users to specify a desired force upon agiven body part. The character achieves this force virtually by manipulatinginternal control torques along a chain of joints between the given part anda specified base joint. The Jacobian Transpose is used to determine controltorques based on the desired virtual force:τc = JTFVirtual Forces abstract control so that users can specify a desired force inCartesian coordinates. This can be extended to balance and speed control,gravity compensation, or forces specified on end effectors.Figure 3.2: Example of virtual forces. VF Controller acting on the legs toapply an upward force at the center of massThe equation for virtual force is derived by relating the power P gener-ated by a force F along a chain of jointsP = F> · v11for v the velocity at the point where the force is applied. Given that thissame power can be generated internally by joint torques τ , we haveP = τ> · ωfor angular velocity ω. Equating the two, along with the relation v = J · ω,givesF> · v = τ> · ωF> · J = τ> (3.1)By creating simple linear control laws to adjust the desired force, virtualforces can be easily extended to feedback laws for achieving balance, velocitycontrol, and gravity compensation.For the 2D example in Figure 3.2, we haveJ =[∂vx/∂ωa ∂vx/∂ωb ∂vx/∂ωc ∂vx/∂ωd∂vy/∂ωa ∂vy/∂ωb ∂vy/∂ωc ∂vy/∂ωd](3.2)where vx and vy are the velocities at the point where we wish to applythe force, in this case the center of mass, and ωa, ωb, ωc, ωd are the angularvelicities of the waist, hip, knee, and ankle, respectivly.Equation 3.2 reduces toJ =[ya − yF yb − yF yc − yF yd − yFxF − xa xF − xb xF − xc xF − xd]where (xF , yF ) is the point in Cartesian coordinates where the force is ap-plied.3.1.3 Inverse KinematicsInverse kinematics takes as input a desired location either in world space orrelative to a base joint, and computes the joint angles necessary to move agiven body part to that location. This provides another level of abstraction12by allowing users to specify a target location in Cartesian coordinates.Our system uses cyclic coordinate descent in order to determine thenecessary angles along a chain of joints between the part being moved anda specified base joint. In cyclic coordinate descent, the position objectiveis minimized by repeatedly optimizing each joint angle variable along thechain, one at a time. A detailed description of this technique can be found in[34]. The optimal angles are then achieved using PD Controllers to producenecessary joint torques.Figure 3.3: Example of inverse kinematics. IK controller acting to bring theright hand and left foot to the red dots3.1.4 Joint SymmetryThe symmetry primitive allows the user to specify that a given joint shouldmatch the angle of another. This is useful when the exact angle of thesymmetric counterpart is unknown, such as when it is adjusted by feedbacklaws.133.2 FeedbackAnother desired feature for control is the ability to provide more globalreal time feedback. We accomplish this in two separate ways. The firstis a simple PD Controller modifier based on the joint space feedback rulesused in SIMBICON [37], while the second, based on virtual forces, providesfeedback in the Cartesian frame.3.2.1 PD Controller ModificationThe PD Controller modifier is given byθd = θd0 + cdd+ cvvwhere θd is the modified desired joint angle for the PD controller, θd0 theinitial desired angle, d the horizontal distance between center of mass anda given body part, v the center of mass velocity, and cd, cv gain parame-ters. This form of feedback control is used primarily in the SIMBICON-likelocomotion scripts.3.2.2 Virtual Force FeedbackThe second type of feedback employs virtual forces. Virtual force feedbackcan be used to control both character balance and velocity. For balancing,we use a simple linear controllerF = cdd+ cvvto determine a virtual force to apply to the center of mass. This forceis realized virtually, using the joint chain running between the ankles andupper torso. Here, d represents the distance between the center of massand the center of pressure, v is the center of mass velocity, and cd andcv are gain parameters. By changing the definition of d, we can use thesame feedback law to direct the character’s center of mass to other desiredlocations, such as directly above one of the ankles. This idea is shown in14the stair climbing scripts by using virtual forces to reposition the center ofmass over the leading foot during double stance.Similarly, by manipulating v, we can regulate the character’s velocity.Here, we replace v with (vd − va), where vd is a desired velocity, and vathe current velocity. This will create a virtual force on the center of mass,attempting to ’push’ or ’pull’ the character until it reaches the desired ve-locity.3.3 Hierarchical Phase-Based StructureOne of the most prevalent features in controller design is the finite state-machine. In this, a complex motion is broken down into a number of simplermotions, or phases. For example, a backflip motion could be broken into asquat phase followed by jumping, aerial, and landing phases.For this reason, short motion phases represent the fundamental unit ofa controller designed in our language. In each phase the user specifies anumber of motion primitives, such as a PD controller or Virtual Force ona given joint or body part, any desired feedback laws, and a number oftransition conditions for moving on to the next phase.Another important feature in designing controllers is the ability to easilyre-use controller elements. If a user creates a squat motion, and wants to useit in both a backflip and hop motion, this should be simple to achieve. Wesupport this through a hierarchical controller structure , where any givencontroller can include another. In our previous example, the user wouldfirst design the squat controller. Then, that controller can be included asan identical phase in both the backflip and hop controllers.This idea also facilitates the parameterization of controller scripts. Auser can start by designing a simple walking script. Then, by passing indifferent sets of parameters, he can modify the walk for different styles ofwalking without having to reimplement the original script. This idea canalso be extended to parameterizing for a given feature, such as the center ofmass velocity.153.3.1 Phase TransitionsFor a controller model based on finite state machines, the ability to deter-mine when to transition between phases is essential. Our language offersthe user a number of different phase transitions they can use:1. Time - The simplest form of transition. Transitions after a givenamount of time has elapsed since entering the phase.2. Contact - Switch phases after a specified body part has come into(or broken) contact with the ground or another environmental object.This is useful in situations such as switching from an aerial phase toa landing phase in a jump controller.3. Stable - Switch phases after the character has become stable, i.e.after all joint velocities as well as the center of mass velocity havedropped below some given tolerance. This is useful for highly dynamicphases/controllers where slight disturbances in the input state cancause the controller to fail.4. Fallen - Switch transitions after the character’s torso orientation haspassed a given limit. This is useful in determining if the character hasfallen or a controller has failed.5. Iterations - The controller will switch to the next phase after a givennumber of iterations of the phase.Each phase in a controller supports multiple transitions, which are spec-ified in an order of importance. The controller will check each specifiedtransition condition in order, and if it succeeds, switch to the given phasefor that specific transition. This design helps to create branches in a con-troller, allowing the character to choose different actions based on a numberof parameters. For instance, in the landing phase of the backflip script,two phase transitions are specified. First, if the character’s upper torso hasexceeded a certain global angle range (fallen forward), then the controllerswitches to phase which calls a crawling script. Second, if the character16has fallen backward, then the controller switches to a phase which calls thesupine script. Finally, if neither fallen transition takes place, the characterwaits until it is stable and then transitions to a rising phase.17Chapter 4Language SpecificationsWe unify the features discussed in the previous chapter into a scriptinglanguage. The language is implemented using Boost’s xpressive grammarbuilding library [23]. Scripts are parsed when the system is initially loaded,as opposed to being interpreted on the fly.In this chapter, we will provide a detailed description of the language forthe interested reader. This will involve an in-depth discussion of the scriptingformat and design choices as well as provided functions and parameters. Themore casual reader may prefer to skip to Chapter 5, in which we demonstrateresults and controllers we have authored.For code examples, we will use <...> to specify values defined by theuser, and [...] for optional sections of code.4.1 Script FormatThe basic script format uses a hierarchical block structure. The highest levelblock encloses the remainder of the script.1 [ SCRIPTS <s c r i p t 1 >, <s c r i p t 2 >, . . . , <scr iptN > ; ]23 BEGINSCRIPT name( parameters )4 . . .5 ENDSCRIPTThe user specified values here are the name of the script, primarily usedfor display purposes, and the parameters list, a comma separated list ofinput parameters. If the script requires no parameters, this is replaced byvoid.The optional SCRIPTS statement is where the user lists the filenames ofall scripts required for this one to be executed. This is analogous to the18#include statement found in C and C++. After encountering this line, thesystem will read in all scripts in this list.4.1.1 Phases and TransitionsThe next lower level of abstraction is the phase block1 PHASE <n>2 <COMMANDS>3 ENDPHASEThe user specifies the phase number n, a digit used to refer to this phase.The COMMANDS section is made up of transition statements, motion prim-itives, or a call to another script.The user can call another script using> <scriptname>(<parameters >);scriptname is the filename of the script the user wants to call. Thisscript must have been previously listed in the SCRIPTS statement at thebeginning of the file.parameters is again a comma separated list of values to be passed tothe new script. It must have the same length as the list of input parametersin the new script’s definition. If the scripts takes no parameters, void isused instead. For example, if the user wants to call the stand.s script witha parameter of 0.1 (time spent in the controller, in this case), they wouldwrite> stand ( 0 . 1 ) ;When the system encounters a switch statement, it pushes the calledscript onto the stack, along with its parameters. When the called scriptreturns, it is popped off the stack, and the calling script continues.Every phase must also have at least one transition. A transition is definedasTRANSITION to(<N>). a f t e r (<type> <parameters >);In this, N is the phase to transition to, type is the type of transition,along with any specified space separated parameters for that transitiontype.19The transition types are as follows:1. time <dt> - The simplest form of transition will switch to the nextphase after the amount of time given by dt2. contact <part> - The contact-based transition will execute the phaseswitch after the given part has contacted the ground or any otherobject in the environment. A listing of part and joint primitives isgiven in section 4.1.33. nocontact <part> - Similar to the contact type, except the transi-tion is made when contact is broken.4. stable <tol> - The stable transition compares the angular velocitiesof each joint, as well as the center of mass velocity of the characteragainst the specified tolerance tol. The controller will transition tothe next phase if all these values are below the tolerance.5. fallen <range> - The fallen transition will transition if the globalangle of the upper torso is out of some range. For an angle r (specifiedin radians), range is specified as > r for an upper bound, < r for alower bound, and x r for a symmetric range from -r to r.6. anglerange <lower> <upper> - Similar to the fallen transition, butallows the user to specify a range of angles. When the character’supper torso leaves this range, the transition is executed.7. iterations <N> - The iterations transition will transition after N repe-titions of the current phase. This is mainly helpful when the associatedphase consists of a call to another script.8. complete - Transition after all actions have been performed. Thisis equivalent to iterations 1. This is again must useful when theassociated phase is calling another script. For a phase consisting ofstandard motion primitives, the complete transition would be imme-diately executed.209. keypress <key> - The transition will execute after the user presses akey.10. keyrelease <key> - The transition will execute after a given key isreleased. This, along with keypress could potentially be used to createinteractive games using our system.4.1.2 PrimitivesThe motion primitives section of a phase is contained within an action block1 ACTIONS2 <PRIMITIVE>3 ENDACTIONSwhere PRIMITIVE is any one of the following motion primitives.1. PD Controller - Generates a torque to move a given joint to a givenangle.Form: POSE <joint>(<angle>[, <kp>, <kd>]);Parameters:joint: the joint this PD controller acts onangle: the desired angle,kp, kd: position and velocity gains, respectively.2. PD Controller Feedback Term - Simbicon style modifier for PDControllers. Mostly deprecated, having been replaced by Virtual ForceFeedback, but left in for the sake of compatibility with old scripts. Ad-justs the PD Controller’s desired angle to keep the character’s centerof mass located directly above a given part or joint.Form: POSEFB <joint>(<cd> <cv>).on(<part|joint> <on>);Parameters:joint: The joint to apply the feedback tocd, cv: Position and velocity gain parameters21part|joint: Whether this feedback controller is based on a part orjointon: The part or joint to keep the center of mass positioned above.3. Linearly Interpolated PD Controller - Generates a torque tomove a given joint to a given angle over a given amount of time.Form: LIPOSE <joint>(<angle>[, <kp>, <kd>]).time(<t>);Parameters:joint: the joint this PD controller acts onangle: the desired angle,kp, kd: position and velocity gains, respectively.t: time over which the angle is interpolated between the initial anddesired angles.4. Global PD Controller - A (virtual) PD controller that generates atorque to move a body part to a specified global angle.Form: VPD <part>(<angle>[, <kp>, <kd>]).joint(<joint>);Parameters:part: The body part to moveangle: The globally defined angle to move the part tokp, kd: Position and velocity gains, respectivelyjoint: The joint that generates the torque to move the part5. Virtual Force Controller - Generates a given force internally usingJacobian TransposeForm: VF (<x,y,z>).on(<part>).by(<joint>);Parameters:x,y,z: The force to generate in Cartesian coordinates.part: The part that should apply the force.22joint: The base joint. The joint chain between this and the specifiedpart will be used to generate the desired force.6. Inverse Kinematics Controller - Generates joint angles to move agiven body part to a given spatial location, specified locally or globally.Form: IK <part>.target<local|global>(<x,y,z>).base(<joint>)[.tolerance(<tol>)];Parameters:part: The part to be movedlocal|global: Whether the target is specified in global or local (tothe base joint) coordinates.x,y,z: The position to move the given part to.joint: The base joint. The chain of angles used to move the part isfrom this to the given part.tol: Tolerance, how close the part needs to be to the specified locationbefore stopping the iteration process.7. Virtual Force Feedback - Balance feedback generated through vir-tual forces. Applies a force to the given part in order to move thecenter of mass above a given point.Form: VFFB <part>(<cd>, <cv>).by(<joint>).over(<part|joint|cop>);Parameters:part: The part the force is applied to. Generally the upper torso forfull body balance.cd, cv: Position and velocity gains, respectively.joint: The base joint for the virutal force controller.part|joint|cop: The part or joint to move the center of mass above.Or ’cop’ for the center of pressure.8. Match Angle - Applies a PD controller to match this joint to another,adding a simple method for requiring symmetry.23Form: MATCH <joint1>.to(<joint2>[,<kp>,<kd>])[.time(<t>)];Parameters:joint1: The joint to apply the PD controller to.joint2: The joint whose angle should be matched.kp, kd: Position and velocity gain paramters, respectively.t: If a time is specified, a linearly interpolated PD Controller is usedinstead.9. Virtual Force Speed Feedback - Uses virtual forces to help controlcenter of mass velocityForm: VSFSB <part>(<kd>).by(<joint>).speed(<speed>);Paramters:part: The part the force is applied to. Generally the upper torso.kd: Gain paramterjoint: The base joint for the virtual force controller.speed: The desired center of mass velocityThe following commands are controller level commands, and are notenclosed in an ACTIONS...ENDACTIONS block. They are generally the onlycommand in a phase that transitions on completion.1. Save state - Saves the character state, including center of mass po-sition and velocity, and joint angles and angular velocities.Form: SAVE <name>;Parameters:name: The name of the output state file.2. Load state - Loads the character state, and resets all internal andexternal torques and forces.Form: LOAD <name>;24Parameters:name: The name of the state file to load.4.1.3 Key Term ListingPart ListingThe names used to refer to each body part are shown in Figure 4.1.1. head - Head2. neck - Neck3. uTorso - Upper Torso4. rArm - Right Arm5. lArm - Left Arm6. rForearm - Right Forearm7. lForearm - Left Forearm8. rHand - Right Hand9. lHand - Left Hand10. lTorso - Lower Torso11. Pelvis - Pelvis12. rThigh - Right Thigh13. lThigh - Left Thigh14. rShin - Right Shin15. lShin - Left Shin16. rFoot - Right Foot17. lFoot - Left FootFigure 4.1: Part listingJoint ListingThe names used to refer to each joint are shown in Figure 4.2.1. neck2head - Joint connecting neck and head2. uTorso2neck - Joint between uTorso and neck3. rShoudler - Right Shoulder, connects rArm and uTorso254. lShoudler - Left Shoulder, connects lArm and uTorso5. rElbow - Right Elbow, connects rForearm and rArm6. lElbow - Left Elbow, connects lForearm and lArm7. rWrist - Right Wrist, connects rHand and rForearm8. lWrist - Left Wrist, connects lHand and lForearm9. lTorso2uTorso - Joint connecting lTorso and uTorso10. pelvis2lTorso - Joint connecting pelvis and lTorso11. rHip - Right Hip, connects rThigh and pelvis12. lHip - Left Hip, connects lThigh and pelvis13. rKnee - Right Knee, connects rShin and rThigh14. lKnee - Left Knee, connects lShin and lThigh15. rAnkle - Right Ankle, connects rFoot and rShin16. lAnkle - Left Ankle, connects lFoot and lShinFigure 4.2: Joint listing26Chapter 5Integrated Controller GraphOur language has been used to author over 25 controllers for motions rangingfrom simple poses such as a balanced stand to dynamic motions such as abackflip or kip. Figure 5.1 shows all of our controllers, as well as how theymay be connected. In section 5.1, we present the scripts for a selectionof the controllers we’ve developed, and describe the workflow to producethem. For more scripts, refer to Appendix A. In section 5.3, we discuss howcontrollers may be na¨ıvely connected to create long sequences of motion.Our controllers are simulated using the open source physics engine, OpenDynamics Engine (ODE) [28]5.1 Example Controllers5.1.1 Step-UpWe now show an example script for a step-up motion and explain the thoughtprocess and workflow used to design it. The finished motion can be seen inFigure 5.3.In simple english, we wish to accomplish the following:1. Stand in a balanced state2. Lift the right foot up3. Move the right foot over the step4. Move the right foot down onto the stepThe script for this motion is shown in Figure 5.2The first line in the script lists all of the controllers called by this script,which lets the system know it should load these as well. This is comparable27Figure 5.1: Integrated Controller Graph. Diamond nodes represent dynamicactions while rectangular nodes are static poses. Solid arrows are na¨ıvetransitions while white arrows are a result of the optimization scheme, anddashed arrows are corrective transitions that are utilized upon failure of acontrollerto an #include statement in C. In this case, we include the stand script,because we would like to start and end from it, thereby extending the rangeof controllers that can be connected to this one through direct transition.The actual script begins on line 3. It is given a name and a list ofparameters—in this case, x and y—which correspond to the height of theblock that the character will step onto.In the first phase—lines 4 through 7—the system calls the standVFFB.t(stand with virtual force feedback) script, with an input parameter 0.1.When the stand script has finished running, the system transitions to phase281 SCRIPTS standVFFB . t ;23 BEGINSCRIPT step up (x , y )4 PHASE 05 > standVFFB . t ( . 1 ) ;6 TRANSITION to ( 1 ) . a f t e r ( complete ) ;7 ENDPHASE8 PHASE 19 ACTIONS10 IK rFoot . t a r g e t l o c a l ( 0 . 1 , −.6 , 0 ) . base ( rHip ) ;11 VFFB uTorso (3000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;12 ENDACTIONS13 TRANSITION to ( 2 ) . a f t e r ( time . 2 ) ;14 ENDPHASE15 PHASE 216 ACTIONS17 IK rFoot . t a r g e t g l o b a l (x , y ,−10)18 . base ( rHip )19 . t o l e r an c e ( 0 . 0 0 1 ) ;20 VPD rFoot (0.0 ,−300 ,−30). j o i n t ( rAnkle ) ;21 VFFB uTorso (3000 , 250 ) . by ( lAnkle ) . over ( lFoot ) ;22 ENDACTIONS23 TRANSITION to ( 3 ) . a f t e r ( time . 3 ) ;24 ENDPHASE25 PHASE 326 ACTIONS27 POSE rHip ( 0 . 0 ) . time ( 5 ) ;28 VPD rFoot (0.0 ,−1000 ,−100). j o i n t ( rAnkle ) ;29 VFFB uTorso (3000 , 2 5 0 . ) . by ( lAnkle ) . over ( lFoot ) ;30 ENDACTIONS31 TRANSITION to ( 4 ) . a f t e r ( contact rFoot ) ;32 ENDPHASE33 . . .Figure 5.2: Step up script1 of the original step up controller.In the second phase, we would like to begin raising the right foot so thatit can be placed on the next stair. This could be done in a number of ways.We could specify PD controllers on the right hip, knee, and ankle, but thiswould lead to much trial and error trying to place the foot exactly where wewant it. Another method would be to specify an upward force on the rightfoot using virtual forces. This only requires one parameter, but it would bedifficult to determine when we would like to stop moving the foot upward.We choose to use the inverse kinematics primitive, shown on line 10. Thisallows us to specify a (x,y,z) location to move the foot to—in this case, given29Figure 5.3: Step up motionin the local coordinate frame of the right hip.To ensure that the character remains balanced, we also include a virtualforce feedback primitive (line 11). We use parameters for position and veloc-ity gain of 3000 and 250 respectively, and specify that the character shoulduse the chain of joints between the center of mass and left ankle in order tokeep the center of mass positioned over the center of pressure. We specifya transition out of this phase after a sufficient time duration has passed tobring the foot upwards.Now that the right foot has been raised, we would like to position it overthe step. Here, we again use inverse kinematics (line 17). This time, thegoal location is specified in global coordinates. The script parameters x andy represent the position of the top center of the step, in global Cartesian co-ordinates. Since the inverse kinematics primitive does not control the globalangle of the base joint, we also include a virtual, or global, PD controller(line 20). We specify the desired angle—0.0, or horizontal—so that the footmay remain oriented correctly with the block.In phase 3, we bring the foot down so that it rests flat on the block. Thisis done by applying a PD controller at the right hip, and transitioning outof the phase as soon as the foot makes contact with the block.The remainder of the script (which is omitted) shifts the character’sweight to its right foot with a VFFB primitive, then lifts the left foot to jointhe right in a similar fasion.Through this process we have designed a successful initial—albeitjerky—stepping up motion, shown in Figure 5.3. The motion can besmoothed or stylized by fine tuning gains and other parameters, either by30hand or through an optimization technique.5.1.2 StandThe stand script serves two purposes. First, rise to a simple standing pose;then, balance in that pose until stable.1 BEGINSCRIPT STAND( dt , dt2 )2 PHASE 03 ACTIONS4 POSE neck2head ( 0 . , 1 0 0 0 . , 1 0 0 . ) ,5 uTorso2neck ( 0 . , 1 0 0 0 . , 1 0 0 . ) ,6 waist ( 0 . , 6 0 0 . , 1 0 . ) ,7 lTorso2uTorso ( 0 . , 6 0 0 . , 6 0 . ) ;89 POSE rElbow ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ,10 lElbow ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ,11 rWrist ( 0 . 0 , 1 0 0 . , 1 0 . ) ,12 lWr i s t ( 0 . 0 , 1 0 0 . , 1 0 . ) ;1314 LIPOSE rShoulder ( 0 . ) . time ( dt ) ;15 LIPOSE lShou lde r ( 0 . ) . time ( dt ) ;16 LIPOSE rHip ( 0 . 0 ) . time ( dt ) ;17 LIPOSE lHip ( . 0 ) . time ( dt ) ;1819 LIPOSE rKnee ( 0 . ) . time ( dt ) ;20 LIPOSE lKnee ( 0 . ) . time ( dt ) ;21 LIPOSE rAnkle ( 0 . ) . time ( dt ) ;22 LIPOSE lAnkle ( 0 . ) . time ( dt ) ;2324 VFFB uTorso (2000 . , 2 5 0 . ) . by ( rAnkle ) . over ( cop ) ;25 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;26 ENDACTIONS27 TRANSITION to ( 1 ) . a f t e r ( time dt2 ) ;28 ENDPHASE29 PHASE 130 ACTIONS31 VFFB uTorso (2000 . , 2 5 0 . ) . by ( rAnkle ) . over ( cop ) ;32 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;33 ENDACTIONS34 TRANSITION to (−1). a f t e r ( s t ab l e . 0 1 ) ;35 ENDPHASE36 ENDSCRIPTFigure 5.4: Stand script31Figure 5.5: Standing motionThis script is divided into two phases. In the first phase, we set simplePD controllers on all joints that do not contribute to the standing motion.This serves the purpose of bringing those joints to a known rest state. Also,linearly interpolated PD controllers are used to move all joints between theankles and hips to angles of zero, forcing the character upright. The userspecified parameter dt controls the speed at which the character achieves thisstanding pose. Finally, virtual force feedback is used to keep the characterbalanced during the rising motion.After the character has risen, he enters the second phase. Here, theonly primitives used are feedback laws to keep the character balanced. Thisphase serves the purpose of waiting until the character has become stable, asspecified by the transition. The controller exits after achieving this stability.Because of the simplicity of this controller, accompanied by the feedback,it is generally successful, as long as the initial character state has the centerof mass relatively close to the center of pressure (horizontally). This, com-bined with the fact that the output character state is fairly consistent, makesthe stand controller an integral part of connecting sequences of motions, asdiscussed in section 5.3. The finished result is shown in Figure 5.5A selection of other controllers produced in our language can be seen inFigure 5.11.325.2 Controller RobustnessThere are a number of situations in which a given controller can fail. Perhapsone of the most predominant issues is that of significant perturbations ofthe initial character state. The domain of initial states which will cause acontroller to achieve its desired goal is known as the basin of attraction tothat controller.In general, smoother, slower motions with significant feedback built inhave larger basins of attraction, while highly dynamic controllers are moresensitive to their initial state. For instance, the squat and stand controllersgenerally have very little dynamic motion as the feet never have to leave theground. Virtual force feedback terms help to control the center of mass andmaintain stability.As it starts and ends from the highly stable squatting state, the backflipis surprisingly stable for small changes in initial state and environment.Figure 5.6 shows the backflip controller performed on various terrain slopes.SIMBICON style locomotion controllers are also very robust, as theyhave significant feedback to control foot placement. Figure 5.7 shows anumber of locomotion controllers over terrain of varying slope.Figure 5.6: Robustness of backflip controller. Top Left: 7.5 degree slope(successful). Top Right: 8 degree slope (fails initially). Bottom: -4 degreeslope (fails on landing)33Figure 5.7: Robustness of locomotion controllers. Simbicon style controllers(walk, skip, fastwalk, run) over varying terrain5.3 Controller TransitionsWhile our language facilitates the design of scripts for individual motions,connecting these controllers is a more challenging problem.A na¨ıve approach is to design the majority of controllers to start froma single pose, so that they may be connected by using the given pose asan intermediate controller. For example, when we design the hop motion,the first step is to call the stand script, which consists of a simple posecomplete with balance feedback. In addition, it waits until the characterhas achieved stability for the joints and for center of mass before exitingand returning to the main hop motion. In this way, we guarantee that thehop starts from a very specific initial state, as defined by the stand script.The process of transitioning from another controller to the hop then simplyrequires designing other scripts to end at the stand pose—or close enoughthat the stand script will be successful.As an example, if we wish to connect the walk controller to the hopcontroller, we use the intermediate walk-to-stop controller, which slowlybrings the walk motion to a standstill, after which the stand motion may34then be called. Once the character has reached stability in the stand, the hopcan be successfully executed. The stand script is chosen as an intermediatebecause it is highly stable and provides sufficient feedback. Other scripts,including the squat and SIMBICON-like locomotion scripts, are also highlystable and make for good intermediaries.Through this process, we have been able to create a number of motionsequences though our controller graph, as shown in Figures 5.9, and 5.10.Figure 5.8 shows a sequence of the step up and hop controllers interactingwith the environment.Figure 5.8: Motion sequence with environmental features. A sequence ofstep up and hop controllers over changing terrain is depictedWhile this process is often successful, enabling us to create long se-quences of connected controllers such as that in Figure 5.1, it often requiressmall stability tolerances, which leads to lengthy pauses while the characterattempts to achieve stability. In addition, it can fail for dynamic motions,which would require unrealistic tolerances.An alternative is to employ an optimization to automatically create newtransitions. This method is explored in the next chapter.35Figure 5.9: Sequence of connected controllers. Top: Hard coded sequencethrough the integrated controller graph. Bottom: Corresponding simulation.36Figure 5.10: Random motion sequences. Motion sequences producedthrough random walkthroughs of the integrated controller graph. The firstfails on the kip, while the second fails on the handstand.Figure 5.11: Selection of controllers. Top: Walk, Middle: Backflip, Bottom:Forward Walkover37Chapter 6Learning Transitions6.1 InspirationIn the previous chapter, we discussed how long sequences of motion can becreated through a system of transitions between controllers. In general, mostcontrollers are highly dependent upon the initial character state. Becauseof this, many transitions will either fail or cause the transitioned controllerto fail. A na¨ıve way to overcome this is to design a number of transitioningcontrollers, which end at a stable character state. Then, other controllerscan be designed from this output state. By using these highly stable transi-tioning controllers, long sequences of motion can be created. However, thesecan still fail for transitions to highly dynamic controllers, and also lead tolengthy pauses while the character achieves stability in joint space.To overcome this, we propose an optimization framework based on mu-tating existing controllers through derivative-free evolutionary methods tocreate new transitions so that longer, more fluid, motion sequences can beeasily designed.Our optimization framework is able to assist with the creation oftransitions in a number of ways:Learn New TransitionsWhile our integrated controller graph (Figure 5.1) already has a numberof transitions between similar controllers (for instance, many of the SIMBI-CON controllers are robust to na¨ıve transitions), the process of designingdirect transitions between other motions can be difficult and often producesawkward motions.Our transition optimization framework provides a simple way to38automatically learn new transitions between controllers. This greatlyexpands the number of paths that can be taken when creating longermotion sequences.Smooth Existing TransitionsMany of the transitions designed through a direct, na¨ıve approach areawkward and involve long pauses while the character attempts to achievestability in joint space. Our optimization framework can be used to requireminimal energy or time spent in these transitions in order to eliminate thepauses and make the transitions more realistic.Correct Perturbed TransitionsFinally, many of the na¨ıve transitions are only successful for a giveninitial character state. Even a small perturbation in the character’s statecan cause the transition to fail. This is also true in the case of perturbationsin the environment, such as when performing the motions on a slope. Ourframework can be used to modify the transitioning controller in order tocorrect the transition for these perturbations.6.2 Optimization6.2.1 UnknownsIn our optimization scheme, we are attempting to optimize over specifiedphases of a given input controller. To do this, we optimize all numericalparameters that are used in the phase specification, in other words, thoseused in motion primitives, feedback laws, and transitions.For example, in the PD Controller primitive, the desired joint angle,gains, and duration are all included in the unknowns. In virtual force feed-back laws, the gain parameters are subject to optimization. For transitions,the phase time or stability tolerance are both optimized. Integer values suchas the number of iterations before transitioning or categorical parameterssuch as the given body part or joint are not optimized. The set of motion39primitives present is not changed. In this way, we keep the original intentof the controller, and simply modify the exact values used. Our unknownvector x is simply a list of all of these numerical values.6.2.2 Objective FunctionsOur overall function E is given as the weighted sum of a number of individualobjective termsE =n∑iwiFi(x)where Fi are individual objective functions and wi their correspondingweights.We split the individual objectives into two groups, those that are alwayspresent during the optimization, and others that are optional. The primarygoal of the first group is for the character to match a known successfultrajectory upon switching to the new controller. We define this using asthree separate objective terms. The second group helps to provide stylizedor smoother transitions.The first of the objective terms is trajectory of the center of mass. Wedefine this objective term asF1 =n∑t=0(ca,t − cd,t)2where cd,t is the position of the center of mass in the known trajectory attime t, and ca,t is the position of the center of mass in the current iterationof the optimization.To avoid possible local minima where the center of mass trajectory ismatched, but in a different manner than intended, we add in an objectiveterm to track the global orientation of the character.F2 =n∑t=0(φa,t − φd,t)240where φa,t is the angle of the upper torso in world coordinates in the currentiteration at time t, and φd,t is the desired angle at time t.Finally, we also track the local joint angles of the characterF3 =m∑i=0n∑t=0(θi,a,t − θi,d,t)2with θi,a,t, θi,d,t the joint angles of the ith joint at time t in the currentiteration of the optimization and the desired trajectory respectively.Together, the objective functions F1, F2, and F3 encode a target trajec-tory that the optimized controller should follow.We allow the user to specify extra objective functions, such as limitingthe time spent in a phase or minimizing energy cost. For minimizing thetime spent in phase p, we use the objective functionFtime = tpwhere tp is the time spent in phase p. The objective function for minimizingenergy cost is given asFenergy = tpjoints∑iτ2iwhere τi is the control torque of joint i, and tp the time spent in phase p.These additional objective functions allow for more stylistically pleasingtransitions and tend to be useful in improving existing transitions.6.2.3 Covariance Matrix AdaptationOur choice of optimization method is a variant of Covariance Matrix Adap-tation known as (1+1)-CMA-ES [17]. In (1+1)-CMA, only one offspring isgenerated for each parent, replacing it if it has a better fitness. Instead ofkeeping track of an evolution path, as in standard CMA-ES, we keep trackof an averaged success rate, and adjust the global step size in accordancewith this. If the success rate is low, the step size should be decreased, andvice versa. (1+1)-CMA-ES has the benefit of being easy to implement, while41maintaining the performance of standard, non-elitist CMA-ES.The full optimization strategy can be summarized as follows: In eachgeneration of the optimization, we create one child set of unknowns basedon a normal distribution around the current optimal unknowns and scaledby the (1+1)-CMA-ES step size. After running the simulation with the childparameters, the objective function is evaluated, and if it has a better fitnessthan the previous optimal, the child set of unknowns replaces the parent.Finally, the success rate is updated and used to determine the new step size.The process is then repeated until the fitness drops below a pre-definedtolerance, or a designated limit for the number of generations is reached.6.3 ResultsFor most transitions, the (1+1)-CMA-ES optimization would convergewithin 200 generations, providing favorable results. An initial step size of0.002 was used for the majority of motions. The overall time spent opti-mizing each transition is dependent upon the length of the goal trajectoryand the transitioning controller. Goal trajectories were generally between2 and 5 seconds, leading to optimization times ranging from 10 minutes toan hour. All optimizations were performed on Linux Mint 16 with an IntelCore i5 CPU and an Nvidia GTX285 GPU.6.3.1 Walk to Forward WalkoverWhile the transition from the forward walkover into the walk motion (or themajority of SIMBICON-based controllers, for that matter), generally worksfine, the reverse na¨ıve transition fails.Through our optimization framework, we have created a new transitionbetween the walk and forward walkover controllers as in Figure 6.1.6.3.2 Skip to WalkDuring one of the random walkthroughs of the integrated controller graph,we found that the initial character state into the skipping controller had42been perturbed just enough so that when the character tried to transitionto the walking motion, the motion failed.After optimization, the controller was modified to adapt for the pertur-bations, allowing for a successful transition from the perturbed skip to thewalk, shown in Figure 6.2.6.3.3 Walk to StandAn initial attempt to transition straight from the walking controller resultsin the character falling over because his feet suddenly stop while the center ofmass still has forward momentum. After optimization, the character learnsto slow down during the last few cycles of the walk controller, resulting in asuccessful transition, as shown in Figure 6.3.6.3.4 Forward Walkover to RunTransitioning from the forward walkover to the run is successful with ana¨ıve approach, but awkward. Upon transitioning, the character beginsto run backward in order to regain his balance, before resuming to thestandard run. After optimization, the character retains his forward velocity,smoothly entering the run after transitioning. The center of mass trajectorydemonstrating this transition is shown in Figure 6.4.6.3.5 Forward Walkover over BoxWhen a box is added to the scene, the forward walkover controller thatworks on flat ground is unsuccessful. Using our optimization framework,we adapt the controller so that it still follows the successful trajectory, asshown in Figure 6.5.43Figure 6.1: Walk to forward walkover transition. Top: Initial (failed) at-tempt. Bottom: Sucessful optimized transition.Figure 6.2: Skip to walk transition. The transition between the skip andwalk controllers is optimized. Left: Initial (failed) transition. Right: Opti-mized transitionFigure 6.3: Walk to stand transition. The transition between the walk andstand controllers is optimized. The top image shows the initial attempt, andthe lower image shows the successful transition after optimization44Figure 6.4: Forward walkover to run transition. The transition between theforward walkover controllers and run controllers is optimized. The centerof mass trajectory is shown, with X representing the transition. The na¨ıveapproach on the left shows the character running backward slightly to regainhis balance. The optimized result is on the right.Figure 6.5: Forward walkover with obstacle. Optimization of the forwardwalkover when an obstacle is added. Top: Failed initial attempt. Bottom:Successful modified controller45Chapter 7ConclusionAuthoring controllers for humanoid motion is still a challenging problem,with no clearly defined standard for their design. Current approaches con-tinue to focus on algorithmic novelty, while the capabilities of existing tech-niques has still not been explored to its full potential. This work attemptsto address these problems by defining a universal controller authoring lan-guage that is simple enough to be intuitive, while still being comprehensive,employing many common features of existing approaches. We have demon-strated how the language can be used to design a large number of con-trollers for a planar humanoid character. We have further shown how thesecontrollers can be integrated through a system of designing and optimizingtransition motions.There is still work that needs to be pursued for a universal motion designlanguage to be even more successful. Crowd sourcing is an obvious futuredirection. A readily available, web based version of our framework in whichnovice and professional users alike could design and submit motions wouldbe essential for creating a vast database of controllers. In addition, theframework should be able to automatically detect how newly submittedcontrollers could be integrated with existing ones in the database. Ourframework of learning new transitions between controllers is a start to this,but it is still limited in that it only handles controllers that start from aspecified character state. One idea to tackle this problem is to learn amodel of the basin of attraction of valid input states for a controller [10].Another possibility is to interpolate between existing transition controllersthat have been shown to be successful for different character states.The idea of creating controllers from motion captured data has beenexplored in [7, 19, 29]. This presents another possible future direction for46our work, in combining our optimization framework with motion capturedata. Given that a center of mass trajectory could be determined from themocap data, our system could be used to optimize an existing controller tomatch the captured motion, as well as create transitions into the motion.Another interesting direction is to further generalize the language tocreate primitives at a higher level. An idea similar to Ha and Liu’s controlrigs could map lower level controllers such as PD or Jacobian transposecontrol to more intuitive, human-readable instructions, such as those usedby a coach when teaching his students [12]. This could open up the languageto novice users who could issue a simple instruction as they would to anotherhuman being. Generalizing the language even further could allow the userto specify tasks such as ”move to a given location,” allowing the systemto automatically find a path through the integrated controller graph whichwould achieve the desired result.While generalizing primitives even further will increase the power andease of designing motions, some motions, such as those that are highly dy-namic, will likely still involve tedious parameter tuning to produce a success-ful, robust motion. In its current state, every time a script in our language ismodified, the simulation has to be restarted in order to see the change. Forcomplex or longer motions, this process can be incredibly time consuming.One possible future direction for this work is a live scripting environment,similar to that presented by Bret Victor’s 2012 talk at CUSEC, Inventing onPrinciple [33]. Victor presents a game involving a simple character, whichcan be paused at any time, and a ghost trail of the character as it would besimulated is shown.Then, the user can modify the code that controls the simulation, andthe trail updates accordingly. The ability to see what a simple change oraddition to a script in real time would have the potential to greatly reducethe time spent designing controllers. This could be extended to simulta-neously show the simulated controller for a number of perturbations of theinitial character state, which could help to design more robust controllers.Applying these ideas to a physically simulated character could prove morechallenging. For instance, every small change in the code would require a47Figure 7.1: Example from Inventing on Principle. The ‘future trail’ of thecharacter updates as the code is changed in real timenew simulation from the given timepoint, which is far less trivial for a physi-cally simulated N-link character than for the simple sprite shown in Victor’stalk.48Bibliography[1] Mazen Al Borno, Eugene Fiume, A Hertzmann, and M de Lasa. Feed-back control for rotational movements in feature space. In ComputerGraphics Forum, volume 33, pages 225–233. Wiley Online Library,2014.[2] Joel Chestnutt, Manfred Lau, German Cheung, James Kuffner, JessicaHodgins, and Takeo Kanade. Footstep planning for the honda asimohumanoid. In Robotics and Automation, 2005. ICRA 2005. Proceedingsof the 2005 IEEE International Conference on, pages 629–634. IEEE,2005.[3] Seth Cooper, Firas Khatib, Adrien Treuille, Janos Barbero, JeehyungLee, Michael Beenen, Andrew Leaver-Fay, David Baker, Zoran Popovic´,et al. Predicting protein structures with a multiplayer online game.Nature, 466(7307):756–760, 2010.[4] Stelian Coros, Philippe Beaudoin, and Michiel van de Panne. Robusttask-based control policies for physics-based characters. In ACM Trans-actions on Graphics (TOG), volume 28, page 170. ACM, 2009.[5] Stelian Coros, Philippe Beaudoin, and Michiel van de Panne. Gener-alized biped walking control. ACM Transactions on Graphics (TOG),29(4):130, 2010.[6] Stelian Coros, Andrej Karpathy, Ben Jones, Lionel Reveret, and MichielVan De Panne. Locomotion skills for simulated quadrupeds. ACMTransactions on Graphics (TOG), 30(4):59, 2011.49[7] Marco Da Silva, Yeuhi Abe, and J Popovic´. Simulation of human mo-tion data using short-horizon model-predictive control. In ComputerGraphics Forum, volume 27, pages 371–380. Wiley Online Library,2008.[8] Marco Da Silva, Fre´do Durand, and Jovan Popovic´. Linear bellmancombination for control of character animation. In Acm transactionson graphics (tog), volume 28, page 82. ACM, 2009.[9] Martin de Lasa, Igor Mordatch, and Aaron Hertzmann. Feature-based locomotion controllers. ACM Transactions on Graphics (TOG),29(4):131, 2010.[10] Petros Faloutsos, Michiel Van de Panne, and Demetri Terzopoulos.Composable controllers for physics-based character animation. In Pro-ceedings of the 28th annual conference on Computer graphics and in-teractive techniques, pages 251–260. ACM, 2001.[11] Thomas Geijtenbeek and Nicolas Pronost. Interactive character anima-tion using simulated physics: A state-of-the-art review. In ComputerGraphics Forum, volume 31, pages 2492–2515. Wiley Online Library,2012.[12] Sehoon Ha and C Karen Liu. Iterative training of dynamic skills in-spired by human coaching techniques. ACM TRANSACTIONS ONGRAPHICS, 2014.[13] Sehoon Ha, Yuting Ye, and C Karen Liu. Falling and landing mo-tion control for character animation. ACM Transactions on Graphics(TOG), 31(6):155, 2012.[14] Nikolaus Hansen and Andreas Ostermeier. Completely derandom-ized self-adaptation in evolution strategies. Evolutionary computation,9(2):159–195, 2001.[15] Jessica K Hodgins and Nancy S Pollard. Adapting simulated behaviorsfor new characters. In Proceedings of the 24th annual conference on50Computer graphics and interactive techniques, pages 153–162. ACMPress/Addison-Wesley Publishing Co., 1997.[16] Jessica K Hodgins and Wayne L Wooten. Animating human athletes.Springer, 1998.[17] Christian Igel, Thorsten Suttorp, and Nikolaus Hansen. A computa-tional efficient covariance matrix update and a (1+ 1)-cma for evolutionstrategies. In Proceedings of the 8th annual conference on Genetic andevolutionary computation, pages 453–460. ACM, 2006.[18] Joseph Laszlo, Michiel van de Panne, and Eugene Fiume. Limit cyclecontrol and its application to the animation of balancing and walking.In Proceedings of the 23rd annual conference on Computer graphics andinteractive techniques, pages 155–162. ACM, 1996.[19] Yoonsang Lee, Sungeun Kim, and Jehee Lee. Data-driven biped control.ACM Transactions on Graphics (TOG), 29(4):129, 2010.[20] Libin Liu, KangKang Yin, Michiel van de Panne, and Baining Guo.Terrain runner: control, parameterization, composition, and planningfor highly dynamic motions. ACM Trans. Graph., 31(6):154, 2012.[21] Adriano Macchietto, Victor Zordan, and Christian R Shelton. Momen-tum control for balance. In ACM Transactions on Graphics (TOG),volume 28, page 80. ACM, 2009.[22] Igor Mordatch, Martin De Lasa, and Aaron Hertzmann. Robustphysics-based locomotion using low-dimensional planning. ACM Trans-actions on Graphics (TOG), 29(4):71, 2010.[23] Eric Niebler. Boost. xpressive, 2007.[24] Jerry Pratt, Chee-Meng Chew, Ann Torres, Peter Dilworth, and GillPratt. Virtual model control: An intuitive approach for bipedal loco-motion. The International Journal of Robotics Research, 20(2):129–143,2001.51[25] Morgan Quigley, Ken Conley, Brian Gerkey, Josh Faust, Tully Foote,Jeremy Leibs, Rob Wheeler, and Andrew Y Ng. Ros: an open-sourcerobot operating system. In ICRA workshop on open source software,volume 3, 2009.[26] Marc Raibert, Kevin Blankespoor, Gabriel Nelson, Rob Playter, et al.Bigdog, the rough-terrain quadruped robot. In Proceedings of the 17thWorld Congress, pages 10823–10825, 2008.[27] Marc H Raibert and Jessica K Hodgins. Animation of dynamic leggedlocomotion. In ACM SIGGRAPH Computer Graphics, volume 25,pages 349–358. ACM, 1991.[28] R. Smith and Others. Open dynamics engine, 2003.[29] Kwang Won Sok, Manmyung Kim, and Jehee Lee. Simulating bipedbehaviors from human motion data. In ACM Transactions on Graphics(TOG), volume 26, page 107. ACM, 2007.[30] Craig Sunada, Dalila Argaez, Steven Dubowsky, and ConstantinosMavroidis. A coordinated jacobian transpose control for mobile multi-limbed robotic systems. In Robotics and Automation, 1994. Proceed-ings., 1994 IEEE International Conference on, pages 1910–1915. IEEE,1994.[31] Yao-Yang Tsai, Wen-Chieh Lin, Kuangyou B Cheng, Jehee Lee, andTong-Yee Lee. Real-time physics-based 3d biped character animationusing an inverted pendulum model. Visualization and Computer Graph-ics, IEEE Transactions on, 16(2):325–337, 2010.[32] Steve Upstill. RenderMan Companion: A Programmer’s Guide to Re-alistic Computer Graphics. Addison-Wesley Longman Publishing Co.,Inc., 1989.[33] Bret Victor. Inventing on principle, 2012.[34] Chris Welman. Inverse kinematics and geometric constraints for artic-ulated figure manipulation. PhD thesis, Simon Fraser University, 1993.52[35] Wayne L Wooten. Simulation of leaping, tumbling, landing, and bal-ancing humans. 1998.[36] Yuting Ye and C Karen Liu. Optimal feedback control for characteranimation using an abstract model. ACM Transactions on Graphics(TOG), 29(4):74, 2010.[37] KangKang Yin, Kevin Loken, and Michiel van de Panne. Simbicon:Simple biped locomotion control. In ACM Transactions on Graphics(TOG), volume 26, page 105. ACM, 2007.53Appendices54Appendix AScriptsA.1 Stable Pose ScriptsA.1.1 Squat1 #Fi l e : squatVFFB . s2 #Desc r ip t i on : Performs a squat motion3 #Inputs : dt − Time to ach ieve and stay in squat pose4 BEGINSCRIPT SQUATPOSE( dt )5 PHASE 06 ACTIONS7 LIPOSE neck2head ( 0 . , 1 0 0 0 . , 1 0 0 . ) . time ( dt ) ;8 LIPOSE uTorso2neck ( 0 . , 1 0 0 0 . , 1 0 0 . ) . time ( dt ) ;9 LIPOSE lTorso2uTorso ( 0 . , 6 0 0 . , 1 0 . ) . time ( dt ) ;10 LIPOSE waist ( 0 . 0 , 6 0 0 . , 1 0 . ) . time ( dt ) ;11 LIPOSE rShoulder ( −1 .7) . time ( dt ) ;12 LIPOSE lShou lde r ( −1 .7) . time ( dt ) ;13 LIPOSE rHip ( −1 .6) . time ( dt ) ;14 LIPOSE lHip ( −1 .6) . time ( dt ) ;15 LIPOSE rKnee ( 2 . ) . time ( dt ) ;16 LIPOSE lKnee ( 2 . ) . time ( dt ) ;17 LIPOSE rAnkle ( − . 6 ) . time ( dt ) ;18 LIPOSE lAnkle ( − . 6 ) . time ( dt ) ;19 POSE rElbow ( −0 . , 5 0 . , 3 0 . ) , lElbow ( −0 . , 5 0 . , 3 0 . ) ;20 POSE rWrist ( − . 2 , 5 . , 3 . ) , lWri s t ( − . 2 , 5 . , 3 . ) ;21 VFFB uTorso ( 2 0 0 0 . , 2 5 0 . ) . by ( rAnkle ) . over ( cop ) ;22 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;23 ENDACTIONS24 TRANSITION to (−1). a f t e r ( f a l l e n x 1 . 2 ) ;25 TRANSITION to ( 1 ) . a f t e r ( time dt ) ;26 ENDPHASE27 PHASE 128 ACTIONS29 VFFB uTorso (2000 . , 4 5 0 . ) . by ( rAnkle ) . over ( cop ) ;30 VFFB uTorso (2000 . , 4 5 0 . ) . by ( lAnkle ) . over ( cop ) ;31 ENDACTIONS32 TRANSITION to (−1). a f t e r ( f a l l e n x 1 . 2 ) ;5533 TRANSITION to (−1). a f t e r ( s t ab l e . 0 1 ) ;34 ENDPHASE35 ENDSCRIPTA.1.2 Stand1 #Fi l e : standVFFB . t2 #Desc r ip t i on : Ri se s and ba lances in a stand s t a t e3 #Inputs : dt − Rise durat ion ; dtt − Cont r o l l e r durat ion4 BEGINSCRIPT STANDINGPOSE( dt , dtt )56 PHASE 07 ACTIONS8 POSE neck2head ( 0 . , 1 0 0 0 . , 1 0 0 . ) , uTorso2neck ( 0 . , 1 0 0 0 . , 1 0 0 . ) ,9 waist ( 0 . , 6 0 0 . , 1 0 . ) , lTorso2uTorso ( 0 . , 6 0 0 . , 6 0 . ) ;10 POSE rElbow ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) , lElbow ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ;11 POSE rWrist ( 0 . 0 , 1 0 0 . , 1 0 . ) , lWri s t ( 0 . 0 , 1 0 0 . , 1 0 . ) ;12 LIPOSE rShoulder ( 0 . ) . time ( dt ) ;13 LIPOSE lShou lde r ( 0 . ) . time ( dt ) ;14 LIPOSE rHip ( 0 . 0 ) . time ( dt ) ;15 LIPOSE lHip ( . 0 ) . time ( dt ) ;16 LIPOSE rKnee ( 0 . ) . time ( dt ) ;17 LIPOSE lKnee ( 0 . ) . time ( dt ) ;18 LIPOSE rAnkle ( 0 . ) . time ( dt ) ;19 LIPOSE lAnkle ( 0 . ) . time ( dt ) ;20 VFFB uTorso (2000 . , 2 5 0 . ) . by ( rAnkle ) . over ( cop ) ;21 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;22 ENDACTIONS23 TRANSITION to ( 1 ) . a f t e r ( time dtt ) ;24 ENDPHASE25 PHASE 126 ACTIONS27 VFFB uTorso (2000 . , 2 5 0 . ) . by ( rAnkle ) . over ( cop ) ;28 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lAnkle ) . over ( cop ) ;29 ENDACTIONS30 TRANSITION to (−1). a f t e r ( s t ab l e . 0 1 ) ;31 ENDPHASE32 ENDSCRIPTA.2 Dynamic ScriptsA.2.1 Backflip1 #Fi l e : b a c k f l i p . t2 #Desc r ip t i on : Performs a ba ck f l i p3 #Precond i t ion : Squat Pose564 #Inputs : void5 SCRIPTS balanceh ighsquat . t , squat . t , r i s e . t , stand . t , squatVFFB . t ;67 SET TORQUELIMIT = 100089 BEGINSCRIPT ba ck f l i p ( void )10 PHASE 011 ACTIONS12 POSE rShoulder ( −2 . 2 , 300 . , 30 . ) , l Shou lde r ( −2 . 2 , 3 00 . , 3 0 . ) ;13 VF ( −900 ,3500 ,0 . ) . on ( uTorso ) . by ( rAnkle ) ;14 VF ( −900 ,3500 ,0 . ) . on ( uTorso ) . by ( lAnkle ) ;15 ENDACTIONS16 TRANSITION to ( 1 ) . a f t e r ( time . 2 ) ;17 ENDPHASE18 PHASE 119 ACTIONS20 POSE rAnkle (−1) , lAnkle (−1);21 POSE rKnee ( 2 . 3 ) , lKnee ( 2 . 3 ) ;22 POSE rHip (−2.) , lHip ( −2 . ) ;23 POSE rShoulder (−2.) , lShou lde r ( −2 . ) ;24 POSE rElbow (−1.6) , lElbow ( −1 .6) ;25 POSE waist ( . 7 ) , lTorso2uTorso ( . 7 ) ;26 ENDACTIONS27 TRANSITION to ( 2 ) . a f t e r ( contact rFoot ) ;28 ENDPHASE29 PHASE 230 TRANSITION to ( 4 ) . a f t e r ( time . 2 ) ;31 ACTIONS32 POSE rAnkle (− .5) , lAnkle ( − . 5 ) ;33 POSE rKnee ( 2 . 3 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 2 . 3 , 1 0 0 0 . , 1 0 0 . ) ;34 POSEFB rAnkle ( 2 . 2 , . 5 ) . on ( part lFoot ) ;35 POSEFB lAnkle ( 2 . 2 , . 5 ) . on ( part lFoot ) ;36 ENDACTIONS37 ENDPHASE38 PHASE 339 > ba lanceh ighsquat . t ( 5 ) ;40 TRANSITION to ( 4 ) . a f t e r ( complete ) ;41 ENDPHASE42 PHASE 443 > squatVFFB . t ( 2 ) ;44 TRANSITION to (−1). a f t e r ( complete ) ;45 ENDPHASE46 ENDSCRIPTA.2.2 Forward Hop1 #Fi l e : fwdhop . s572 #Desc r ip t i on : Performs a bunny hop . standVFFB . t c a l l e d to s t a b i l i z e3 #Inputs : void4 SCRIPTS standVFFB . t ;5 BEGINSCRIPT fwdhop ( void )6 PHASE 07 > standVFFB . t (1 , 1 ) ;8 TRANSITION to ( 1 ) . a f t e r ( complete ) ;9 ENDPHASE10 PHASE 111 ACTIONS12 POSE rElbow (−1.7) , lElbow ( −1 .7) ;13 ENDACTIONS14 TRANSITION to ( 2 ) . a f t e r ( time 1 ) ;15 ENDPHASE16 PHASE 2 # Star t l e an ing forward17 ACTIONS18 POSE rElbow (− .4 , 8 0 . , 3 0 . ) , lElbow (− .4 , 8 0 . , 3 0 . ) ;19 POSE rShoulder ( . 5 , 8 0 . , 3 0 . ) , l Shou lde r ( . 5 , 8 0 . , 3 0 . ) ;20 POSE rHip (− .6 , 8 0 . , 3 0 . ) , lHip (− .6 , 8 0 . , 3 0 . ) ;21 POSE rKnee ( . 3 , 1 2 0 . , 3 0 . ) , lKnee ( . 3 , 1 2 0 . , 3 0 . ) ;22 POSE rAnkle (− .4 , 8 0 . , 3 0 . ) , lAnkle (− .4 , 8 0 . , 3 0 . ) ;23 ENDACTIONS24 TRANSITION to ( 3 ) . a f t e r ( time . 5 ) ;25 ENDPHASE26 PHASE 3 # Bend knees27 ACTIONS28 POSE rHip ( −1 .3 ,180 . , 3 0 . ) , lHip ( −1 . 3 , 1 80 . , 3 0 . ) ;29 POSE rKnee ( 1 . 2 , 150 . , 3 0 . ) , lKnee ( 1 . 2 , 1 5 0 . , 3 0 . ) ;30 POSE rAnkle (− .5 , 100 . , 1 0 . ) , lAnkle (− .5 , 100 . , 1 0 . ) ;31 ENDACTIONS32 TRANSITION to ( 4 ) . a f t e r ( time . 3 ) ;33 ENDPHASE34 PHASE 4 # Jump !35 ACTIONS36 POSE rShoulder (− .5 , 8 0 . , 3 0 . ) , l Shou lde r ( − . 5 , 8 0 . , 3 0 . ) ;37 VPD uTorso ( . 7 5 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;38 VPD uTorso ( . 7 5 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;39 VF (−200 , −3000 , 0 ) . on ( rFoot ) . by ( rHip ) ;40 VF (−200 , −3000 , 0 ) . on ( lFoot ) . by ( lHip ) ;41 POSE rAnkle ( 0 ) ;42 POSE lAnkle ( 0 ) ;43 ENDACTIONS44 TRANSITION to ( 5 ) . a f t e r ( nocontact rFoot ) ;45 ENDPHASE46 PHASE 5 # mid jump47 ACTIONS48 POSE rHip ( −0 . 7 , 1000 . , 100 . ) , lHip ( −0 . 7 , 1 000 . , 1 00 . ) ;5849 POSE rKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) ;50 POSE rAnkle (− .4) , lAnkle ( − . 4 ) ;51 POSE rShoulder ( −1 . 7 , 80 . , 3 0 . ) , l Shou lde r ( −1 . 7 , 8 0 . , 3 0 . ) ;52 ENDACTIONS53 TRANSITION to ( 7 ) . a f t e r ( contact rFoot ) ;54 ENDPHASE55 PHASE 6 # landing56 ACTIONS57 POSE rHip ( −1 . 1 , 1000 . , 100 . ) , lHip ( −1 . 1 , 1 000 . , 1 00 . ) ;58 POSE rKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) ;59 POSE rAnkle (− .3 , 1000 . , 1 0 0 . ) , lAnkle (− .3 , 1000 . , 1 0 0 . ) ;60 ENDACTIONS61 TRANSITION to ( 7 ) . a f t e r ( time . 2 ) ;62 ENDPHASE63 PHASE 764 > standVFFB . t (1 , 1 ) ;65 TRANSITION to (−1). a f t e r ( f a l l e n x . 6 ) ;66 TRANSITION to (−1). a f t e r ( complete ) ;67 ENDPHASE68 ENDSCRIPTA.2.3 Forward Walkover1 #Fi l e : fwdhandspring . s2 #Desc r ip t i on : Performs a forward walkover .3 #Inputs : void4 SCRIPTS step . t , walk . s ;5 BEGINSCRIPT fwdhandspring ( void )6 PHASE 0 # s t a r t with a walk s tep7 > s tep . t ( void ) ;8 TRANSITION to ( 1 ) . a f t e r ( complete ) ;9 ENDPHASE10 PHASE 1 # s t a r t l e an ing forward11 TRANSITION to ( 2 ) . a f t e r ( time . 5 ) ;12 ACTIONS13 POSE rShoulder ( −1 . 7 , 150 . , 30 . ) , l Shou lde r ( −1 . 7 , 1 50 . , 3 0 . ) ;14 POSE lKnee ( 0 . 0 5 ) , rKnee ( . 5 ) ;15 POSE lHip ( . 3 , 2 0 0 . , 3 0 . ) , rHip ( −1 , 200 . , 30 . ) ;16 POSE rAnkle ( 0 . ) , lAnkle ( . 4 ) ;17 POSE rElbow (− .5) , lElbow ( − . 5 ) ;18 ENDACTIONS19 ENDPHASE20 PHASE 2 # lean forward21 TRANSITION to ( 3 ) . a f t e r ( time . 2 ) ;22 ACTIONS23 POSE waist ( . 3 ) , lTorso2uTorso ( . 3 ) ;24 POSE rShoulder (−1.8) , lShou lde r ( −1 .8) ;5925 POSE rWrist (−1.5) , lWri s t ( −1 .5) ;26 POSE lKnee (0 . 05 , 500 , 30 ) , rKnee ( . 3 ) ;27 POSE rHip ( −1 . 2 , 200 . , 30 . ) , lHip ( . 3 , 2 0 0 . , 3 0 . ) ;28 POSE rAnkle ( . 2 ) , lAnkle ( . 4 ) ;29 POSE rElbow (− .2) , lElbow ( − . 2 ) ;30 ENDACTIONS31 ENDPHASE32 PHASE 3 # contact hands to ground33 TRANSITION to ( 4 ) . a f t e r ( contact lHand ) ;34 ACTIONS35 POSE rShoulder (−2.3) , lShou lde r ( −2 .3) ;36 POSE rWrist (−1) , lWr i s t (−1);37 POSE rHip (−1.5) , lHip ( . 3 ) ;38 POSE rAnkle ( . 8 ) ;39 ENDACTIONS40 ENDPHASE41 PHASE 4 # kick up42 TRANSITION to ( 5 ) . a f t e r ( time . 3 ) ;43 ACTIONS44 POSE rShoulder ( −2 . 5 , 500 . , 30 . ) , l Shou lde r ( −2 . 5 , 500 . , 30 . ) ,45 rElbow (− .5) , lElbow (− .5) ,46 rWrist (−1.5) , lWr i s t (−1.5) ,47 rHip (−1.6) , lHip ( 1 . 6 , 3 0 0 . , 2 0 0 . ) ,48 rKnee ( 0 . ) , lKnee ( 0 . ) ,49 rAnkle ( . 4 ) , lAnkle ( 0 . ) ;50 ENDACTIONS51 ENDPHASE52 PHASE 5 # balance53 TRANSITION to ( 6 ) . a f t e r ( time . 4 ) ;54 ACTIONS55 POSE waist ( − . 2 ,300 ,100) , lTorso2uTorso ( − . 2 ,300 ,100) ;56 POSE rShoulder ( −2 . 5 , 300 . , 30 . ) , l Shou lde r ( −2 . 5 , 300 . , 30 . ) ,57 rElbow (− .8) , lElbow (− .8) ,58 rWrist (−1.7) , lWr i s t (−1.7) ,59 rAnkle ( . 2 ) , lAnkle ( . 2 ) ,60 rKnee ( . 5 ) , lKnee ( . 5 ) ;61 POSE rHip (−1.4) , lHip ( 2 . 3 , 3 0 0 . , 2 0 0 . ) ;62 ENDACTIONS63 ENDPHASE64 PHASE 6 # prepare f o r land ing65 TRANSITION to ( 7 ) . a f t e r ( contact lFoot ) ;66 ACTIONS67 POSE rHip (− .3) , lHip ( 2 . , 1 0 0 0 . , 1 0 0 . ) ;68 POSE rKnee ( . 4 ) , lKnee ( 1 . 4 ) ,69 waist (− .4) , lTorso2uTorso (− .4) ,70 rShoulder (−2.7) , lShou lde r ( −2 .7) ;71 POSE rAnkle ( . 4 ) , lAnkle ( − . 8 ) ;6072 ENDACTIONS73 ENDPHASE74 PHASE 7 # land75 TRANSITION to ( 8 ) . a f t e r ( time 1 ) ;76 ACTIONS77 POSE waist ( − . 1 , 6 00 . , 6 0 . ) , lTorso2uTorso ( 0 . , 6 0 0 . , 6 0 . ) ;78 POSE rKnee ( 1 . 3 ) , lKnee ( . 3 ) , rHip (− .1) , lHip ( . 2 ) ;79 POSE rAnkle (− .0) , lAnkle ( − . 7 ) ;80 POSE rShoulder ( 0 . , 1 0 0 . , 3 0 . ) , l Shou lde r ( 0 . , 1 0 0 . , 3 0 . ) ,81 rElbow ( 0 . ) , lElbow ( 0 . ) ,82 rWrist ( 0 . ) , lWri s t ( 0 . ) ;83 ENDACTIONS84 ENDPHASE85 PHASE 886 > walk . s ( void ) ;87 TRANSITION to (−1). a f t e r ( complete ) ;88 ENDPHASE89 ENDSCRIPTA.2.4 Kip1 #Fi l e : k ip . t2 #Desc r ip t i on : Performs a kip .3 #Precond i t ion : Supine4 #Inputs : void5 SCRIPTS squatVFFB . t ;67 BEGINSCRIPT kip ( void )8 PHASE 0 #Retract9 ACTIONS10 POSE neck2head ( 0 . , 1 0 0 0 . , 1 0 0 . ) , uTorso2neck ( 0 . , 1 0 0 0 . , 1 0 0 . ) ,11 lTorso2uTorso ( 0 . , 1 0 0 0 . , 1 0 0 . ) , wa i s t ( 0 . , 1 0 0 0 . , 1 0 0 . ) ,12 rWrist (−1.57) , lWri s t ( −1 .57) ;13 LIPOSE rAnkle ( 0 . ) . time ( . 6 ) ;14 LIPOSE lAnkle ( 0 . ) . time ( . 6 ) ;15 LIPOSE rKnee ( 2 . 8 ) . time ( . 6 ) ;16 LIPOSE lKnee ( 2 . 8 ) . time ( . 6 ) ;17 LIPOSE rHip ( −1 .4) . time ( . 6 ) ;18 LIPOSE lHip ( −1 .4) . time ( . 6 ) ;19 LIPOSE rShoulder ( −2 .6) . time ( . 6 ) ;20 LIPOSE lShou lde r ( −2 .6) . time ( . 6 ) ;21 LIPOSE rElbow ( −2 .27) . time ( . 6 ) ;22 LIPOSE lElbow ( −2 .27) . time ( . 6 ) ;23 ENDACTIONS24 TRANSITION to ( 1 ) . a f t e r ( time 1 ) ;25 ENDPHASE26 PHASE 1 #Retract more , throw f e e t6127 ACTIONS28 POSE lKnee ( 0 . ) , rKnee ( 0 . ) ;29 POSE lHip (−1.7) , rHip ( −1 .7) ;30 VF ( 0 . , 0500 . , 0 ) . on ( rFoot ) . by ( rHip ) ;31 VF ( 0 . , 0500 . , 0 ) . on ( lFoot ) . by ( lHip ) ;32 ENDACTIONS33 TRANSITION to ( 2 ) . a f t e r ( time . 3 ) ;34 ENDPHASE35 PHASE 2 #Throw Lower Body36 ACTIONS37 POSE rAnkle (−1.0) , lAnkle ( −1 .0) ;38 POSE rKnee ( 1 . 5 0 5 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 5 0 5 , 1 0 0 0 . , 1 0 0 . ) ;39 POSE rHip ( . 7 8 ) , lHip ( . 7 8 ) ;40 VF ( 0 . , −4000. , 0 . ) . on ( rHand ) . by ( rShoulder ) ;41 VF ( 0 . , −4000. , 0 . ) . on ( lHand ) . by ( lShou lde r ) ;42 ENDACTIONS43 TRANSITION to ( 3 ) . a f t e r ( contact rFoot ) ;44 ENDPHASE45 PHASE 3 #Throw Upper Body46 ACTIONS47 POSE waist ( 0 . 4 , 6 0 0 . , 6 0 . ) ;48 POSE rAnkle ( − . 4 , 1000 . , 100 . ) , lAnkle ( − . 4 , 1 000 . , 1 00 . ) ;49 POSE rShoulder (−1.7) , lShou lde r ( −1 .7) ;50 POSE rElbow ( −0 . , 5 0 . , 3 0 . ) , lElbow ( −0 . , 5 0 . , 3 0 . ) ;51 POSE rWrist ( − . 2 , 5 . , 3 . ) , lWri s t ( − . 2 , 5 . , 3 . ) ;52 LIPOSE rHip (−1.1 , 1000 . , 1 0 0 . ) . time ( . 5 ) ;53 LIPOSE lHip (−1.1 , 1000 . , 1 0 0 . ) . time ( . 5 ) ;54 VFFB uTorso (1800 . , 1 0 0 . ) . by ( rAnkle ) . over ( cop ) ;55 VFFB uTorso (1800 . , 1 0 0 . ) . by ( lAnkle ) . over ( cop ) ;56 ENDACTIONS57 TRANSITION to ( 4 ) . a f t e r ( time 1 ) ;58 ENDPHASE59 PHASE 460 > squatVFFB . t ( 2 ) ;61 TRANSITION to ( 0 ) . a f t e r ( f a l l e n < − .6) ;62 TRANSITION to (−1). a f t e r ( f a l l e n > 1 . 2 ) ;63 TRANSITION to (−1). a f t e r ( complete ) ;64 ENDPHASE65 ENDSCRIPTA.3 SIMBICON Style ScriptsA.3.1 Simbicon Base1 #Fi l e : s imbicononce . t2 #Desc r ip t i on : Base s c r i p t f o r SIMBICON−s t y l e motions623 #Inputs : See SIMBICON paper4 BEGINSCRIPT simbicon ( dt , cde , cdo , cve , cvo , tor , swhe ,5 swho , swke , swko , stke , stko , ankle )6 PHASE 07 ACTIONS8 POSE neck2head ( 0 . 0 ) , uTorso2neck ( 0 . 0 ) ;9 POSE waist ( 0 . 0 , 600 . , 6 0 . ) , lTorso2uTorso ( 0 . 0 , 600 . , 6 0 . ) ;10 POSE lWris t ( 0 . 0 , 5 , 3 ) , rWrist ( 0 . 0 , 5 , 3 ) ;11 POSE rKnee ( swke ) , rAnkle ( ankle ) ;12 POSE lKnee ( s tke ) , lAnkle ( ankle ) ;13 POSE rShoulder ( . 3 , 1 00 , 3 0 ) , rElbow (0 , 1 00 , 3 0 ) ;14 POSE lShou lde r ( − . 3 ,100 ,30) , lElbow ( − . 4 , 100 ,30) ;15 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;16 COMFB2 cde cve j rAnkle17 VPD rThigh ( swhe ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;18 ENDACTIONS19 TRANSITION to ( 1 ) . a f t e r ( time dt ) ;20 ENDPHASE21 PHASE 122 TRANSITION to ( 2 ) . a f t e r ( contact rFoot ) ;23 ACTIONS24 POSE rKnee ( swko ) , lKnee ( stko ) ;25 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;26 COMFB2 cdo cvo j rAnkle27 VPD rThigh ( swho ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;28 ENDACTIONS29 ENDPHASE30 PHASE 231 TRANSITION to ( 3 ) . a f t e r ( time dt ) ;32 ACTIONS33 POSE lKnee ( swke ) ,34 rShoulder ( − . 3 ,100 ,30) , lShou lde r ( . 3 , 1 0 0 , 3 0 ) ,35 rElbow ( − . 4 ,100 ,30) , lElbow (0 , 100 , 3 0 ) ;36 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;37 COMFB2 cde cve j lAnkle38 VPD lThigh ( swhe ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;39 ENDACTIONS40 ENDPHASE41 PHASE 342 TRANSITION to (−1). a f t e r ( contact lFoot ) ;43 ACTIONS44 POSE lKnee ( swko ) , rKnee ( stko ) ;45 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;46 COMFB2 cdo cvo j lAnkle47 VPD lThigh ( swho ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;48 ENDACTIONS49 ENDPHASE6350 ENDSCRIPTA.3.2 Two Phase Simbicon Base1 #Fi l e : s imbicon2phaseonce . t2 #Desc r ip t i on : Base s c r i p t f o r 2 phase SIMBICON−s t y l e motions3 #Inputs : See SIMBICON paper4 BEGINSCRIPT simbicon ( dt , cde , cdo , cve , cvo , tor ,5 swh , swk , stk , swa , s ta )6 PHASE 07 ACTIONS8 POSE neck2head ( 0 . 0 ) , wa i s t ( 0 . 0 ) ,9 uTorso2neck ( 0 . 0 ) , lTorso2uTorso ( 0 . 0 ) ,10 lWr i s t ( 0 . 0 , 5 , 3 ) , rWrist ( 0 . 0 , 5 , 3 ) ,11 rKnee ( swk ) , rAnkle ( swa ) , lKnee ( s tk ) , lAnkle ( s ta ) ,12 rShoulder ( . 1 , 1 00 , 3 0 ) , rElbow ( −1 .7 ,100 ,30) ,13 l Shou lde r ( − . 1 ,100 ,30) , lElbow ( −1 .7 ,100 ,30) ;14 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;15 COMFB2 cde cve j rAnkle16 VPD rThigh ( swh ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;17 ENDACTIONS18 TRANSITION to ( 1 ) . a f t e r ( time dt ) ;19 ENDPHASE20 PHASE 121 ACTIONS22 POSE lKnee ( swk ) , rKnee ( s tk ) , lAnkle ( swa ) , rAnkle ( s ta ) ,23 rShoulder ( − . 1 ,100 ,30) , rElbow ( −1 .7 ,100 ,30) ,24 l Shou lde r ( . 1 , 1 0 0 , 3 0 ) , lElbow ( −1 .7 ,100 ,30) ;25 VPD uTorso ( tor , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;26 COMFB2 cde cve j lAnkle27 VPD lThigh ( swh ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;28 ENDACTIONS29 TRANSITION to (−1). a f t e r ( time dt ) ;30 ENDPHASE31 ENDSCRIPTA.3.3 Walk1 #Fi l e : walkonce . t2 #Desc r ip t i on : Walk , c a l l s SIMBICON3 #Inputs : void4 SCRIPTS simbicononce . t ;56 BEGINSCRIPT walk ( void )7 PHASE 08 > s imbicononce . t ( . 3 , 0 . 0 , −2.2 , −.2 , 0 . 0 , 0 . 0 ,9 −.4 , . 7 , 1 . 1 , . 0 5 , 0 . 05 , 0 . 1 , − .2) ;6410 TRANSITION to (−1). a f t e r ( complete ) ;11 ENDPHASE12 ENDSCRIPTA.3.4 Fast Walk1 #Fi l e : f a s twa lkonce . t2 #Desc r ip t i on : Fast Walk , c a l l s SIMBICON3 #Inputs : void4 SCRIPTS simbicononce . t ;56 BEGINSCRIPT fas twa lk ( void )7 PHASE 08 > s imbicononce . t ( . 2 , 0 . 0 , −2. , −.2 , 0 . 0 , 0 . 1 ,9 −.73 , . 7 , 1 . 83 , . 0 5 , 0 . 05 , 0 . 1 , − .2) ;10 TRANSITION to (−1). a f t e r ( complete ) ;11 ENDPHASE12 ENDSCRIPTA.3.5 Run1 #Fi l e : runonce . t2 #Desc r ip t i on : Run , c a l l s SIMBICON 2 phase3 #Inputs : void4 SCRIPTS simbicon2phaseonce . t ;56 SET TORQUELIMIT = 37078 BEGINSCRIPT run ( void )9 PHASE 010 > s imbicon2phaseonce . t ( . 2 , 0 . 0 , 0 . 0 , −.2 , −.2 ,11 0 . 14 , −1.08 , 2 . 18 , 0 . 05 , −.2 , − .27) ;12 TRANSITION to (−1). a f t e r ( complete ) ;13 ENDPHASE14 ENDSCRIPTA.3.6 Skip1 #Fi l e : sk ip . t2 #Desc r ip t i on : Skip3 #Inputs : void4 SET TORQUELIMIT = 17056 BEGINSCRIPT sk ip ( void )7 PHASE 08 ACTIONS9 POSE neck2head ( 0 . 0 ) , wa i s t ( 0 . 0 , 600 . , 6 0 . ) ,6510 uTorso2neck ( 0 . 0 ) , lTorso2uTorso ( 0 . 0 , 600 . , 6 0 . ) ;11 POSE lWris t ( 0 . 0 , 5 , 3 ) , rWrist ( 0 . 0 , 5 , 3 ) ;12 POSE rKnee ( 1 . 7 5 ) , lKnee ( . 1 9 ) ;13 POSE rAnkle (− .2) , lAnkle ( − . 2 ) ;14 POSE rShoulder ( . 3 , 1 00 , 3 0 ) , rElbow (0 , 1 00 , 3 0 ) ;15 POSE lShou lde r ( − . 3 ,100 ,30) , lElbow ( − . 4 , 100 ,30) ;16 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;17 COMFB2 0 . −0.4 j rAnkle18 VPD rThigh (−1.04 ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;19 ENDACTIONS20 TRANSITION to ( 1 ) . a f t e r ( time . 1 9 ) ;21 ENDPHASE22 PHASE 123 TRANSITION to ( 2 ) . a f t e r ( time . 1 2 ) ;24 ACTIONS25 POSE rKnee ( 2 . 1 8 ) , lKnee ( . 0 5 ) ;26 POSE lAnkle ( 1 . 0 ) ;27 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;28 COMFB2 0 . −.4 j rAnkle29 VPD rThigh (−2.25 ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;30 ENDACTIONS31 ENDPHASE32 PHASE 233 TRANSITION to ( 3 ) . a f t e r ( time 0 . 2 6 ) ;34 ACTIONS35 POSE rKnee ( 2 . 0 9 ) , lKnee ( . 0 5 ) ;36 POSE lAnkle ( − . 2 ) ;37 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;38 COMFB2 0 . −.04 j rAnkle39 VPD rThigh (−2.44 ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;40 ENDACTIONS41 ENDPHASE42 PHASE 343 TRANSITION to ( 4 ) . a f t e r ( contact rFoot ) ;44 ACTIONS45 POSE rKnee ( . 2 5 ) , lKnee ( . 1 0 ) ;46 POSE lAnkle ( − . 2 ) ;47 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;48 COMFB2 −.18 −.37 j rAnkle49 VPD rThigh ( .46 ,−300. ,−30) . j o i n t ( rHip ) . f l a g s ( s ) ;50 ENDACTIONS51 ENDPHASE52 PHASE 453 ACTIONS54 POSE lWris t ( 0 . 0 , 5 , 3 ) , rWrist ( 0 . 0 , 5 , 3 ) ;55 POSE lKnee ( 1 . 7 5 ) , rKnee ( . 1 9 ) ;56 POSE lAnkle (− .2) , rAnkle ( − . 2 ) ;6657 POSE lShou lde r ( . 3 , 1 00 , 3 0 ) , lElbow (0 , 1 00 , 3 0 ) ;58 POSE rShoulder ( − . 3 ,100 ,30) , rElbow ( − . 4 , 100 ,30) ;59 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;60 COMFB2 0 . −0.4 j lAnkle61 VPD lThigh (−1.04 ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;62 ENDACTIONS63 TRANSITION to ( 5 ) . a f t e r ( time . 1 9 ) ;64 ENDPHASE65 PHASE 566 TRANSITION to ( 6 ) . a f t e r ( time . 1 2 ) ;67 ACTIONS68 POSE lKnee ( 2 . 1 8 ) , rKnee ( . 0 5 ) ;69 POSE rAnkle ( 1 . 0 0 ) ;70 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;71 COMFB2 0 . −.4 j lAnkle72 VPD lThigh (−2.25 ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;73 ENDACTIONS74 ENDPHASE75 PHASE 676 TRANSITION to ( 7 ) . a f t e r ( time . 2 6 ) ;77 ACTIONS78 POSE lKnee ( 2 . 0 9 ) , rKnee ( . 0 5 ) ;79 POSE rAnkle ( − . 2 ) ;80 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;81 COMFB2 0 . −.04 j lAnkle82 VPD lThigh (−2.44 ,−300. ,−30). j o i n t ( lHip ) . f l a g s ( s ) ;83 ENDACTIONS84 ENDPHASE85 PHASE 786 ACTIONS87 POSE lKnee ( . 2 5 ) , rKnee ( . 1 0 ) ;88 POSE rAnkle ( − . 2 ) ;89 VPD uTorso ( 0 . 0 5 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;90 COMFB2 −.18 −.37 j lAnkle91 VPD lThigh ( .46 ,−300. ,−30) . j o i n t ( lHip ) . f l a g s ( s ) ;92 ENDACTIONS93 TRANSITION to (−1). a f t e r ( contact lFoot ) ;94 ENDPHASE95 ENDSCRIPTA.3.7 Walk to Stop1 #Fi l e : walk2stop . t2 #Desc r ip t i on : Connects walk and stand .3 #Inputs : SIMBICON cd , cv ga ins .4 BEGINSCRIPT stop ( cde , cve )5 PHASE 0676 TRANSITION to ( 1 ) . a f t e r ( time . 3 ) ;7 ACTIONS8 POSE neck2head ( 0 . 0 ) , wa i s t ( 0 . 0 , 600 . , 6 0 . ) ,9 uTorso2neck ( 0 . 0 ) , lTorso2uTorso ( 0 . 0 , 600 . , 6 0 . ) ;10 POSE lWris t ( 0 . 0 , 5 , 3 ) , rWrist ( 0 . 0 , 5 , 3 ) ;11 POSE rKnee ( . 7 ) , rAnkle ( −0 .5) ;12 POSE lKnee ( . 1 ) ;13 POSE lAnkle ( −0 .2) ;14 VPD uTorso ( 0 , 3 0 0 , 3 0 . ) . j o i n t ( lHip ) ;15 COMFB2 cde cve j rAnkle16 VPD rThigh (− .5 ,−300. ,−30). j o i n t ( rHip ) . f l a g s ( s ) ;17 ENDACTIONS18 ENDPHASE19 PHASE 120 TRANSITION to ( 2 ) . a f t e r ( time 1 ) ;21 ACTIONS22 POSE rAnkle ( 0 . 0 ) ;23 POSE rHip ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ;24 POSE lHip ( −0 . 5 , 1 000 . , 1 00 . ) ;25 POSE rKnee ( 0 . 0 ) ;26 POSE lKnee ( 1 . 3 ) ;27 POSE lAnkle ( −0 .5) ;28 VFFB uTorso (1000 . , 4 5 0 . ) . by ( rAnkle ) . over ( rFoot ) ;29 VPD uTorso ( 0 , 3 0 0 , 3 0 . ) . j o i n t ( rHip ) ;30 ENDACTIONS31 ENDPHASE32 PHASE 233 TRANSITION to ( 3 ) . a f t e r ( time 1 ) ;34 ACTIONS35 POSE neck2head ( 0 . 0 ) , wa i s t ( 0 . 0 , 600 . , 6 0 . ) ,36 uTorso2neck ( 0 . 0 ) , lTorso2uTorso ( 0 . 0 , 600 . , 6 0 . ) ;37 POSE rAnkle ( −0 . ) ;38 POSE rKnee ( 0 . 0 ) ;39 POSE rHip ( 0 . 0 ) ;40 POSE lAnkle ( −0 .9) ;41 VFFB uTorso (1000 . , 4 5 0 . ) . by ( rAnkle ) . over ( cop ) ;42 ENDACTIONS43 ENDPHASE44 PHASE 345 TRANSITION to (−1). a f t e r ( time 2 ) ;46 ACTIONS47 POSE rAnkle ( −0 .05) ;48 MATCH lAnkle . to ( rAnkle ) . time ( 1 ) ;49 MATCH lHip . to ( rHip ) . time ( 1 ) ;50 MATCH lKnee . to ( rKnee ) . time ( 1 ) ;51 VFFB uTorso (1000 . , 4 5 0 . ) . by ( rAnkle ) . over ( cop ) ;52 ENDACTIONS6853 ENDPHASE54 ENDSCRIPTA.4 Crawl ScriptsA.4.1 Crawl1 #Fi l e : crawl . t2 #Desc r ip t i on : High l e v e l crawl s c r i p t .3 #Inputs : number o f i t e r a t i o n s4 SCRIPTS stand to hak . t , c raw l base once . t ;56 BEGINSCRIPT crawl ( i t e r s )7 PHASE 08 > s tand to hak . t ( void ) ;9 TRANSITION to ( 1 ) . a f t e r ( complete ) ;10 ENDPHASE11 PHASE 112 > c raw l base once . t ( . 3 ) ;13 TRANSITION to (−1). a f t e r ( i t e r a t i o n s i t e r s ) ;14 ENDPHASE15 ENDSCRIPTA.4.2 Stand to Hands and Knees1 #Fi l e : s tand to hak . t2 #Desc r ip t i on : Trans i t i on from stand to Hands and Knees3 #Inputs : void4 BEGINSCRIPT STAND TO HAK( void )5 PHASE 0 # s t a r t to squat6 ACTIONS7 POSE lTorso2uTorso ( 0 . , 600 . , 6 0 . ) ,8 uTorso2neck ( 0 . ) , neck2head ( 0 . ) ;9 POSE waist ( 0 . 1 , 6 0 0 . , 6 0 . ) ;10 LIPOSE rAnkle ( −1 .4) . time ( 1 ) ;11 LIPOSE lAnkle ( −1 .4) . time ( 1 ) ;12 LIPOSE lKnee ( 1 . 6 ) . time ( 1 ) ;13 LIPOSE rKnee ( 1 . 6 ) . time ( 1 ) ;14 LIPOSE rHip ( −1 .4) . time ( 1 ) ;15 LIPOSE lHip ( −1 .4) . time ( 1 ) ;16 POSE rShoulder ( −1 . 7 , 50 . , 3 0 . ) , l Shou lde r ( −1 . 7 , 5 0 . , 3 0 . ) ;17 POSE rElbow ( −0 . , 5 0 . , 3 0 . ) , lElbow ( −0 . , 5 0 . , 3 0 . ) ;18 POSE rWrist ( − . 2 , 5 . , 3 . ) , lWr i s t ( − . 2 , 5 . , 3 . ) ;19 POSEFB rAnkle ( 2 . 2 , 2 . ) . on ( j o i n t lAnkle ) ,20 lAnkle ( 2 . 2 , 2 . ) . on ( j o i n t lAnkle ) ;21 ENDACTIONS6922 TRANSITION to ( 2 ) . a f t e r ( time 1 ) ;23 ENDPHASE24 PHASE 125 TRANSITION to ( 2 ) . a f t e r ( time 0 . 5 ) ;26 ACTIONS27 POSE rAnkle (−1.4) , lAnkle ( −1 .4) ;28 ENDACTIONS29 ENDPHASE30 # landing with hands31 PHASE 232 TRANSITION to ( 3 ) . a f t e r ( time 0 . 8 ) ;33 ACTIONS34 POSE rAnkle (−1.4) , lAnkle ( −1 .4) ;35 POSE lKnee ( 1 . 3 , 3 0 0 . , 3 0 . ) , rKnee ( 1 . 3 , 3 0 0 . , 3 0 . ) ;36 POSE rShoulder ( −1 . 4 , 1000 . , 100 . ) , lShou lde r ( −1 . 4 , 1 000 . , 1 00 . ) ;37 POSE rElbow (−1. , 1000 . , 1 0 0 . ) , lElbow ( −1 . , 1 000 . , 1 00 . ) ;38 POSE rWrist ( − . 8 , 5 . , 3 . ) , lWri s t ( − . 8 , 5 . , 3 . ) ;39 ENDACTIONS40 ENDPHASE41 PHASE 342 TRANSITION to (−1). a f t e r ( time 0 . 4 ) ;43 ACTIONS44 POSE lKnee ( 1 . 8 , 1 0 0 0 . , 1 0 0 . ) , rKnee ( 1 . 8 , 1 0 0 0 . , 1 0 0 . ) ;45 POSE rAnkle ( −1 . , 1000 . , 100 . ) , lAnkle ( −1 . , 1 000 . , 1 00 . ) ;46 POSE rElbow ( −1 . , 1000 . , 100 . ) , lElbow ( −1 . , 1 000 . , 1 00 . ) ;47 ENDACTIONS48 ENDPHASE49 ENDSCRIPTA.4.3 Crawl Base1 #Fi l e : c raw l base once . t2 #Desc r ip t i on : Perform a crawl cy c l e3 #Inputs : dt − Phase 0 ,2 durat ion4 BEGINSCRIPT crawl ( dt )5 PHASE 06 ACTIONS7 POSE neck2head ( −1 . 0 , 1000 . , 100 . ) , wa i s t (−2.0 , 1000 . , 1 0 0 . ) ,8 uTorso2neck ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) , lTorso2uTorso ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ;9 POSE rHip (−2.3 , 1000 . , 1 0 0 . ) , lHip (−1.7 , 1000 . , 100 . ) ;10 POSE rKnee ( 1 . 9 5 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 5 , 1 0 0 0 . , 1 0 0 . ) ;11 POSE rAnkle ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) , lAnkle ( − . 2 , 1 000 . , 1 00 . ) ;12 POSE rShoulder ( −1 . 1 , 1000 . , 100 . ) , lShou lde r ( −0 . 7 , 1 000 . , 1 00 . ) ;13 POSE rElbow ( −0 . 8 , 1000 . , 100 . ) , lElbow (−1.7 , 1 0 0 0 . , 1 0 0 . ) ;14 POSE rWrist ( −0 . 8 , 100 . , 10 . ) , lWr i s t ( −0 . 5 0 , 1 00 . , 1 0 . ) ;15 ENDACTIONS16 TRANSITION to ( 1 ) . a f t e r ( time dt ) ;7017 ENDPHASE18 PHASE 119 ACTIONS20 POSE rHip (−2.3 , 1000 . , 1 0 0 . ) , lHip (−1.4 , 1000 . , 100 . ) ;21 POSE rKnee ( 2 . 0 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) ;22 POSE rAnkle ( − . 7 , 1000 . , 100 . ) , lAnkle ( − . 5 , 1 000 . , 1 00 . ) ;23 POSE rShoulder ( −0 . 7 , 1000 . , 100 . ) , lShou lde r ( −1 . 6 , 1 000 . , 1 00 . ) ;24 POSE rElbow ( −0 . 9 , 1000 . , 100 . ) , lElbow (−0.6 , 1 0 0 0 . , 1 0 0 . ) ;25 POSE rWrist ( − . 9 , 1 00 . , 1 0 . ) , lWr i s t ( − . 6 , 1 0 0 . , 1 0 . ) ;26 ENDACTIONS27 TRANSITION to ( 2 ) . a f t e r ( contact lHand ) ;28 ENDPHASE29 PHASE 230 ACTIONS31 POSE rHip (−1.9 , 1000 . , 1 0 0 . ) , lHip (−2.3 , 1000 . , 100 . ) ;32 POSE rKnee ( 1 . 6 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 2 . 2 , 1 0 0 0 . , 1 0 0 . ) ;33 POSE rAnkle ( − . 7 , 1000 . , 100 . ) , lAnkle ( 0 . 0 , 1 0 0 0 . , 1 0 0 . ) ;34 POSE rShoulder ( −0 . 7 , 1000 . , 100 . ) , lShou lde r ( −1 . 05 , 1000 . , 1 00 . ) ;35 POSE rElbow ( −1 . 6 , 1000 . , 100 . ) , lElbow (−0.5 , 1 0 0 0 . , 1 0 0 . ) ;36 POSE rWrist ( −0 . 3 , 100 . , 10 . ) , lWr i s t ( −1 . 2 , 1 00 . , 1 0 . ) ;37 ENDACTIONS38 TRANSITION to ( 3 ) . a f t e r ( time dt ) ;39 ENDPHASE40 PHASE 341 ACTIONS42 POSE rHip (−1.5 , 1000 . , 1 0 0 . ) , lHip (−2.1 , 1000 . , 100 . ) ;43 POSE rKnee ( 1 . 1 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . 7 , 1 0 0 0 . , 1 0 0 . ) ;44 POSE rAnkle ( − . 7 , 1000 . , 100 . ) , lAnkle ( − . 2 , 1 000 . , 1 00 . ) ;45 POSE rShoulder ( −1 . 5 , 1000 . , 100 . ) , lShou lde r ( −0 . 7 , 1 000 . , 1 00 . ) ;46 POSE rElbow ( −0 . 7 , 1000 . , 100 . ) , lElbow (−0.9 , 1 0 0 0 . , 1 0 0 . ) ;47 POSE rWrist ( −0 . 8 , 100 . , 10 . ) , lWr i s t ( −1 . 1 , 1 00 . , 1 0 . ) ;48 ENDACTIONS49 TRANSITION to (−1). a f t e r ( contact rHand ) ;50 ENDPHASE51 ENDSCRIPTA.5 Handstand ScriptsA.5.1 Handstand1 #Fi l e : handstand . t2 #Desc r ip t i on : Perform a handstand3 #Inputs : dt − time spent in handstand4 SCRIPTS step . t ;56 BEGINSCRIPT handstand ( dt )717 PHASE 0 # s t a r t with a walk s tep8 > s tep . t ( void ) ;9 TRANSITION to ( 1 ) . a f t e r ( complete ) ;10 ENDPHASE11 PHASE 1 # s t a r t l e an ing forward12 TRANSITION to ( 2 ) . a f t e r ( time . 5 ) ;13 ACTIONS14 POSE rShoulder ( −1 . 7 , 150 . , 30 . ) , l Shou lde r ( −1 . 7 , 150 . , 30 . ) ,15 lKnee ( 0 . 0 5 ) , rKnee ( . 5 ) ,16 lHip ( . 3 , 2 0 0 . , 3 0 . ) , rHip ( −1 ,200 . , 30 . ) ,17 rAnkle ( 0 . ) , lAnkle ( . 4 ) , rElbow (− .5) , lElbow ( − . 5 ) ;18 ENDACTIONS19 ENDPHASE20 PHASE 2 # lean forward21 TRANSITION to ( 3 ) . a f t e r ( time . 2 ) ;22 ACTIONS23 POSE waist ( . 3 ) , lTorso2uTorso ( . 3 ) ;24 POSE rShoulder (−1.6) , lShou lde r (−1.6) ,25 rWrist (−1.5) , lWr i s t (−1.5) ,26 lKnee (0 . 05 , 500 , 30 ) , rKnee ( . 3 ) ,27 rHip ( −1 . 2 , 200 . , 30 . ) , lHip ( . 3 , 2 0 0 . , 3 0 . ) ,28 rAnkle ( . 2 ) , lAnkle ( . 4 ) ,29 rElbow (− .28) , lElbow ( − . 28) ;30 ENDACTIONS31 ENDPHASE32 PHASE 3 # contact hands to ground33 ACTIONS34 POSE rShoulder (−2.75) , lShou lde r ( −2 .75) ;35 POSE rWrist (−1.3) , lWr i s t (−1.3) ,36 rHip (−1.2) , lHip ( . 3 ) , rAnkle ( . 8 ) ;37 POSE rElbow (− .6) , lElbow ( − . 6 ) ;38 ENDACTIONS39 TRANSITION to ( 4 ) . a f t e r ( contact lHand ) ;40 ENDPHASE41 PHASE 4 # kick up42 ACTIONS43 POSE rShoulder ( −2 .85 , 1000 . , 100 . ) , lShou lde r ( −2 . 85 , 1000 . , 1 00 . ) ;44 POSE rElbow ( − . 7 , 1000 . , 100 . ) , lElbow ( − . 7 , 1 000 . , 1 00 . ) ;45 POSE rWrist (−1.25 , 300 . , 3 0 . ) , lWr i s t (−1.25 , 300 . , 3 0 . ) ;46 POSE rHip (− .9) , lHip ( − . 7 , 4 0 0 . , 2 0 0 . ) ;47 POSE rKnee ( . 7 , 1 0 0 0 . , 1 0 0 . ) , lKnee ( . 7 , 1 0 0 0 . , 1 0 0 . ) ;48 POSE rAnkle ( . 0 ) , lAnkle ( 0 . ) ;49 ENDACTIONS50 TRANSITION to ( 5 ) . a f t e r ( time . 3 ) ;51 ENDPHASE52 PHASE 5 # balance53 ACTIONS7254 POSE waist ( 0 . 0 , 2 0 00 , 1 0 0 . ) , lTorso2uTorso ( − . 0 , 1 000 . , 1 00 . ) ;55 POSE rHip ( − . 7 , 1000 . , 100 . ) , lHip ( − . 7 , 1 000 . , 1 00 . ) ;56 POSE rKnee ( 1 . , 1 0 0 0 . , 1 0 0 . ) , lKnee ( 1 . , 1 0 0 0 . , 1 0 0 . ) ;57 POSE rWrist (−1.2 , 300 . , 3 0 . ) , lWr i s t (−1.2 , 300 . , 3 0 . ) ;58 POSEFB rHip ( −2 . 0 , . 0 ) . on ( part rHand ) ;59 POSEFB lHip ( −2 . 0 , . 0 ) . on ( part rHand ) ;60 POSEFB rWrist ( 2 . 0 , 1 . 0 ) . on ( part rHand ) ;61 POSEFB lWris t ( 2 . 0 , 1 . 0 ) . on ( part rHand ) ;62 ENDACTIONS63 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;64 TRANSITION to (−1). a f t e r ( time dt ) ;65 ENDPHASE66 ENDSCRIPTA.5.2 Handstand to Supine1 #Fi l e : handstand2supine . t2 #Desc r ip t i on : Ro l l from handstand to supine3 #Inputs : void4 SCRIPTS stand2handstand . t ;56 BEGINSCRIPT supine ( void )7 PHASE 08 ACTIONS9 LIPOSE rShoulder ( −2 . ) . time ( 1 ) ;10 LIPOSE lShou lde r ( −2 . ) . time ( 1 ) ;11 LIPOSE rElbow ( −1 .57) . time ( 1 ) ;12 LIPOSE lElbow ( −1 .57) . time ( 1 ) ;13 LIPOSE rWrist ( −1 .57 , 300 , 30 . ) . time ( 1 ) ;14 LIPOSE lWris t ( −1 . 5 7 , 3 00 . , 3 0 . ) . time ( 1 ) ;15 POSE rHip (−1.57) , lHip ( −1 .57) ;16 LIPOSE neck2head ( 1 . ) . time ( 1 ) ;17 LIPOSE uTorso2neck ( 1 . ) . time ( 1 ) ;18 LIPOSE waist ( 1 . ) . time ( 1 ) ;19 LIPOSE lTorso2uTorso ( 1 . ) . time ( 1 ) ;20 ENDACTIONS21 TRANSITION to (−1). a f t e r ( ang lerange 0 3 ) ;22 TRANSITION to ( 1 ) . a f t e r ( time 1 . 2 ) ;23 ENDPHASE24 PHASE 125 ACTIONS26 POSE neck2head ( 0 . 0 ) , uTorso2neck ( 0 . 0 ) ,27 waist ( 0 . 0 , 6 0 0 . , 6 0 . ) , lTorso2uTorso ( 0 . 0 , 6 0 0 . , 6 0 . ) ;28 POSE rShoulder ( 0 . 0 ) , lShou lde r ( 0 . 0 ) ;29 POSE rElbow ( 0 . 0 ) , lElbow ( 0 . 0 ) ;30 POSE rWrist ( 0 . 0 ) , lWri s t ( 0 . 0 ) ;31 POSE rHip ( 0 . 0 ) , lHip ( 0 . 0 ) ;7332 POSE rKnee ( 0 . 0 ) , lKnee ( 0 . 0 ) ;33 POSE rAnkle ( 0 . 0 ) , lAnkle ( 0 . 0 ) ;34 ENDACTIONS35 TRANSITION to (−1). a f t e r ( ang lerange 0 3 ) ;36 TRANSITION to (−1). a f t e r ( time 1 ) ;37 ENDPHASE38 ENDSCRIPTA.5.3 Walk on Hands1 #Fi l e : handstandwalk . t2 #Desc r ip t i on : Walk on hands , SIMBICON based3 #Precond i t ion : Handstand4 #Inputs : void5 BEGINSCRIPT walk on hands ( void )6 PHASE 07 ACTIONS8 LIPOSE rHip ( 0 . ) . time ( 1 ) ;9 LIPOSE lHip ( 0 . ) . time ( 1 ) ;10 LIPOSE rKnee ( 0 . ) . time ( 1 ) ;11 LIPOSE lKnee ( 0 . ) . time ( 1 ) ;12 LIPOSE waist ( 0 . , 1 0 0 0 . , 6 0 . ) . time ( 1 . ) ;13 VFFB uTorso (1000 . , 5 0 . ) . by ( rWrist ) . over ( cop ) ;14 VFFB uTorso (1000 . , 5 0 . ) . by ( lWris t ) . over ( cop ) ;15 ENDACTIONS16 TRANSITION to (−1). a f t e r ( ang lerange −2 2 ) ;17 TRANSITION to ( 1 ) . a f t e r ( time 1 ) ;18 ENDPHASE19 PHASE 120 ACTIONS21 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lWris t ) . over ( cop ) ;22 LIPOSE rElbow ( −1 .7) . time ( 1 ) ;23 ENDACTIONS24 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;25 TRANSITION to ( 2 ) . a f t e r ( time 1 ) ;26 ENDPHASE27 PHASE 228 ACTIONS29 VFFB uTorso (2000 . , 2 5 0 . ) . by ( lWris t ) . over ( lHand ) ;30 LIPOSE rElbow ( − . 3 ) . time ( 1 ) ;31 LIPOSE rShoulder ( −2 .9) . time ( 1 ) ;32 LIPOSE rWrist (− .5 , 300 . , 3 0 . ) . time ( 1 ) ;33 LIPOSE lShou lde r ( −2 .5) . time ( 1 ) ;34 ENDACTIONS35 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;36 TRANSITION to ( 3 ) . a f t e r ( contact rHand ) ;37 ENDPHASE7438 PHASE 339 ACTIONS40 VFFB uTorso (1000 . , 1 0 0 0 . ) . by ( lWri s t ) . over ( cop ) ;41 VFFB uTorso (1000 . , 1 0 0 0 . ) . by ( rWrist ) . over ( cop ) ;42 ENDACTIONS43 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;44 TRANSITION to ( 4 ) . a f t e r ( time 1 ) ;45 ENDPHASE46 PHASE 447 ACTIONS48 VFFB uTorso (2000 . , 2 0 0 . ) . by ( rWrist ) . over ( rHand ) ;49 VFFB uTorso ( 300 . , 3 0 . ) . by ( lWris t ) . over ( rHand ) ;50 ENDACTIONS51 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;52 TRANSITION to ( 5 ) . a f t e r ( time 1 ) ;53 ENDPHASE54 PHASE 555 ACTIONS56 LIPOSE rShoulder ( −2 .7) . time ( 1 ) ;57 LIPOSE rWrist ( −1 . 3 , 3 00 . , 3 0 . ) . time ( 1 ) ;58 LIPOSE lElbow ( −1 .7) . time ( 1 ) ;59 VFFB uTorso (2000 . , 6 0 0 . ) . by ( rWrist ) . over ( rHand ) ;60 ENDACTIONS61 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;62 TRANSITION to ( 6 ) . a f t e r ( time 1 ) ;63 ENDPHASE64 PHASE 665 ACTIONS66 VFFB uTorso (2000 . , 6 0 0 . ) . by ( rWrist ) . over ( rHand ) ;67 MATCH lShou lde r . to ( rShoulder ) . time ( 1 ) ;68 MATCH lElbow . to ( rElbow ) . time ( 1 ) ;69 MATCH lWris t . to ( rWrist , 300 . , 3 0 . ) . time ( 1 ) ;70 ENDACTIONS71 TRANSITION to (−1). a f t e r ( ang lerange −2 2 . 8 ) ;72 TRANSITION to (−1). a f t e r ( time 1 ) ;73 ENDPHASE74 ENDSCRIPT75Appendix BController HierarchyHere, we briefly describe how the hierarchical system of controllers is repre-sented during execution.The basic system uses four structures representing the controller, phase,action, and transition. The controller class contains its filename, a list ofphases, and the index of the current phase1 c l a s s Con t r o l l e r ( )2 {3 s t r i n g name ;4 array phases ;5 i n t cur r phase ;6 } ;The phase class consists of the phase number, a list of actions to be takenon this phase, and a list of transitions to be checked.1 c l a s s Phase ( )2 {3 i n t num;4 array a c t i on s ;5 array t r a n s i t i o n ;6 } ;Each type of action is decended from the Action class, and must have aperformAction function, which determines the torques generated wheneverthe action is called.1 c l a s s Action ( )2 {3 v i r t u a l void performAction ( ) ;4 v i r t u a l void r e s e t ( ) ;5 } ;Finally, a transition object is decended from the Transition class, and76must have a check() function that evaluates whether the transitioning con-ditions are true or not, and a phase index to transition to.1 c l a s s Trans i t i on ( )2 {3 v i r t u a l void check ( ) ;4 i n t to ;5 } ;After the controllers are read in, and the basic structures set up, theyneed to be stored and handled by the system in an efficient manner. Thereare two primary data structures used, a map for storing all controllers thathave been read in, and a stack for storing the current hierarchy of controllers.The storage map uses the controller’s name as the key, and the controllerdata structure as the entry. When the system comes across a phase that callsanother controller, the new controller is located in the map, and pushed tothe top of the stack. After the controller exits, it is popped from the stack,and the previous controller resumes at the phase it left off at.When the controller stack is empty, the character goes into a ragdollmode, where no control torques are generated.77

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0167045/manifest

Comment

Related Items