Design State Exploration Applied to the Development of a Remote Lab for Projectile Launch Experiments

This paper describes the application of Design State Exploration techniques in the development of a remote lab for projectile motion experiments. The application was enabled by the existence of two independent teams: one composed of a series of internships that started first and another with two grantees that started a few months later. The paper presents evidence on how this approach provided gains in the development process conducted by the second team that benefited from design state exploration studies performed by the first team. This particular aspect is highlighted in relation to the work already presented in the 10 Remote Engineering and Virtual Instrumentation (REV) conference.


INTRODUCTION
Distance education has been in use for several years at the Polytechnic of Porto -School of Engineering (ISEP), but the application of remote laboratories in physics was being used exclusively in the electric and electronic fields. VISIR [1,2] and RemoteElectLab (developed at ISEP) [3] are examples of remote experimentation on electronics used in-house. The need for similar approaches supporting other experiments in physics has led us to develop a machine able to perform projectile launch experiments remotely. This type of apparatus can be used to address several topics on a typical physics curriculum, under different learning scenarios, since it allows different complexity levels in the characterization of the projectile motion. Figure 1 illustrates ancient didactical apparatuses used at ISEP, at the end of the 19 th century, for supporting experimental activities related with projectile motion. These apparatuses are now exhibited at ISEP's science & technology museum [4] and allow one to observe how physics is a foundation of any curricula offered at engineering schools. This paper discusses the development of a similar apparatus, for remote experiments, by two independent teams: one comprising a series of four internships that started in September 2010 and another team comprising two grantees that started the development in April 2011, i.e. circa 8 months after the 1 st team. This time gap led the project coordinators to think of the 1 st team as a good opportunity to apply Design State Exploration (DSE) techniques [5] in order to extract results leading to better de- sign options in the work carried out by the 2 nd team. The work done by the two teams is presented in detail in [6], whereas this paper emphasizes the beneficial aspects attained by the application of DSE techniques. It also presents a cross-comparative analysis of the costs and results pertaining to each team.
The rest of this paper is structured as follows: section II briefly reviews aspects related to the development of remote laboratories; section III focus on the specification phase of the developed apparatus; section IV describes the design phase; section V provides a comparative analysis of the work done by each team; and, finally, section VI concludes the paper.

II. DEVELOPMENT ASPECTS OF REMOTE LABS
Existing literature describes many examples about the development process of remote laboratories [7,8,9,10,11]. For instance, a quick survey through papers published in the International Journal of Online Engineering (iJOE) and in Proceedings of the International Conference on Remote Engineering and Virtual Instrumentation (REV) provides the reader with several examples of the development process followed in a number of existing remote labs. A quick analysis of such papers reveals that quite often the design options made by the development team are not described, thus preventing the interested reader in fully understanding why a particular design route was PAPER DESIGN STATE EXPLORATION APPLIED TO THE DEVELOPMENT OF A REMOTE LAB FOR PROJECTILE LAUNCH… followed. Such a gap is addressed in this paper, which emphasizes the design options made during the Physics LabFARM project, in particular in its 3 rd and last stage, where a remote lab for projectile launch experiments was developed. The two following sections describe details from the specification and design phases, respectively.

III. SPECIFICATION PHASE
The 3 rd stage specification phase started with a general meeting involving the two project coordinators, two grantees, several teachers from the physics department, and one student willing to do her final-year project/seminar in the scope of the Physics LabFARM project. The meeting started with a brief introduction to the first planned remote experiment covering the field of kinematics, namely projectile motion study. The introduction included some discussion on the experiment lab guide used in Physics lab classes (learning goals, list of material, theoretical background and execution steps -including items to be addressed in the experiment report) and a presentation of similar experiments, one being a virtual lab [12] and the other a commercially available didactical apparatus [13,14]. Discussions then followed on the pedagogical dimension, i.e. what would be the learning goals of such a remote lab for each teaching level (basic, medium, high). The rationale was to develop a remote experiment that could be used in basic science courses, preuniversity courses, and also in 1 st -year physics courses at university-level. This triggered discussions on user interface aspects, including on how to present results to the user and on how to link the remote lab with a Learning Management System (LMS), i.e. Moodle, to support student assessment [15]. At this point, the group decided to discuss possible design alternatives and additional characteristics of the remote lab, taking into account the present state-of-art [7,8,9,16,17], the resources available in the project, and the possibility to promote internships in the scope of the Physics LabFARM project. This discussion resulted in defining a global strategy for the the design phase (discussed in the next section), considering the following aspects: • The two initial stages of the Physics LabFARM project (related to two other remote labs for experiments with electrical and electronic circuits) implied that the two grantees would only start the development of this particular apparatus after an 8-months period. • This period was considered to be large enough to accommodate a series of internships, acting as design exploration experiences. • An experimental kit from [13] was to be ordered and studied to obtain further insight on the apparatus. • The apparatus to be built by the trainees (1 st team) would follow a low-cost methodology, i.e. reuse inhouse materials, use in-house facilities for building the mechanical parts and the printed circuits boards (PCBs), etc. • The trainees would have to address all parts, i.e. work in mechanical, software, and hardware-related parts, the goal being to advance, as much as possible, in the direction of having a readily available and fully working prototype. • The grantees (2 nd team) would follow a traditional hardware/software co-design methodology, with one grantee concentrating in the top-level software (serv-er side, scheduling mechanism, SCORMcompatibility, user interface, central database for storing all the experimental results, high-level interaction with the apparatus -through web services, etc.); and the other grantee concentrating in the mechanical and hardware parts, including the low-level software control and monitoring functions running in the remote apparatus.
The two teams thus followed different design routes, i.e. the first team applying DSE techniques able to feed results, ideas and suggestions to the second team, aiming a reliable, reproducible and portable apparatus.

IV. DESIGN PHASE
The 1 st internship started with an exploration task of the best platform for accommodating the high-level and lowlevel software layers. The choice went for the ARDUINO platform [18], given the reduced learning curve, the existence of a supportive community-of-users and open-source development tools, the price, the processing power, and the range of piggy-back boards (also called "shields") offering extending functionalities, e.g. the Ethernet shield. The end result of this initial internship allowed reaching an initial set of conclusions: • The ARDUINO platform proved to be robust and powerful enough to run the experiment server, including the web interface and the low-level software layer (control/observation of the photogates and the ultrasonic sensors); • The physical structure, made out of PVC tubes, proved to be unreliable, causing damping effects and vibrations, during the projectile motion. Additionally, it was not possible to guarantee that the ball was always released with an initial null speed. • The ultrasonic sensors were not appropriate to accurately measure the horizontal distance, possibly due to the shape and speed of the falling object (ball). Comparisons between the distances calculated from the signal returned by the ultrasonic sensors and the actual distances, given by photos taken with a highspeed video acquisition camera (see Figure 2), were important to clearly prove this conclusion. The 2 nd internship started after the 1 st one had ended, and so the two trainees were not able to physically meet in front of the apparatus. However, as they were from the same institution, they were able to discuss face-to-face, in Brazil, and establish a smooth transition in the project. The main priorities for the 2 nd internship derived from the conclusions obtained from the 1 st internship, i.e.: • Build a more rugged structure • Implement the angle variation mechanism • Develop a better distance measurement system At the end of the 2 nd intership, an entire new structure that eliminated unwanted vibrations was built. The tube PAPER DESIGN STATE EXPLORATION APPLIED TO THE DEVELOPMENT OF A REMOTE LAB FOR PROJECTILE LAUNCH… where the ball rolls off still presented a small damping effect and did not solve the initial null speed requirement. The angle variation mechanism was implemented using a stepper motor, a LEGO-alike system, and an accelerometer for providing feedback to the ARDUINO. The web page was improved in order to reflect the new functionalities (e.g. angle variation), and, finally, a measurement system based on a metal plate with two strain gages and one interrupter attached was also implemented and verified. This new measurement system was more accurate (! 10 mm) and reliable but it implied a complex and timeconsuming calibration process, using as references the images taken again with the high-speed video acquisition camera (see Figure 2). The interrupter attached to the metal plate -acting as the landing zone -provided information for calculating the time of flight and determining when to apply a digital filter to the signals obtained from the measuring bridge connected to the two strain gages.
Conclusions pointed out to a better implementation of the measurement system, using four special strain gages in a full-bridge configuration, in order to increase the accuracy and resolution. The ball selector and elevator were still missing.

C. 3 rd Internship (Jul. 2011 -Oct. 2011)
During the transition period between the 2 nd and the 3 rd internships, the two trainees had the opportunity to discuss, face-to-face, several technical details about the apparatus. Given the fact they all had similar backgrounds (all were enrolled in a Mechatronics degree), they easily established a dialogue and a course of action for the remaining work. The main goals were: • To develop the ball selector, elevator, and recovery parts • To guarantee an initial null speed of the ball • To develop PCBs for the electronics parts implementing the measurement bridge At the end of the 3 rd internship (bottom), all the goals were achieved and the result was a fully working prototype, ready for user testing. The solution implemented for the ball selector and elevator -an Archimedes screwallowed storing different balls, with the disadvantage that it was not possible to change their sequence. The ball outlet mechanism was able to guarantee a similar initial speed for all launching sequences, although not necessarily null.

D. Design route followed by the 2 nd team (Apr. 2011 -Jul. 2012)
The two grantees started to work in the development of the remote apparatus for projectile launch experiments in April 2011. By this time, a number of results provided by the 1 st (ended Feb. 2011) and 2 nd internships (in progress since Feb. 2011) pointed out to the urgent need to develop the ball selector and elevator parts (at the apparatus level) and the user interface.
As mentioned before, one grantee took care of the mechanical, electrical and electronic parts and also of the lower-level software layers, i.e. the apparatus control and observation blocks, and the other grantee dealt with the upper-level software layers, i.e. the user interface, the scheduling system, the SCORM compatibility requirement, the experiment database to store the data of every launch sequence (initial parameters, measured data, photo, video and sound records, and timestamps). The mechanical parts were designed in a 3D CAD tool [19] manufactured in an external company [20], and delivered in August 2011, by the time the 2 nd internship ended. The two parts obtained provided a good feedback on the mechanical design-manufacturing process. Focus was then shifted towards the design of the overall hardware control & observation architecture. It was decided to create an internal communication infrastructure, linking all electrical and electronic blocks associated with the four major mechanical parts. The idea was to implement a machine with a self-calibrating and self-monitoring system and allowing for a synchronized snapshot of the ball touchdown moment. The overall block diagram of the apparatus was thus defined as depicted in Figure 3.
The project continued its course with the following mechanical parts being designed, i.e. the launching ramp and the ball collector (with the associated horizontal distance measurement system). The damping and non-null initial speed negative effects, detected during the two initial internships, suggested an adaptation of the solution offered by [13]. The ramp and the electromagnet bought from CIDEPE were thus re-used for building the ball-launching part.
The implemented solution allowed for a variation from 53 mm to 348 mm, in the launching height, and from -15º to +15º degrees, with a 0.5º degrees resolution, in the ramp angle.
Next, the ball collector and the horizontal distance measurement system were designed, manufactured, and integrated with the remaining parts in the same case. The designed measurement system benefited from the difficulties and solutions already identified with the two systems PAPER DESIGN STATE EXPLORATION APPLIED TO THE DEVELOPMENT OF A REMOTE LAB FOR PROJECTILE LAUNCH… implemented during the 1 st and 2 nd internships. As a result, the adopted solution was to develop an infrared LED barrier with a reflecting mirror, to detect the point where the ball touched the landing surface. The developed system is touchless, requires no complex calibration procedures and offers a resolution of 2 mm. However, it took almost two months to develop, given the complex positioning of the 48 emitting and 96 receiving components.
Finally, the whole apparatus was mounted inside a single case, with an inferior compartment meant for storing the experiment server, as depicted in Figure 4. By this time the top-level software layer was also ready but not interconnected with the low-level software layer, as the grantee in charge of the software part left the project a few months before the its final conclusion. However, the grantee was also able to develop the higher-level user interface, integrated in a SCORM package also containing the scheduling mechanisms (see Figure 5). The video feedback mechanism and the photo mechanism (for capturing an image at the exact moment the ball touches the landing zone) were also missing.
The apparatus was initially presented to the scientific community working with remote labs, during the exhibition session of REV 2012, held in Bilbao, Spain from 4 th -6 th July [21]. The feedback obtained from the audience was encouraging and, at the end, it received the best demo award.   Table 1 resumes the main costs associated with the design routes followed by each development team. Starting with the personnel costs, the 3 trainees were supported by international mobility programs (i.e. PROPICIE, which is sponsored by the Brazilian Federal Government, and Erasmus, which is sponsored by the European Commission). The internships thus implied no costs to the Physics LabFARM project. Although the internships followed one another, and thus it was possible to establish a relatively smooth transition, the following facts presented some risks: • Candidates are selected by the sending parties; • The short duration of an internship (! 4 months), the time needed to "enter" into the problem and the requirement to produce a report at the end (which is an essential skill to be acquired during such an activity), limit the real contribution trainees can give under such scenarios; • There was a 4 th and last internship running from Oct. 2011 till Mar. 2012. The two trainees were able to meet face-to-face, at ISEP, but dialogue was neither intense nor fruitful He faced several problems after being asked to change the two strain gages -part of the measuring system -and to perform all necessary adaptations, i.e. to change the analog adaptation circuitry and to verify the digital filter and the distance calculation function implemented in the ARDUINO. At the end of this internship, no real contribution was made to the apparatus and, in fact, it was left in a non-operational state.
Nevertheless, the design made by the 1 st team also entailed some important and positive aspects, such as: • All trainees felt they were contributing to something bigger. Their effort was to be continued by other trainees and they also felt they were covering initial ground, leading to better solutions for the apparatus being developed by the two grantees. • Developing a remote accessible apparatus proved to be a challenging project. All trainees shared this feel-ing. They also enjoyed being able to later show their work, at their home institutions, as the apparatus they helped to develop was, in fact, remotely accessible.
Regarding the 2 nd team, the two project coordinators interviewed a number of candidates and were able to select the two offering the best expertise and commitment towards the project goals. Nevertheless, the grantee dealing with the software part left the project in March 2012 (1#years work), in a moment the apparatus was not fully ready for the integration tests. This implied re-allocating this task to the other grantee, which caused further delays in the whole project.
The mechanical component of the apparatus was a major cost. However, it is possible to reproduce it with considerable lower costs. The CNC-machine preparation time is one major cost, noticeably when single pieces are produced. In fact, for some sub-parts, the cost of producing 10 units, instead of 1, would be almost the same.
The commercial apparatus, bought from [20], provided some benefits for the design phase, in particular for solving the initial null speed problem. The two parts (ramp and electromagnet) could be replicated, but the project team decided to reuse those bought from CIDEPE, while maintaining the brand visible, for acknowledgement purposes.
Finally, the electrical and electronic parts presented the major cost category concerning the work done by the 1 st team. This includes the ARDUINO parts, the sensors (ultrasonic, strain gages, photogates, accelerometers, etc) and the actuators (stepper motor, power drivers). The 2 nd team had the PCBs manufactured by a commercial company, while the 1 st team used in-house manufacturing facilities for small prototype series.

VI. CONCLUSION
The remote apparatus developed by the 2 nd team is now ready for the validation phase, where a number of user trials will be undertaken. The remote apparatus developed by the trainees is in a non-operational condition and hence waits for repairing that, hopefully, will allow using it also in complementary user trials. Although this is an accidental result, both design routes stand as valuable to develop a remote lab. One may argue that the option to offer grants provides some liability towards the final result, but this is not a guarantee in itself, as people can leave the project before it actually finishes. This was the case with the grantee developing the top-level software layer that opted to not renew his grant for a further 6-months period, due to a job offer. In sum, the personnel costs, which emerge as the most important distinguishing factor between the two design routes, provide no real guarantee that a better apparatus will be built, as the final decision will always come from the client side, i.e. the teachers and students willing to use it. In fact, it would be interesting to compare the two apparatus, especially with students, while, in advance, transmitting them the idea that one was designed by grantees and the other was designed by their peers (i.e. other students, during internships). It maybe interesting to evaluate if such a detail causes some sort of Pygmalion effect in respect to the views and impressions students might reveal towards the apparatus produced by their peers. This sort of comparison remains undone, to the best of our knowledge.