1

Decentralized Control Systems Laboratory UsingHuman Centered Robotic Actuators

Binghan He1, Kunye Chen1, Rachel Schlossman1, Neal Ormsbee2, Mara Altman2,Nathan Young1, Matt Mangum2 and Luis Sentis3

Abstract—University laboratories deliver unique hands-on ex-perimentation for STEM students but often lack state-of-the-artequipment and provide limited access to their equipment. TheUniversity of Texas Cloud Laboratory provides remote access toa cutting-edge series elastic actuators for student experimentationregarding human-centered robotics, dynamical systems, and con-trols. Through a browser-based interface, students are providedwith various learning materials using the remote hardware-in-the-loop system for effective experiment-based education. Thispaper discusses the methods used to connect remote hardware tomobile browsers, the adaptation of textbook materials regardingsystem identification and feedback control, data processing togenerate clean and useful results for student interpretation, andinitial usage of the end-to-end system for individual and grouplearning.

I. INTRODUCTION

In control system and robotic laboratory courses, studentsoften grasp novel concepts and ideas from experimental dataand analysis of experiments. The strategies for conductingthese laboratories, however, have not changed in decades.First, advanced state-of-the-art devices can be prohibitivelyexpensive and require significant human supervision. Whilethere are some exceptions [1][2][3], there will always exista segment of the population for which even the relativelylow-priced systems are out of reach. In parallel, many top-performing devices and testbeds developed from competitiveresearch and industrial projects are rarely used for educationalpurposes but hold a strong potential for such purpose. It iscompelled to enhance control systems education by creatingmethods for accessing ubiquitously cutting-edge equipment.

In the past, several projects have been geared towards anonline laboratory for education. An Internet based controllaboratory is devised in [4], consisting of eighteen benchescontaining educational equipment for learning feedback con-trol systems, and it has been used in many courses acrossmultiple departments. A 3-DOF parallel robot has been usedas a Distance Laboratory System [5] showing that users cancollaborate on control algorithms and enhance their experi-ence. However, these online laboratories either focus only onthe remotization aspect with no tutoring content or lack step-by-step guidance for the students to learn new concepts.

1 Authors are with The Department of Mechanical Engineering, Univer-sity of Texas at Austin, Austin, TX 78712, USA. Send correspondence tobinghan@utexas.edu.

2 Authors are with The Faculty Technology Studio, University of Texas atAustin, Austin, TX 78712, USA.

3 Author is with The Department of Aerospace Engineering and Engineer-ing Mechanics, University of Texas at Austin, Austin, TX 78712, USA.

(c)

(a) (b)

(d)

Fig. 1. (a) A demonstration of usage of the CLAB system, in which a teachingassistant and a student perform remote experiments and discuss the results.(b) Another teaching assistant delivers a lecture using the CLAB remotelaboratory. (c) A snapshot of the CLAB interface accessed from an iPad,with live video streaming and live data provided below. (d) Multiple studentsremotely accessing the live experiments from their respective mobile devicesduring class time.

Open online courses, e.g. MOOCs [6], [7], provide fun-damental tutoring. In addition, researchers have built severalsystems to acquire specific knowledge skills. Sherlock [8] isused for guiding students to troubleshoot electrical equipment;ELM-ART [9] supports students to learn programming in Lisp;Andes [10] provides tutoring for learning physics; and Why2-Atlas [11] guides students in writing physics essays. Theseonline courses all provide tutoring content using questions,hints, and guidelines, which assist the learners to obtainspecific competencies. However, these online courses have notbeen connected to any experimental hardware.

There are also other great efforts to combine educational tu-toring with laboratory devices. Quanser [12] has been foundedin response to a need among engineering educators andresearchers for robust, high precision control experiments. Thecompany developed a servomotor system featuring a modularplatform for teaching and research. However, their platformis not remote as it needs to be in the same location as itsusers. iLabCentral [13] is an educational platform for remotehardware experimentation. The platform has been used to con-nect various laboratory devices for science education. Howevertheir devices provide learning of basic scientific principles

arX

iv:1

803.

1111

9v3

[cs

.RO

] 9

Apr

201

9

2

instead of teaching content for state-of-the-art engineeringplatforms.

These challenges and opportunities have prompted the au-thors to develop the UT Cloud Laboratory (CLAB) with focuson teaching concepts related to state-of-the-art engineeringequipment. Given the focus on distance learning, it has lever-aged distributed communication software and cloud frameworktechnologies to provide remote education with a state-of-the-art robotic actuator (Fig. 1). In Section II, the platformdesign, which includes a series elastic actuator (SEA) testbedand a cloud-based software architecture is introduced. It alsointroduces a Linear Temporal Logic (LTL) [14] method whichautomatically synthesize a finite state machine to managehuman-server-machine interaction with a procedural controlsystem experiment. In Section III, experiment content forsystem identification [15, pg.175-178] and feedback control[16, pg.404-410] are described. The feedback control exper-iment has been implemented in the CLAB system using theLTL synthesis method. In Section IV, the paper introduces amethod to present to the students clean system identificationplots from the experimental data by applying a piecewise FastFourier Transformation method. In Section V, the educationalbrowser interface for usage of the CLAB system is shownwhich includes pre-laboratory questions, usage scheduling,and remote laboratory experimentation content.

II. PLATFORM DESIGN

A. State-of-the-art Hardware

The CLAB system includes an Apptronik P-170 Orion SEAtestbed (Fig. 2). The experiment content is suited to teach thirdand/or fourth year engineering students principles of controlsystem theory. The P-170 was developed based on the UT-SEA [17], which has been adapted for the NASA Valkyrierobot [18], [19]. The SEA’s control board is connected to asmall PC with Ubuntu 14.04 OS which connects to a cloudserver for remotization.

B. Software Architecture

Several software platforms have been established for mas-sive open online courses[20], including POSA MOOC[21].Fig. 3 shows the diagram of the software system that drives theCLAB portal. The software system is supported by the GoogleFirebase database [22] and Amazon Web services (AWS) [23]in order to connect users to the P-170 SEA.

Google Firebase is a real-time database, which is a cloud-hosted and allows people to store and synchronize data be-tween users in real-time. It offers a variety of services commonto modern web applications. CLAB makes use of Firebase’sauthentication service and the database. In the software frame-work, Firebase is used for managing user accounts as well assaving data from the users. The data that is collected, includingstudents’ answers to pre-lab questions, students’ scheduledexperimentation times, and students’ input parameters for eachexperiment are stored on the application.

Data to be stored in the Google Firebase real-time databaseis managed in the application server, which is built uponAWS. The application server acts as an intermediary between

Fig. 2. P-170 Orion Series Elastic Actuator Testbed. The platform includes aDC brushless motor, an elastic spring, a ball screw drive transmission drive,two encoders, and a thermal sensor attached to the the surface of the motor.To control the motor and read sensor data, the testbed has an AXON controlboard which includes EtherCat communications, provides optimized real-timecontrol, low latency data transfer, and a floating point processor.

Firebase real-time database

Application Server(Node JS)

Control Design Engine(Python)

Websocket Video Relay(JSMpeg)

Simple Storage Service (S3)

Students

Testbeds

Store experiment result data

Data exchange(authentication required)

https:// Video relayed to students via websockets (ws://)

Data management

Store experiment video

Initiate experiments / live-stream data(ZeroMQ, tcp://)

Live video stream (FFMPEG)

Elastic Cloud Compute(EC2)

ZeroMQ (tcp://)

Fig. 3. Overview of the CLAB software system, which employs thecapabilities of Google Firebase and AWS

the web portal and other resources. The server communicateswith the experimentation testbed to handle several activities,including reserving a block of experimentation time, initiatingan experiment, and streaming experimental data for students toview. The server constructs the structure of the interface, offersdifferent activity options to users, and changes the actuatoroperating modes. It also communicates with the control designengine. For instance, once a student chooses the first labexperiment, the server will transfer the mode value to alignwith the control design engine, and will allow the controldesign engine to evaluate the student’s answers.

The Control Design Engine is in the form of a finite statemachine synthesized by the LTL method to manage the action-reaction interactions between student, server, and testbed. Forexample, the range of acceptable values for an experimentationquestion may depend on values submitted earlier in the controldesign sequence. The control design engine contains the logicfor dynamically determining which student submissions are

3

acceptable. Additional details will be provided in subsequentsections.

To improve student experience when interacting with theCLAB system, real-time video streaming is provided duringthe lab section. The web socket video relay takes in a livevideo of the lab device and broadcasts the feedback to astudent in a browser-friendly format via the web portal. Thevideo relay is optimized to be low latency. The time between astudent pressing the ”Start Run” button and seeing the deviceexecution is only about two tenths of a second. JSMpeg andFFMpeg are used for the video recording feature. JSMpeg is avideo player written in JavaScript. FFMpeg is a cross-platformsolution to record, convert, and stream audio and video. Afterthe experiment, the experimental data and the video streamingwill be stored in Amazon’s simple cloud storage service, S3,for later review.

The SEA is run by a computer with a web camera pointedat the device itself. The computer receives and responds tomessages via ZeroMQ, a lightweight messaging framework,to perform actions and launch experiments. Live experimentaloutput data is broadcast in real-time back to the applicationserver using ZeroMQ’s publisher-subscriber model. The datais subsequently forwarded to the students browser for real-timeplotting.

C. Control Design Engine

1) Student-Server-Machine Interaction: In a controller de-sign experiment, the server asks the student to enter variablevalues through posing lab questions. The server will checkthese variables within the cloud computation segment of thecontrol design engine, and will record whether these variableshave been entered correctly. When all the variables havebeen correctly entered and the student enters the ”Start Run”command, the server tells the testbed’s local computer to startthe experiment, and receives the experiment results if theexperiment is successfully finished. The machine reports anerror message to the server if there is any problem in runningthe experiment. The student can reset the system back to thebeginning of the controller design activity at any time.

The Control Design Engine, which lives in the Amazonserver, manages all interactions between the student, cloudcomputation, and local machine on the testbed (Fig. 4). When-ever there is an action executed from the student or machine,the Control Design Engine identifies the correct respondingaction to guide the student to complete all questions and collectall necessary inputs to start the experiment.

2) Linear Temporal Logic: The Control Design Engine,which is called ”system” in this LTL synthesis, is a finite statemachine in which transitions are triggered from the student,cloud computation, and machine actions. The state indicatesthe suitable system response. LTL [14] is used to representthe system specifications for all interactions, and automaticallysynthesizes the finite state machine.

First, the atomic propositions (AP) of LTL are defined basedon the actions of the system, student, cloud computation, andmachine. Assume x is one variable from a series of questionsthat the student needs to complete before the experiment. s,

Student

Controller(System)

Machine

Environment

Environment

Student-to-System Actions

● select input types● plug in values● reset

Machine-to-System Actions

● show results● show errors

System-to-Student Actions

● ask for inputs● assign hints

System-to-Machine Actions

● trigger experiments● setup experiments

Fig. 4. An overview of the information communicated from one CLABcomponent to another, where the key components are the student at thehigh level, the cloud computation at the mid-level, the experiment device(machine) at the low level, and the Control Design Engine (system) servingas an intermediary.

h, c, and m stand for system, student, cloud computation,and local machine. The associated atomic propositions are asfollows:

1) System-to-Human actions: ϕs−hx indicates the system

asks a question to the student to calculate x. ϕs−hexp

indicates the system asks if the student wants to enterthe experiment. ϕs−h

reset indicates the system asks if thestudent wants to reset itself. All system-to-human actionAPs are included in set Sh.

2) Human-to-System actions: ϕhx indicates the student pro-

vides the value of x to the system; ϕhexp indicates the

student clicks the ”Start Run” button to run the experi-ment; ϕh

reset indicates the student clicks the reset buttonto restart from the beginning. All human-to-system actionAPs are included in set Eh.

3) System-to-Computation actions: ϕs−cx indicates the cloud

computation checks whether x has been correctly calcu-lated by the student. All system-to-computation actionAPs are included in set Sc.

4) Computation-to-System actions: ϕctrue and ϕc

false indi-cate the correctness of cloud computation checking resultfor the entered variable. All computation-to-system actionAPs are included in set Ec.

5) System-to-Machine actions: ϕs−mexp indicates that the sys-

tem triggers the experiment on the low level testbedmachine. All system-to-machine action APs are includedin set Sm.

6) Machine-to-System actions: ϕmresult indicates that the

experiment has been completed successfully and the ex-perimental results have been displayed and saved; ϕm

error

indicates the experiment has been interrupted and an errormessage has been collected. All machine-to-system actionAPs are included in set Em.

7) System-Self actions: ϕsh, ϕs

m, and ϕsc indicate which

external factor the system is currently communicatingwith. ϕs

x indicates the variable x has been calculatedcorrectly by the student and is saved for the setup ofthe experiment. ϕs

result indicates experiment results havebeen saved in the system.

For ease of later discussions, superscript e ∈ {h,m, c} isalso defined.

All APs are formulated into constraints by propositional

4

logic operators and temporal operators for automatic synthesis.The temporal operators, � stands for ’always’, ♦ stands for’eventually’, and © stands for ’next time step.’

All interactions are formulated under a structure of a two-player game in which one player is the system and the otherplayer is the group of all external factors (human, cloudcomputation, and local machine). The system specifications ofthe two-player game are expressed into GR(1) [24] formulas,which allows automatic synthesis of the finite state machine.The GR(1) formulas include safety assumptions, livenessassumptions, and initial assumptions for human, computationand machine; and safety requirements, liveness requirements,and initial requirements for the server. The assumptions ofactions from human, cloud computation, and machine aredefined as the follows.

1) Safety Assumption 1: At each time step, there is onlyone action ϕe

i ∈ Eh ∪ Ec ∪ Em executed by the student,computation, or machine,

� ϕei → ¬

∨j 6=i, ϕe

j∈Eh∪Ec∪Em

ϕej (1)

2) Safety Assumption 2: The student will not be able toenter the value of x in the next time step if a variable xhas not been requested by the server at the current timestep,

� ¬ϕs−hx →©¬ϕh

x (2)

3) Safety Assumption 3: The student will not be able to enterthe experiment in the next time step if the experiment hasnot been requested by the server at the current time step,

� ¬ϕs−hexp →©¬ϕh

exp (3)

4) Safety Assumption 4: The student will not be able to resetthe system in the next time step if a reset has not beenrequested by the server at the current time step,

� ¬ϕs−hreset →©¬ϕh

reset (4)

5) Safety Assumption 5: The machine will send experimentresults or an error message in the next time step if andonly if the server has triggered the experiment at thecurrent time step,

� ϕs−mexp ↔©(ϕm

result ∨ ϕmerror) (5)

6) Safety Assumption 6: The cloud computation will send a‘correct’ message or ‘incorrect’ message in the next timestep if and only if the server has asked the computationto check the value of x at the current time step,

� ϕs−cx →©(ϕc

true ∨ ϕcfalse) (6)

7) Liveness Assumption 1: Any action, ϕei ∈

Eh ∪ Ec ∪ Em, from the student, computation, andmachine is available in the future at every time step,

�♦ ϕei (7)

The system requirements from the server are defined asfollows, noting that there is no liveness requirement in thesespecifications:

1) Safety Requirement 1: x1 is a prerequisite value of valuex2. The server will ask the student to enter the value ofx2 if and only if in the student mode there is no correctvalue of x2 saved in the server and a correct value of x1saved,

� (¬ϕsx2∧ ϕs

x1∧ ϕs

h)↔ ϕs−hx2

(8)

2) Safety Requirement 2: y is a prerequisite value of theexperiment. The server will ask the student to enter theexperiment if and only if in the student mode there is acorrect value of y saved in the server,

� (ϕsy ∧ ϕs

h)↔ ϕs−hexp (9)

3) Safety Requirement 3: The server will ask the student toreset if and only if the server is in the student mode,

� ϕsh ↔ ϕs−h

reset (10)

4) Safety Requirement 4: The server will ask the computa-tion to check the value of a variable x if and only if thestudent has inputted the value of x at the same time step,

� ϕhx ↔ ϕs−c

x (11)

5) Safety Requirement 5: The server will trigger the exper-iment if and only if the student has clicked the ‘start’button to start the experiment,

� ϕhexp ↔ ϕs−m

exp (12)

6) Safety Requirement 6: The system is in the mode ofmachine if and only if the system formulates a machinerequest at the current time step. The system is in the modeof computation if and only if the system formulates acomputation request at the current time step. The systemis in the mode of human if and only if the system is notin the mode of machine or computation.

� ϕsm ↔

∨ϕs−m

i ∈Sm

ϕs−mi , � ϕs

c ↔∨

ϕs−ci ∈Sc

ϕs−ci ,

� (¬ϕsm ∧ ¬ϕs

c)↔ ϕsh

(13)7) Safety Requirement 7: The system will hold a value of

x in the next time step if and only if all the followconditions hold:

i. An x is held by the system at the current time stepor an x will be entered by the student in the nexttime step.

ii. No x under the checking of cloud computation at thecurrent time step or no ‘false’ message will be sentfrom cloud computation in the next time step.

iii. No ‘error’ message will be sent from the machine inthe next time step.

5

iv. No reset command will be entered from the studentin the next time step.

� (ϕsx ∨©ϕh

x) ∧ (¬ϕs−cx ∨ ¬© ϕc

false)

∧ ¬© ϕmerror ∧ ¬© ϕh

reset ↔©ϕsx

(14)

8) Safety Requirement 8: The system will hold an experi-ment result in the next time step if and only if all thefollowing conditions hold:

i. An experiment result is held by the system at thecurrent time step or an experiment result will be sentfrom the machine in the next time step.

ii. No reset command will be entered by the student inthe next time step.

� (ϕsresult ∨©ϕm

result) ∧ ¬© ϕhreset ↔©ϕs

result (15)

Finally, after defining all these assumptions and systemrequirements, GR(1) is used to solve a finite state machinewhich satisfies all constraints. For the CLAB system, TuLip[25], which is a Python LTL synthesis package, was used toformulate and solve all the constraints discussed. The resultingfinite state machine was implemented as the Control DesignEngine in the server.

Notice that initial assumptions and requirements have notbeen specified. However, in order to ensure the system startsproperly, reset commands are automatically executed at thebeginning of the lab questions.

III. EXAMPLE EXPERIMENTS

In this section, two example experiments for teaching thirdand/or fourth year engineering students control systems theoryhas been provided. The first experiment, system identification,is a preliminary task before all other experiments on thetestbed. The lab questions designed for the second experiment,feedback control, provide the students step-by-step guidanceto design a lead controller. The automatic synthesis of thefinite state machine under the constraints (1) - (11) will beapplied to ease the implementation of the feedback controlexperiment on CLAB. The sequence of the lab questions areprogrammed under the form of Safety Requirement 1 in theprevious section.

A. System Identification

Before students design control systems for the actuator, theyneed to understand the system model and its mathematicalrepresentation. When the actuator arm has been locked, it ismodeled as a second order linear system (Fig. 6) [15, pg.75]with a transfer function:

P (s) =βks

mks2 + beffs+ ks, (16)

where mk is the spring-motor lumped mass, beff is theeffective damping ratio of the spring, ks is the spring constant,and β is a product of the motor efficiency and gear ratio ofthe drivetrain.

Φpm

Φd ΔΦ α

ωgc-max ωgc-minωgc

k, p, zΦmax Experiment

Fig. 5. Flow chart of the feedback control experiment. The original phasemargin φpm and the original gain-crossover frequency ωgc−min (both blue)are measured from the original Bode diagrams from the system identificationexperiment. The desired phase margin (green) is given. The other intermediateparameters (red) are asked in a step-by step manner. These questions assistthe student in developing a transfer function for the lead controller such thatthe student can implement the lead controller to obtain a new Bode diagramto see the phase margin improvement.

In the system identification experiment [15, pg.175-178],electric current in the form of sine waves of varying frequen-cies are sent to the series elastic actuator. The resulting systemoutputs, spring forces, are measured. From this data, a Bodediagram can be developed, showing the magnitude and phasediagrams when considering output spring force as a result ofinput current of varying frequencies. The Bode diagrams allowthe student to measure the associated phase margin as wellas to recognize the effects of non-ideal conditions within anengineering system.

B. Feedback Control

Without a controller, this SEA will be unstable in theclosed loop configuration due to the negative phase marginthat was measured in the system identification experiment. Thephase margin should be positive and relatively large so thatit can stably track a desired output trajectory and overcomedisturbances and time delay from the real world. The feedbackcontrol experiment introduces a lead controller, which is a typeof feedback controller used to improve the phase margin andsystem stability. A series of six questions based on a controlsystem textbook [16, pg.404-410] guides the student step-by-step to design the lead controller (Fig. 5).

Before the feedback control design experiment, the Bodediagram from the system identification experiment is amplifiedby a predefined steady gain kss. The original phase marginφpm, and the original gain-crossover frequency ωgc−min aremeasured by the students from the amplified Bode diagram.The first question asks about ∆φ, which is the differencebetween φd and φpm.

∆φ = φd − φpm (17)

The second question asks about φmax, which is chosenbased on the entered value of ∆φ. As a design rule of thumb[16, pg.405], φmax is 5 − 10◦ greater than ∆φ. The thirdquestion asks about α, which is the ratio between the poleand the zero of the transfer function of the lead controller.The parameter can be calculated from a function in terms ofφmax.

α =1 + sinφmax

1− sinφmax(18)

6

The CLAB system then requests that the student enterωgc−max, the maximum possible value of the new gain-crossover frequency. The value of ωgc−max is measured onthe original Bode diagrams by finding the new gain-crossoverfrequency after shifting the magnitude diagram 20 logα up-ward. The fifth question asks the student about the new gain-crossover frequency ωgc, which is a value between ωgc−min

and ωgc−max. The final question requests that the gain k, polep, and zero z values of the lead controller transfer functionbe entered into the interface. The prerequisite values have allbeen calculated in the previous questions.

k = α, p = ωgc

√α, z =

ωgc√α. (19)

The transfer function of the lead controller Gc(s) with thepredefined steady gain can be expressed as:

Gc(s) = kss · k ·s+ z

s+ p(20)

Similar to the system identification experiment, electricalcurrent in the form of sine waves of varying frequencies arethe inputs and the output spring forces, are measured. The leadcontroller with the transfer function of (17) is automaticallyimplemented into the experiment. The Bode diagrams arecreated from the input command. The current command isinversely calculated from the relationship between electricalcurrent and output spring force provided by the controllerequation. The student will be able to see that the phase marginon the bode diagram has been improved by the lead controllerand be able to compare this new phase margin with the desiredphase margin.

By applying constraints (1) - (11), a finite state automatawith 13 environment actions, 28 system actions, and 78 statesis automatically synthesized.

IV. RESULTS

The vedio of demonstration is available at https://www.youtube.com/watch?v=IkcvnRCCqoI. Before the userenters into an experiment, the CLAB home page provides anintroduction to the testbed, the CLAB interface, and the moti-vation for the experiments. The user interface is separated intotwo parts: a menu bar and the main content of each experiment.The menu bar on the left side of the CLAB interface showsthe session names for each experiment, which is composed ofthree subsection: pre-lab, scheduler, and experiment. The pre-lab tab leads the users to understand fundamental knowledgeused in the experiments with a sequence of questions. Afterusers complete the pre-lab, they can schedule the lab time byclicking ”Schedule Lab,” shown in the menu bar.

The lab activity will become unblocked in the menu baronly when the scheduled time begins, so that multiple users(with different login ID’s) will not be able to access theexperiment system to run the testbed at the same time. Itis important to note that multiple students can access theexperiment via multiple laptops and/or iPhones using the samelogin ID, so that use of CLAB in a classroom environmentis supported. When users start the lab activity, there may bea set of questions instructing them to input the parameters

(a) (b)

Fig. 6. (a) An example system identification prelab question. The purpose ofthis question is to ensure that the student can model dynamic SEA systemsand express the system’s input-output relationship in the Laplace domain. (b)An example feedback control prelab question. This question drives the studentto ensure his or her ability to interpret Bode diagram results and to understandthe meaning of the controller design parameter φmax.

(a) (b)

Fig. 7. An overview of the process a user follows to reserve an experimenttime. (a) The blue block indicates to the user that he or she can reserve theselected time, with unavailable times indicated in gray. (b) Once the userselects a time, the interface reserves a block suitable for experimentation(green) and hardware cool-down time (red).

used in running the experiment. The interface in which theexperiment is executed contains real-time video streaming,real-time input and output data, and simulation results forcomparison. After the experiment is complete, Bode diagramswill also be provided for comparison against the simulatedresults.

After the experiment, all the data and video will be auto-matically stored on the S3 Amazon Server for users to conve-niently review their experiments and data to make observationsand conclusion about the results.

A. Prelab

The CLAB interface allows for a prelab to be associatedwith each experiment. Instructors and teaching assistants cancreate and modify the questions using Firebase. Firebaseallows for the questions to be structured in three differentways: free response questions that take a specific answer,free response questions which can take a range of answers,and multiple choice questions. The purpose of the prelab isthat which is typical for in-person laboratories: to ensure theunderstanding of key concepts which are relevant to the currentexperiment so that the student can appreciate the applicabilityof theory to the real world.

7

Example questions for the system identification and feed-back control experiments are provided in Fig. 6. In Fig. 6(a),the locked output SEA model, which was discussed previously,is presented, and the student is asked to devise the transferfunction between input current and the force measured inthe spring. This question allows for the understanding ofmodel development, transfer functions, and the input-outputrelationship relevant for system identification. If the student isunsure of an answer, he or she can access a hint [26], [27],which provides further insight on the relevant topics and/or apointer to useful references for more information. Other topicscovered in the system identification prelab relate to experimentprocedure, system behavior as a function of different degreesof damping, system order, and phase margin measurement. Ifthe answer is submitted incorrectly, the student can continueto submit answers until it is correct.

Fig. 6(b) shows the interface for the feedback control prelab.The prelab focuses on ensuring that the student understands therelevance of lead controller design parameters and the abilityto formulate these parameters, as demonstrated in the questiondisplayed. Users can move forward as long as their responsesare in the range of accepted answers, and they are allowed togo back and review their answers after they have answeredcorrectly. The ability to schedule a lab is contingent uponfull completion of the associated prelab. Upon completion,the student is automatically directed to the scheduler.

B. Scheduler

The CLAB scheduler interface guides users to schedulethe experiments online. The scheduler helps multiple usersefficiently make use of the device. The scheduler interfacedesign does not change between experiments, and the feedbackcontrol experiment is provided as an example.

Fig. 7 shows the interface during and after scheduling anexperiment time. Fig. 7(a) shows that times occupied by othersor which have already passed are denoted as gray, and theseperiods are automatically blocked for scheduling. The usercan click on the unblocked spaces to select a time between9:00 AM to 4:30 PM. A legend box is provided to distinguishbetween blocked times, times for “actuator cool-down time”in order to not stress the machine, and time reserved bythe user. After clicking on the calendar, the system willautomatically reserve two hours for the experiment section.Theperiod selected will be highlighted in blue. If users are satisfiedwith the time period they can click on the “Schedule” buttonlocated in the bottom-right of the interface. After a userschedules the experiment time, that period will turn green toindicate that the time has been reserved, as shown in Fig.7(b). After the reservation is complete, the “Schedule” buttonchanges into a “Cancel” button to allow students to changetheir reserved times, if needed. Users are allowed to canceltheir appointment until the beginning of the lab section. Byclicking on the “Cancel” button, the previously-reserved timeis unreserved, and the user is allowed to choose another otherexperiment time period.

There are multiple rules to conveniently help users managetheir scheduling: Users cannot arrange another time period

(a) (b)

Fig. 8. (a) Video streaming of the P170 SEA on the CLAB interface.During the experiments, the student will notice the drive belt (connectingmotor to output) moving at different frequencies, and the motions of theother components. (b) Time-domain output from the system identificationexperiment. The student will notice that the input current’s amplitude remainsconstant but that the frequency increases over time. In the Output Force vs.Time plot, the varying spring force as a result of the varying frequenciesprovides valuable data for the generation of the associated Bode diagrams.

(a) (b)

Fig. 9. Within the CLAB interface the student has access to plotted real datafor the feedback control experiment, as well as simulation data for comparison.The student can read the positive phase margin gained from using feedbackcontrol, as well as identify deviations from expected behavior. Through side-by side comparison, one notes deviations from a predicted phase of zerosdegrees at low frequencies, and deviations from a relatively constant phase athigh frequencies in ideal conditions.

for the same experiment until they finish the one they alreadyscheduled; Users are allowed to use multiple devices to accessto the experiment website; Users are allowed to arrangemultiple lab experiments if they finish all the correspondingprelab sections; Users cannot cancel the scheduling during thelab experiment section. Once the scheduling time begins, usersare allowed to start their lab experiment and they can start orend at any time during the scheduling period.

C. Lab

The CLAB interface is configured for remote access tothe system identification and feedback controller design ex-periments. When the student conducts an experiment, he orshe can see the experiment being executed in real-time (Fig.8(a)). There is also audio available, as the sound of thesystem combined with visual information can give insight intounderstanding expected versus actual behaviors. For example,the student might be able to identify that the system needs tobe lubricated if the belt does not move significantly despitehigh-frequency sounds. As the experiment is executed, time-domain data is simultaneously plotted, showing input currentversus time and measured spring force versus time (Fig. 8(b)).

After the experiment concludes, the CLAB software auto-matically conducts a Fast-Fourier transform on the experimen-tal data to produce Bode diagrams. The Bode phase diagramassociated with the system identification experiment shows anegative phase margin, indicating instability. The student canthen understand the benefit of implementing control of the

8

system. The Bode diagrams of the open-loop system with thelead controller integrated into the control scheme, as seen inFig. 9, shows the positive phase margin achieved.

In both experiments, the student has access to predictedideal Bode diagrams which were produced in Matlab sim-ulations. These figures for comparison highlight one of thekey benefits of performing laboratory experiments on realhardware - the ability to identify the disparities betweenpredicted and real-world behaviors. For example, as can beseen in Fig. 9 for the feedback control experiment, simulationsuggests that in ideal conditions the phase should be equal tozero at low frequencies. In the real system, one recognizes thatthe phase is less than zero at low frequencies. Disturbances tothe system, such as nonlinear drivetrain friction, contributeto this observed decrease in stability. The simulation alsoshows that at high frequencies the ideal phase will reacha steady value as frequency increases, while the real datashows the phase continuing to decrease. Another source ofimperfection in the embedded system is time delay, whichmay contribute to this deviation from expected behaviors. Thetwo experiments allow for the development of key engineeringskills - to decipher between predicted and actual outcomes, andto recognize the potential sources for imperfections in physicalsystems.

V. CONCLUSIONS

In this paper, a method to learn the usage of stat-of-the-artrobotics equipment via remote browsers has been discussed.The concept by devising a cloud-based infrastructure, CLAB,which delivers the experiment content pertaining to the anal-ysis and control of a series elastic actuator developed forNASA to remote users has been demonstrated. The CLABinfrastructure allows users to answer prelab questions, obtainhints if needed, schedule lab time, solve lab questions, processreal-time remote experiments, and collect experimental dataand video through a web browser. With this foundation,system identification and feedback control experiments wereimplemented on the CLAB infrastructure. The authors believethis infrastructure could be effective at training students fortheir job careers since it uses state-of-the-art equipment.

ACKNOWLEDGEMENTS

This work was supported by the Longhorn Innovation Fundfor Technology (LIFT) grant and the Academic DevelopmentFunds from the University of Texas at Austin, and NASASpace Technology Research Fellowship 80NSSC17K0188.

REFERENCES

[1] F. Mondada, M. Bonani, X. Raemy, J. Pugh, C. Cianci, A. Klaptocz,S. Magnenat, J.-C. Zufferey, D. Floreano, and A. Martinoli, “The e-puck, a robot designed for education in engineering,” in Proceedingsof the 9th conference on autonomous robot systems and competitions,vol. 1, 2009, pp. 59–65.

[2] H. Zhang, J. Gonzalez-Gomez, Z. Me, S. Cheng, and J. Zhang, “De-velopment of a low-cost flexible modular robot gz-i,” in AdvancedIntelligent Mechatronics, 2008. AIM 2008. IEEE/ASME InternationalConference on Advanced Intelligent Mechatronics, 2008, pp. 223–228.

[3] R. Bischoff, U. Huggenberger, and E. Prassler, “Kuka youbot-a mobilemanipulator for research and education,” in IEEE International Confer-ence on Robitcs and Automation (ICRA), 2011, pp. 1–4.

[4] H. H. Hahn and M. W. Spong, “Remote laboratories for controleducation,” in Proceedings of the 39th IEEE Conference on Decisionsand Controls, vol. 1, 2000, pp. 895–900.

[5] I. Santana, M. Ferre, E. Izaguirre, R. Aracil, and L. Hernandez, “Remotelaboratories for education and research purposes in automatic controlsystems,” IEEE transactions on industrial informatics, vol. 9, no. 1, pp.547–556, 2013.

[6] J. Wulf, I. Blohm, J. M. Leimeister, and W. Brenner, “Massive openonline courses,” Business & Information Systems Engineering, vol. 6,no. 2, pp. 111–114, 2014.

[7] C. Severance, “Teaching the world: Daphne koller and coursera,” Com-puter, vol. 45, no. 8, pp. 8–9, 2012.

[8] S. Katz, A. Lesgold, E. Hughes, D. Peters, G. Eggan, M. Gordin, andL. Greenberg, “Sherlock 2: An intelligent tutoring system built on thelrdc framework,” Facilitating the development and use of interactivelearning environments, pp. 227–258, 1998.

[9] P. Brusilovsky, E. Schwarz, and G. Weber, “Elm-art: An intelligenttutoring system on world wide web,” in Proceedings of the ThirdInternational Conference on Intelligent Tutoring Systems, 1996, pp. 261–269.

[10] K. Vanlehn, C. Lynch, K. Schulze, J. A. Shapiro, R. Shelby, L. Taylor,D. Treacy, A. Weinstein, and M. Wintersgill, “The andes physics tutoringsystem: Lessons learned,” International Journal of Artificial Intelligencein Education, vol. 15, no. 3, pp. 147–204, 2005.

[11] K. VanLehn, P. W. Jordan, C. P. Rose, D. Bhembe, M. Bottner, A. Gay-dos, M. Makatchev, U. Pappuswamy, M. A. Ringenberg, A. Roqueet al., “The architecture of why2-atlas: A coach for qualitative physicsessay writing,” in Proceedings of the Sixth International Conference onIntelligent Tutoring Systems, vol. 2363, 2002, pp. 158–167.

[12] “Company Quanser,” accessed: 2017-12. [Online]. Available: http://www.quanser.com/

[13] “Project iLabCentral,” accessed: 2017-12. [Online]. Available: https://ilabcentral.sesp.northwestern.edu/

[14] C. Baier, J.-P. Katoen, and K. G. Larsen, Principles of model checking.MIT press, 2008.

[15] N. A. Paine, “High-performance series elastic actuation,” Ph.D. disser-tation, 2014, pg. 175-178.

[16] Z. Gajic and M. Lelic, Modern control systems engineering. Prentice-Hall, Inc., 1996.

[17] N. Paine, S. Oh, and L. Sentis, “Design and control considerations forhigh-performance series elastic actuators,” IEEE/ASME Transactions onMechatronics, vol. 19, no. 3, pp. 1080–1091, 2014.

[18] N. A. Radford, P. Strawser, K. Hambuchen, J. S. Mehling, W. K.Verdeyen, A. S. Donnan, J. Holley, J. Sanchez, V. Nguyen, L. Bridgwateret al., “Valkyrie: Nasa’s first bipedal humanoid robot,” Journal of FieldRobotics, vol. 32, no. 3, pp. 397–419, 2015.

[19] N. Paine, J. S. Mehling, J. Holley, N. A. Radford, G. Johnson, C.-L.Fok, and L. Sentis, “Actuator control for the nasa-jsc valkyrie humanoidrobot: A decoupled dynamics approach for torque control of serieselastic robots,” Journal of Field Robotics, vol. 32, no. 3, pp. 378–396,2015.

[20] L. Breslow, D. E. Pritchard, J. DeBoer, G. S. Stump, A. D. Ho, andD. T. Seaton, “Studying learning in the worldwide classroom: Researchinto edx’s first mooc,” Research & Practice in Assessment, vol. 8, 2013.

[21] D. C. Schmidt and Z. McCormick, “Producing and delivering a cours-era mooc on pattern-oriented software architecture for concurrent andnetworked software,” in Proceedings of the 2013 companion publicationfor conference on Systems, programming, & applications: software forhumanity, 2013, pp. 167–176.

[22] “Product Google Firebase,” accessed: 2017-12. [Online]. Available:https://firebase.google.com/

[23] “Product Amazon Web Service,” accessed: 2017-12. [Online]. Available:https://aws.amazon.com/

[24] N. Piterman, A. Pnueli, and Y. Saar, “Synthesis of reactive (1) designs,”in International Workshop on Verification, Model Checking, and AbstractInterpretation, 2006, pp. 364–380.

[25] T. Wongpiromsarn, U. Topcu, N. Ozay, H. Xu, and R. M. Murray, “Tulip:a software toolbox for receding horizon temporal logic planning,” inInternational Conference on Hybrid Systems, 2011, pp. 313–314.

[26] G. F. Franklin, J. D. Powell, A. Emami-Naeini, and J. D. Powell,Feedback control of dynamic systems. Addison-Wesley Reading, MA,1994, vol. 3.

[27] K. J. Keesman, System identification: an introduction. Springer Science& Business Media, 2011.