1. iLabs 10 Years of Remote Labs Crosstalk - March 6, 2008 Jesús del Alamo – MIT, Professor Department of EECS John Belcher – MIT, Professor Department of Physics Judson Harward – MIT, Associate Director of CECI Kunle Kehinde - Obafemi Awolowo University, Nigeria Steven Lerman – MIT, Dean for Graduate Students Mark Schulz – University of Queensland, Australia

2. What is iLabs? Jesús del Alamo Massachusetts Institute of Technology

3. Motivation for iLabs   There is enormous educational value in hands-on laboratory experiences   But, conventional labs…   … are expensive and have complex logistics   … can’t easily be shared   iLabs: real laboratories accessed through the Internet from anywhere at any time

4. iLabs at MIT Microelectronics device characterization (EECS, deployed 1998) Shake Table (Civil Eng., deployed 2004) Dynamic signal analyzer (EECS, deployed 2004) Polymer Crystallization (Chem. E., deployed 2003) Heat exchanger (Chem. Eng., deployed 2001) ELVIS (EECS, deployed 2006) Spectrometer (Nuclear Eng., deployed 2008) Force on a Dipole (Physics, deployed 2008)

5. Microelectronics Device Characterization iLab

6. Microelectronics Device Characterization   Since 1998   Measurement of DC current-voltage characteristics of microelectronics devices (and small circuits)   Used in three different courses at MIT:   6.002 Circuits and Electronics   2 nd year mandatory “core” subject, EECS   6.012 Electronic Devices and Circuits   3 rd year “header” subject, EECS   6.720J/3.43J Integrated Microelectronic Devices   Graduate subject, EECS+DMSE

7. Typical Assignment: Microelectronic Device Characterization Project Four step process: 1.Using iLab GUI:  Measure DC I-V device characteristics  Graph results 2.Download data to student’s computer 3.Using MATLAB or EXCEL:  Extract device parameters  Construct model based on theory presented in class  Compare with measurements, discuss 4.Freely explore other modes of operation…

8. Findings  iLab experiences can significantly enhance learning  For iLab educational experiences to be effective:  system has to work well, specially under peak load conditions  system must allow free exploration and making mistakes  clear documentation and tutorials are essential  Several small assignments more effective than few large projects  Students find difficulty in handling real-world data  offline, post-measurement portion of assignment critical to learning experience

9. iLabs in 6.002 DC Time domain Frequency domain

10. iLab Capacity System capacity: > 2,000 users/week > 15,000 experiments/week exercise out on Fridayexercise due on Friday Oct. 13-20, 2000 (~100 students)

11. MIT ITESM Makerere UDSM OAU Parma NUS NTU CCU Taipei iLabs has been used by 19 universities on five continents. Chalmers Queensland Portland Cairo DLUT AUB iLabs Use Around the World CMU Pavia Mauritius Deusto

12. iLabs: the Opportunities  Order of magnitude more laboratories available to our students  Unique labs:  Unusual locations, expensive equipment, rare materials equipment, rare materials  Rich pedagogical experiences:  More lab time for students  GUI to lab integrating graphing, simulation, collaboration, tutoring  Worldwide communities of scholars created around labs sharing content http://www.cameco.com/common/images/u101/reactor2.jpg

13. iLabs: the Challenges  Developing an iLab from scratch is a lot of work!  Great attention needed to user scalability  Needs to be done by domain specialist  Managing a broadly shared iLab is also a lot of work!  Disincentive for owner to share lab  Key challenge: iLab Scalability

14. Goals of iLabs project at MIT  To demonstrate the pedagogical potential of iLabs in science & engineering education  To develop a scalable framework to:  Ease the development of new iLabs  Facilitate iLab management  Enable worldwide sharing of iLabs

15.  Original creator: Lane Brooks (then Junior in EECS), built working prototype in 6 months! 10 years ago…

17. The iLabs Architecture view from above … Jud Harward Massachusetts Institute of Technology

18. iLabs Experiment Typology 2 Waves of Development  Batched Experiments (2003-2005):  The entire specification of the experiment is determined before execution begins.  The user need not remain online while experiment executes.  Interactive Experiments (2004-2008):  The student client portrays virtual lab equipment (GUI).  The student can interact with experiment throughout its course.

19. Lab Server iLab Batched Architecture Service Broker Client Campus network Internet University Databases Special purpose system specific to an experiment Developed by domain specialist No user management here Verifies experiment before execution

20. Lab Server iLab Batched Architecture Service Broker Client Campus network Internet University Databases GUI to lab Embodies pedagogical experience Developed by domain specialist Contains generic modules that are recycled: i.e. graphing, collaboration

21. Lab Server iLab Batched Architecture Service Broker Client Campus network Internet University Databases Serves client to student’s computer Mediates between Client and Lab Server Performs generic functions: user management, data storage Single signon access to many labs Managed by and located at end user University

22. iLab Architecture: development responsibilities Service Broker Lab Server Client Campus network Internet University Databases Lab provider: develops Lab Server and Client can customize modules developed at MIT registers them with Service Brokers provides generic functionality developed by MIT, open source has well defined web services interfaces

23. iLab Architecture: management responsibilities Service Broker Lab Server Client Campus network Internet University Databases Lab provider: manages Lab Server sets lab policy manages groups, not individual users End-user institution: manages Service Broker manages users (registration, authentication) responsible for user data (storage, archiving) iLab Batched Architecture

24. Batched vs. Interactive Experiments  The student observes and controls interactive experiments in real time.  Execution takes longer than in the batched case, and users usually want to schedule their use.  The interactive architecture does not scale as well as the batched because experiments take longer to run.  Monitoring and controlling the experiment in real time requires more bandwidth.

25. Batched vs. Interactive Experiments, 2  An interactive experiment client will usually want to connect to the Lab Server directly whereas the batched client only connects through the Service Broker Service Broker Lab Client Lab Server X No Direct Communication Interactive Experiment Batched Experiment

26. Interactive Experiment Topology Service Broker Lab Client 1 Lab Server Clientside Campus Labside Campus User-side Scheduling Service Storage Service Service Broker Lab-side Scheduling Service Lab ManagerLab Client 2

27. Force on a Dipole Demo John Belcher Massachusetts Institute of Technology

28. Force on a Dipole Experiment

29. The UQ Story Mark Schulz University of Queensland, Australia

30. UQ & iLabs: The Beginning Keynote for Teaching and Learning Week at UQ ?? Experiments for High School Students ?? Slotted-Line experiment in EM Inverted Pendulum experiment Inverted Pendulum experiment in control engineering (Didn’t Happen)

31. Was the Inverted Pendulum Experiment a “Success”?

33. Will Other Faculty Follow? PV Array Dynamometer Embedded Systems FPGA Digital Design EE Will!

34. Will Non-EE Follow? Virtual Microscope Coastal Engineering Vet Science & Image Processing

35. What about the secondary schools? Before iLabs, this was the 1 st Year Physics experiment.. Now, it starts to look different. How does this look live (an engineering view, not the student view)?

36. What can the students do with the results?

37. UQ & iLabs: The Future iLabs motivated the mindset change from LabVIEW for Engineering to LabVIEW Everywhere @ UQ Fluid Mechanics (Chem Eng): Falling Particle Detection Prototype took 4 hours Question from staff: Where’s iLabs access? Recent Example:

38. A Perspective from OAU Kunle Kehinde Obafemi Awolowo University, Nigeria

39. OAU’s Involvement in iLabs OAU’s Involvement in iLabs  In a Nutshell, We Have  Used MIT iLabs  Developed new iLabs  Contributed a few ideas  Introduced iLabs to other Nigerian universities.  Used iLabs to enhance curriculum review

40. Lab Development Lab Development  OAU Op-Amp Lab  An operational amplifier iLab using NI ELVIS  Used NI switch array to allow student reconfigure circuits  Hardware controlled via NI DAQmx C++/C# functions

41. Lab Development Lab Development  OAU Op-Amp Lab (contd)  Uses a C# client, a non-standard Service Broker, and a modified Server  “non-standard SB” because we initially could not get the SB to relay pass-though API calls between client and Server. Now resolved.  Experiment engine written in C++ originally; now re- written in C#

42. Lab Development Lab Development  OAU LogicLab 4  Simple circuits with switching matrices allows students to carry out simple experiments on digital electronics  Has gone through quick evolution of the circuit under test (hence, now called “LogicLab 4”)  Interface and experiment engine written in C#

43. Lab Development Work in progress Lab Development Work in progress  ADL/FPGA Lab  Allows students to work with an Altera FPGA board, with FPGA exposing varying levels of complexity to different levels of students  VHDL command-line interface tested. Work ongoing on GUI/drag-and-drop interface  Robot Arm Control Lab  Allows students to manipulate a robot arm  Use this to expose various Control Engineering ideas

44. A Few Contributions From Us  Interfaces  We have always focused on interfaces  Example of interface ideas we have tested: the OpAmp Lab requires students to connect nodes before running experiment

45. A Few Contributions From Us-2  Interfaces (contd)  Another interface idea: we realized that schematics-based interfaces may not be a proper metaphor for a “remote LAB”. Real labs look more like our new Op Amp Lab interface:

46. A Few Contributions From Us-3  Server Installer  Setting up the Server was always problematic for us until we developed an installer that automatically generates and populates SQL tables and re- compiles source code files with login info.  Computer-Based Video Tutorials  We recently completed the first in a series of video tutorials on iLabs which we plan to make freely available to the entire iLabs community  Switching Matrix Server  We have developed a Web Services base scheme whereby multiple iLabs can share the same NI switch array card.

47. Introducing the MIT Reactor iLab Phil Long Massachusetts Institute of Technology

48. Nuclear Spectroscopy iLab

49. Nuclear Reactor iLab

50. Experiments in Neutron Science 1. Demonstration of a Thermal Neutron Beam 2. Demonstration of the DeBroglie wavelength through Time-of-Flight Experiment 3. Demonstration of Bragg diffraction 4. Demonstration of Neutron Scattering and Absorption

51. Target Audience and Educational Impact  Secondary schools  advanced physics and chemistry courses incorporate iLabs into their current curricula  Undergraduate and graduate courses  without access to neutron sources  Outreach to students in countries without nuclear technologies  in conjunction with MIT partnerships e.g., Singapore, Cambridge-UK, and Portugal

52. iLab in the Future Phil Long Massachusetts Institute of Technology

53. The Future of iLabs  An iLabs Consortium  International Partnerships  iLabs in K-12 education

54. Sustainability- Moving to an iLab Consortium Higher Ed Commerce/Industry Foundation Non-Profit & Govt. K-12 Building a micro-economy of shared experiments

55. Building a Consortium - Starting Focused  Initial partners need for a consortium include:  University of Queensland (Australasian),  Obefemi Awolowo University (Africa),  MIT (North America),  National Instruments  And….???  Rely on hub partners for expanding the range of iLabs  Rely on hub partners for training on iLabs technology, localizations and translations of documentation  MIT’s role -insure architecture remains current & continues to develop

56.  MCCD - Maricopa Community College District  ITESM - Tecnologico de Monterrey  URI - University of Rhode Island  Unicamp - Universidade del Estado do Saul Paolo  University of Cambridge  BITS- Pilani  CORE - China Open resources for Education  NTNU - National Technological Normal University  CCU - Cheng Chang University  Makerere University  University of Dar es Salaam Future Consortium Members? MCCD Maricopa Community College District UNICAMP UniversidadedeEstadial de Campinas University of Cambridge CCU Chung Chen University UQ University of Queensland ITESM Tecnologico de Monterrey NTNU National Technological Normal University CORE Beijing URI University of Rhode Island BITS-Pilani Africa iLabs High Schools Windward School llinois Math & Science Academy Queensland Academy of Math Science & Technology

57. Some Consortium Principles (for discussion)  Consortium should be open to all interested willing to participate  Consortium distributes responsibility for development, pedagogy, and policy.  Consortium should eventually lead evolution of iLab Shared Architecture through committee structure  Consortium should retain open source approach for reference implementations but allow compliant proprietary versions

58. iLabs in K-12  A new NSF funded project with Northwestern University  Possible uses of iLabs in OpenCourseWare for Secondary Education

59. Conclusions   iLabs has the potential to enhance science and engineering education   iLabs and their educational content can be broadly shared around the world   iLabs provide a path for the developed world to support education in the developing world   iLabs Architecture: scalable framework to support iLab dissemination around the world

60. “If You Can’t Come to the Lab… the Lab Will Come to You!” (Earth at 89 GHz; courtesy of J. Grahn, Chalmers U.)