Accessible Engineering (Mechanical Engineering)
Dr Hazim Namik in Mechanical Engineering in the Faculty of Engineering at the University of Auckland has been proactive in facilitating skills development in students of Stage Two Robotics course. You will find his experience useful if teaching robotics or other Engineering courses that require hands-on practice to develop or refine skills, for planning remote access to laboratories, and teaching large cohorts where supplementary resources are key.
Background
This case study was initiated in the Faculty of Engineering, specifically in the context of a stage two mechanical engineering paper. A significant, and examinable component of the paper centres around the students’ ability to control a VEX robot. Large class numbers, combined with scheduling requirements for the wider mechanical engineering programme (including post-graduate and higher degree students) meant that students had very limited access to the robot outside of class time. In response to student requests to make the VEX robot more accessible, the lecturer, alongside other students developed a system which would allow remote access to, and control of the robot, for the students.
Design: challenges and process
Developing the system required a collaborative effort. Final year students who are required to complete research projects to complete their degrees were tasked with conducting research projects which would inform system design. There was also support provided from IT staff, particularly with getting particular software programmes up and running. Once developed, the system was multi-faceted, incorporating existing technological software with the newly developed system and these included:
- Custom software for the remote access and control of the VEX robot: responding to lecturer observations and student requests, the system was developed to allow students the opportunity to test their theories and calculations with the robot. The system was also designed to prevent malicious use of the robot by students.
- MyPC: This is existing software utilised by the University which allows students to be able to book a PC in the information commons for a particular period of time.
- VNC (Virtual Network Computing): Allows for students to be able to control a computer, and in this case the VEX robot, remotely.
- VPN (Virtual Protected Network): Required by the University for any person wishing to access University computers while not operating on the University network. In the pilot round of the newly developed system this was not available to students
Implementation and evaluation
Fairness was a carefully considered aspect in the design of the system. In this case, fairness was based largely on the idea that all students would be allocated the same amount of bookable time in the robot lab. This is where MyPC was critical. Adapting this existing software to suit the needs of the course meant that students could be allocated a maximum time allotment per week. Students (in their groups) could then book time in the robot lab outside the usual university operating hours. Bookings were taken on a first-in, first-served basis. Further, the software was designed as a supplementary resource for students; it did not replace pre-existing lectures or content. This being the case, students would not be limited in their ability to access core elements of the course if they could not access the technology.
What worked well?
Technologically speaking, the software worked well. There were however issues which arose around connectivity. That is, the software relied on a wireless connection to work. If for any reason the students were disconnected, the software was inaccessible. Importantly, once disconnected, the robot needed to be manually reset which would require someone to be available in the robot lab. It was unlikely that there would be someone onsite out of usual operating hours, which meant that students could then be waiting for their time slot, only to find the robot was disconnected.
Though the MyPC system did support the goal of fairness to some extent, there are still additional equity issues which should be taken into consideration. In particular, the system was designed to support access, however, because VPN was not available for the students to install on their own devices, they then had to be physically on university grounds. This becomes an issue for students who could only book the later sessions provided between 5pm and 11pm, particularly regarding safety. It would also be an issue for students who rely on public transport, or who are required to be home for caregiving responsibilities. These are only a few of the many possible circumstances which may create barriers to the students’ ability to maximise the value of the opportunity created here. The issues outlined above were observed by the course convenor, and a plan has been put in place so that moving forward, students in this paper will be able to secure VPN access for their personal devices. While this will address a number of core concerns raised in the pilot, there will still need to be consideration given to students with limited access to personal devices.
What would be done differently?
Upon reflection, the lecturer noted that while students did express frustration, they were also understanding as he had made it clear that they were testing a new system and that sometimes it would work and other times there would be issues. The learnings taken from the pilot also led to the development of new instructions and a troubleshooting document to support student learning.
Finally, the system was originally developed for use in a stage II Mechanical Engineering course, however, there is potential for the system to be expanded and adapted to suit the needs of other courses within the Faculty of Engineering and beyond as the principles of the system may also have applications in other disciplines.