Robotic Gardening - Project-based engineering education

Project-based learning gives students the opportunity to immediately put the course materials into action. Also, projects provide a tremendous opportunity for the students to learn from each other. The class "Building a Robot Garden" was taught by Prof. Daniela Rus and myself in Fall 2008 at MIT as a follow-up to "RSS: Robotics Science and Systems", an introductory class in robotics. Our goal was to  actively engage students into research by letting them design a distributed robotic system that autonomously waters and harvests tomato plants in CSAIL. We chose this task as it combines navigation, coordination, image recognition, manipulation and networking while imposing "real-world" challenges due to the interaction with real plants instead of objects modified for their interaction with robots. After the class was over and a common paper was published, I polled the class using surveymonkey.com [1] to learn more about the individual learning experience and the efficiency of the different learning modules.



Class Organization
After an introductory lecture and a brief poll questioning their individual preferences, the 12 students were divided into 6 groups addressing the following technical aspects of the problem:

- System architecture: how to connect individual software modules written in different languages? What code organization do we need?
- Navigation: how can the robot move from A to B on the garden platform hosting the tomato plants? How can we avoid collisions between robots?
- Image recognition: how can the robot recognize red and green tomatoes to inventory a plant and harvest tomatoes?
- Visual servoing: how do the joint positions of our four degree of freedom arm relate to the position of a tomatoe that we would like to grasp in an image captured from a camera on the arm?
- Inverse kinematics: how do we control the joint positions of our arm in order to reach arbitrary position in six degrees of freedom (x,y,z,pitch,yaw and roll)? Which positions can we not reach?
- Networking: how can we exchange information wirelessly between robots and embedded devices monitoring the humidity of each pot?

The class contained the following learning modules: ex-cathedra lectures to teach concepts and theory (1h a week), design reviews where the students presented and discussed their progress and next steps with teachers and peers (1h a week), as well as weekly meetings in the garden (1h a week) to teach individual concepts and address problems with hardware, software and algorithm design.

Student Background
Of the 9 male and 3 female students, 10 where in a BS program and 2 in a MS program. 7 of the students studied computer science, 2 were enrolled in both computer science and electrical engineering, 2 in Mechanical Engineering, and 1 student in Aero- and Astronautical Engineering. 9 of the students stated that they planned on attending graduate school, one female student indicated that the course has motivated her to do so, and two students did not change their plans to not attend graduate school after the class.


Technical Content

We asked the students on which topic they have been working, and how well they understand the other technical aspects.

Figure 1: Technical understanding of course modules

It turned out that almost all students perceived their involvement to go beyond their assigned task as they regularly answered "I was working on component X myself" for more than one component. More than half of the class had a solid understanding of the overall system architecture, navigation and visual servoing, but only 20% of the students claimed this for networking.
We believe the high confidence for some technical aspects to be due to the fact that students had significant previous experience with robotics, in particular in the course of the class "Robotics: Science and Systems" that covered system architecture, navigation and visual servoing. (4 students had both course work and practical experience, 4 students did only take courses, and 2 students had only practical experience due to competitions or internships. Only two students didn´t have any previous experience with their project component.) 60% of the students  claim to have had only a vague or basic understanding of inverse kinematics and manipulation. We believe this to be an artifact of the fact that one of the students implemented inverse kinematics using a robotics software suite that he had previous experience with, but which has not been introduced during the class.
We observe the lowest ratio of peer-to-peer learning for networking and coordination (around 75% of the class indicate  a "vague" understanding). Although networking and coordination were interacting with almost everybody else's modules, interaction between modules was abstracted by an inter-process communication framework and an understanding of the underlying aspects of ad-hoc networking were not necessary for most of the students. Also, while some of the modules required strong mutual understanding of their inner workings, such as visual servoing and inverse kinematics, the actual coordination algorithms were of little importance for students implementing the individual tasks. Finally, as the students needed to overcome various challenges in navigation, perception and manipulation, actual coordination could only be implemented during the very last days of the class, limiting their exposure to the rest of the class.


Efficieny of individual course modules
Learning from the team partner and peers working on other projects of the class, was valued high ("I learned a lot") by more than 50% of the students (Figure 2).

Figure 2: Perceived efficiency of learning modules.

Due to the different backgrounds of students, interaction with the team partner has also seen the highest variance in individual perception (from "I learned nothing" to "I learned a lot"). While all of the students agree that they learned a good deal ("learned something" and "learned a lot") from independently working on their project, only 60% of the students have this opinion on the lecture and 40% of the students reported that they learned "little" during this time. This is also the case for the design reviews - students presenting their progress and ideas in front of the class - received a "I learned a lot" from only two students.
We also asked students, whether they relied on literature not distributed during class in order to research their aspect of the course project, which 50% of the students did.


Summary and Discussion

It turns out that peer-to-pear learning, i.e. learning from other students that work on the same or related project, is perceived as providing a substantial learning experience, and the amount of knowledge acquired seems to be at the same level as that learned during individual study. From this perspective, project-based classes seem to be superior to classical models that rely exclusively on ex-cathedra lecturing and individual study. Designing a project-course that covers the same breadth as a lecture-based course is difficult, however, and an implementation challenging and time intensive for the students. Although lectures and design reviews were not perceived as the most efficient learning vehicles, we believe both of these offers were necessary for the success of the project. The lecture provides the theoretical basis for the students' own exploration and provides a common ground by defining the scope of the project. Also, the fact that the design reviews require deliverables on a weekly basis keeps the progress of individual teams within sync, and it is unclear wether - particularly bigger classes - could efficiently self-motivate themselves. One way to increase the value of the lecture could be to design the lecture in response to problems encountered during the project, in order to maximize the opportunity for the students to put theory into practice.

References

[1] Survey questions