A "Rapid" Scaffolding Approach for Teaching Introductory Robotics By C. N. Thai
Since 2009, the author had been in charge of teaching introductory robotics to middle and junior high school students via the Duke University’s Talent Identification Program (http://www.tip.duke.edu/). The Duke TIP students could be considered as being the top 5% in the USA. The UGA TIP program offers 2 programs, “Academic Adventures” (AA) over a single Saturday and “Scholar Weekends” (SW) over the whole weekend. Also since 2012, the author offered a robotics summer camp (5 days) called Summer Academy at UGA (SAUGA) to any interested students aged 11 to 14 via the GA Center. More recently, starting in 2017, the GA Center added 2 new weekend programs (2-day and 1-day sessions) for any middle-schoolers interested in standard basic robotics and also in the newer trend of leveraging multimedia resources from mobile devices into robotics. Although the intellectual abilities between the two student groups were quite different, both groups had no or minimal background in robotics and computer programming, and for the instructor, relatively “short” time periods were available for subject matter instruction - only 6 to 7 hours per instructional day!
Thus the main challenge was how to teach younger students how to program the robot through its sensors and actuators, considering that their abstraction skills are not yet developed and taking into account the quite short time period (hours not days) allowed in these programs for this task. The author’s approach was to “pick and choose” only programming concepts directly related to do “robot control” and to use analogies to students’ everyday life experiences as much as possible, and as an application of Vygotsky’s Zone of Proximal Development (ZPD) theory. The IDE used was the RoboPlus TASK tool that came with all ROBOTIS systems. The TASK tool could be described as a menu-driven, mixed icon-text interface. Any two-wheeled robot would work with the approach described below.
The picture on the left displays the final result of the first robot programming session, and the individual steps to get to this final result are described below:
1. After showing the students how to start and use the TASK tool, the initial program had only Statement 3 in it. This was used to explain the concept of “PARAMETER ASSIGNMENT” and the peculiar “right to left” way to “read” the code. Although the robot could execute Statement 3 fine, the students of course realized that there was no feedback about what the robot was actually doing.
2. Next, Statement 4 was added to illustrate one way for the robot to provide feedback to the user via printing to an output window. This was also used to illustrate the “Sequential Control” concept, and to point out that Statements 3 and 4 could not switch their “logical” order without changing the robot’s output drastically.
3. Statement 5 was then added to show how to turn on the Geared Motor located on Port 1, which of course did not result in any visible action by the robot, unless Statements 7 and 8 were also used. Here the author used the analogy of using a microwave oven’s timer to heat food to explain the needed Statements 7 and 8. At this stage, students were also asked to verify which motor (left or right) was actually connected to Port 1, i.e. to verify that there was no “construction” mismatch between the instructor’s and students’ robots and that the Port 1 motor was turning in the “expected” direction. Occasionally, this “mismatch” would occur, then the impacted student would be told that his or her robot was built “special” and that “special” coding had to be performed by this student to achieve similar results to the rest of the class.
4. Statement 6 would then be added/inserted and it was time for the students to figure out on their own how to make the robot go forward, purely on a “trial and error” basis.
5. Once Step 4 was achieved correctly, the FUNCTION construct was introduced as a way to “save” the “good work” that had been done so far and not as a tool for modular programming as it was originally designed for (see Statements 11-17).
6. Next, the student was instructed to go back to the main program and figure out how to make the robot go backward, and once this task was done successfully this section of code was then saved in a new function, and so on for turning left and right. Essentially the main program was used as the “experimental playground” while functions were used as “archival” structures.
7. Of course, once the basic “move” functions were created, the students would be introduced to the concept of CALLING functions to create more complex behaviors of the robot by sequentially calling the basic move functions as needed. Next, the instructor would also have the option to put the 2 “timer-related” statements 7 and 8 into a TIMER function that could handle a variable timing parameter/period.
YouTube Video illustrating this process
The author used the same instructional approach for undergraduate engineering students who would find out that additional statements to turn off the motors would be needed after Statement 8 to actually stop the robot, even though the main program had terminated at Statement 9. This was done to impress upon the students that they were dealing with a distributed computing system when working with ROBOTIS DYNAMIXEL hardware, whereas each motor had their own embedded controller which would keep on executing the last command given to them by the main controller/program before it terminated.
For a general robotic problem-solving approach to be used with the younger students, the author opted to follow only the Reactive Control approach [1] by using a progression of creating a CONDITION-ACTION table which was then transformed into an SENSOR/ACTUATOR or INPUT/OUTPUT table which was then used by students to generate the actual code fragments to provide the wanted behaviors of the robot as it interacted with its surroundings. Essentially, students were asked to create a table of CONDITIONS that they would expect the robot to encounter and the corresponding ACTIONS/REACTIONS that the robot would have to perform. Next, the students created a matching SENSOR/ACTUATOR table whereas a SENSOR or sensors would be specified and used to monitor the CONDITION being considered. Similarly, ACTUATOR(S) needed to perform the matching ACTION would be identified and their behavior described in enough details so that the next step of actual coding could be performed. Of course, this approach would result in an IF-ELSE-IF structure inside an ENDLESS LOOP. The younger students would not be required to optimize any code after this step, however they were required to check if the robot behaved as intended and perform code changes as needed to fix the problems encountered.
The engineering students would also be started on a Reactive Control approach but would be required to optimize their code after the original IF-ELSE-IF structure. Next a Behavior Control approach [2] would be used for the same situation to show the differences in the actual codes obtained from each approach.
References
[1] M. J. Mataric, The Robotics Primer, Cambridge: MIT Press, 2007.
[2] R. C. Arkin, Behavior-based Robotics, Cambridge: MIT Press, 1998.
[3] C. N. Thai and M. Paulishen, “Using Robotis Bioloid systems for Instructional Robotics,” in Southeastcon 2011 Proceedings of IEEE, pp.300-306, 17-20 March 2011. DOI: 10.1109/SECON.2011.5752954.
[4] C. N. Thai and J. M. Mativo, “Development of a Senior Level Robotics Course for Engineering Students,” Computers in Education Journal, vol. 3, no. 1, pp. 6-20, 2012.
[5] C. N. Thai, Y. Kuo and P. Yen, “Cooperative Teaching in A Distance Education Environment,” Computers in Education Journal, vol. 4, no. 4, pp. 2-15, 2013.