There are many excellent courses in the world of engineering education, but often the curriculum built on them has one serious drawback - the lack of good connectivity between different topics. One might object: how can this be?
When a training program is formed, prerequisites and a clear order in which disciplines must be studied are indicated for each course. For example, in order to assemble and program a primitive mobile robot, you need to know a little about the mechanics of creating its physical structure; the basics of electricity at the level of Ohm's / Kirchhoff's laws, the representation of digital and analog signals; operations with vectors and matrices in order to describe coordinate systems and movements of the robot in space; fundamentals of programming at the level of data presentation, the simplest algorithms and control transfer structures, etc. to describe behavior.
Is it all in university courses? Of course have. However, to the Ohm/Kirchhoff laws we get thermodynamics and field theory; in addition to operations with matrices and vectors, one has to deal with Jordan forms; in programming, to study polymorphism - topics that are not always needed to solve a simple practical problem.
University education is extensive - the student goes on a wide front and often does not see the meaning and practical significance of the knowledge he receives. We decided to turn the paradigm of university education STEM (from the words Science, Technology, Engineering, Math) and make a program that relies on the coherence of knowledge, allowing for an increase in completeness in the future, that is, it implies intensive mastering of subjects.
Learning a new subject area can be compared to learning a certain area. And here there are two options: either we have a very detailed map with a huge amount of detail that needs to be studied (and this takes a lot of time) in order to understand where the main landmarks are and how they relate to each other; or you can use a primitive plan, which shows only the main points and their relative position - such a map is enough to immediately start moving in the right direction, clarifying the details along the way.
We tested the intensive STEM learning approach at the winter school, which we held together with MIT students with the support of
Material preparation
The first part of the school program was a week of classes in the main areas, which included algebra, electrical circuits, computer architecture, programming in Python and familiarity with ROS (Robot Operating System).
The directions were not chosen by chance: complementing each other, they were supposed to help students see the connection between seemingly different, at first glance, things - mathematics, electronics and programming.
Of course, the main goal was not to give a lot of lectures, but to give students the opportunity to apply the newly acquired knowledge in practice.
In the algebra section, students could practice matrix operations and solve systems of equations, which came in handy when studying electrical circuits. Having learned about the device of the transistor and the logical elements built on its basis, students could see their application in the processor device, and after learning the basics of the Python language, write a program for a real robot using it.
Duckietown
One of the objectives of the school was to minimize the work with simulators where possible. Therefore, a large set of electronic circuits was prepared, which the students had to assemble on a breadboard from real components and test them in practice, and Duckietown was chosen as the basis for the projects.
Duckietown is an open-source project that includes small, autonomous robots called Duckiebots and the networks of roads they travel on. Duckiebot is a wheeled platform equipped with a Raspberry Pi microcomputer and one camera.
Based on it, we have prepared a set of possible tasks, such as building a road map, searching for objects and stopping near them, and a number of others. Also, students could propose their own problem and not only write a program to solve it, but also immediately run it on a real robot.
Teaching
During the lecture, the teachers told the material using pre-prepared presentations. Some of the classes were videotaped so students could watch them at home. During lectures, students used the materials on their computers, asked questions, solved problems jointly and independently, sometimes at the blackboard. Based on the results of the work, the rating of each student was calculated separately in different subjects.
Let's take a look at each subject in more detail. The first subject was linear algebra. Students studied vectors and matrices, systems of linear equations, etc. for one day. Practical tasks were built in an interactive mode: the proposed tasks were solved individually, and the teacher and other students gave comments and tips.
The second subject is electricity and simple circuits. Students learned the basics of electrodynamics: voltage, current, resistance, Ohm's law and Kirchhoff's laws. Practical tasks were partly done in the simulator or done on the board, but more time was devoted to building real circuits, such as logic circuits, oscillatory circuits, etc.
The next topic is Computer Architecture - in a sense, a bridge connecting physics and programming. Students studied the fundamental base, the meaning of which is more theoretical than practical. As a practice, students independently designed arithmetic-logic circuits in the simulator, and received points for completed tasks.
The fourth day is the first day of programming. Python 2 was chosen as the programming language, since it is it that is used in programming under ROS. This day was structured as follows: the teachers presented the material, gave examples of problem solving, while the students listened to them sitting at the computers and repeated what the teacher had written on the board or slide. Then the students solved similar problems on their own, subsequently the solutions were evaluated by the teachers.
The fifth day was devoted to ROS: the guys got acquainted with robot programming. Throughout the school day, students sat at computers, running the program code that the teacher talked about. They were able to get the main ROS units up and running on their own and also got to know the Duckietown project. At the end of this day, the students were ready to start the project part of the school - solving practical problems.
Description of selected projects
The students were asked to form teams of three and choose a topic for their project. As a result, the following projects were accepted:
1. Color calibration. Duckiebot needs to calibrate the camera when the lighting conditions change, so there is an automatic calibration task. The problem is that color ranges are very sensitive to light. The participants implemented a utility that would select the required colors (red, white and yellow) on the frame and build ranges for each of the colors in HSV format.
2. Duck Taxi. The idea of ββthis project is that Duckiebot can stop near some object, pick it up and follow some route. A bright yellow duck was chosen as the object.
3. Construction of the graph of roads. There is a problem of constructing a graph of roads and intersections. The goal of this project is to build a road graph without providing a priori environmental data for Duckiebot, relying only on camera data.
4. Patrol car. This project was invented by the students themselves. They offered to teach one Duckiebot, the "patrolman", to pursue another - the "violator". For this, the target recognition mechanism by the ArUco marker was used. As soon as the recognition is completed, a signal is sent to the "violator" about the completion of work.
color calibration
The goal of the Color Calibration project was to adjust the range of recognizable markup colors to the new lighting conditions. Without such adjustments, the recognition of stop lines, lane separators and road boundaries became incorrect. The participants proposed a solution based on the preprocessing of markup color templates: red, yellow and white.
Each of these colors has a predefined range of HSV or RGB values. Using this range, all areas containing suitable colors are found on the frame, and the largest is selected from them. This area is taken as the color to be remembered. Statistical formulas are then used, such as calculating the mean and standard deviation, to estimate the new color range.
This range is written to the Duckiebot camera configuration files and can be used later. The described approach was applied to all three colors, eventually forming ranges for each of the markup colors.
Tests showed near-perfect recognition of marking lines, except when the marking materials were glossy tape, which is so highly reflective of light sources that the markings appear white from the camera's angle, regardless of their original color.
Duck Taxi
The Duck Taxi project involved building a search algorithm for a passenger duck in the city, and then transporting it to the required point. The participants divided this task into two: detection and movement along the graph.
The students carried out duck detection under the assumption that a duck is any area on the frame that can be recognized as yellow, with a red triangle (beak) on it. As soon as such an area is detected on the next frame, the robot should approach it, and then stop for a few seconds, simulating the landing of a passenger.
Then, given the road graph of the entire duckietown and the bot's position in memory, and given the destination as input, the participants build a path from the origin to the destination using Dijkstra's algorithm to find paths in the graph. The output data is presented as a set of commands - turns at each of the following intersections.
Graph of roads
The goal of this project was to build a graph - a network of roads in Duckietown. The nodes of the resulting graph are intersections, and the arcs are roads. To do this, Duckiebot must explore the city and analyze its route.
During the work on the project, the idea of ββmaking a weighted graph was considered, but then discarded, in which the cost of an edge is determined by the distance (time to overcome) between intersections. The implementation of this idea turned out to be too laborious, and there would not have been enough time for it within the school.
When Duckiebot gets to the next intersection, he chooses the road leaving the intersection, which he has not yet moved. When all the roads at all intersections have been passed, the formed intersection adjacency list remains in the bot's memory, which is converted into an image using the Graphviz library.
The algorithm proposed by the participants is not suitable for an arbitrary Duckietown, but worked well for a small city consisting of four intersections used within the school. The idea was to add an ArUco marker containing the intersection ID to each intersection to keep track of the order in which the intersections were passed.
The scheme of work of the algorithm developed by the participants is shown in the figure.
Patrol car
The purpose of this project is to find, pursue and apprehend an intruder bot in the city of Duckietown. The patrol bot must move around the outer ring of the road in the city in search of a known intruder bot. After detecting the intruder, the patrol bot must follow the intruder and make him stop.
The work began with the search for the idea of ββdetecting a bot on a frame and recognizing an intruder in it. The team proposed equipping each bot in the city with a unique marker on the back, just like real cars have state registration numbers. For this, ArUco markers were chosen. They have been used before in duckietown, as they are easy to work with and allow you to determine the orientation of the marker in space and the distance to it.
Next, it was necessary to make sure that the patrol bot moved strictly along the outer circle without stopping at intersections. By default, Duckiebot moves in the lane and stops at the stop line. Then, with the help of road signs, it determines the configuration of the intersection and makes a choice about the direction of the intersection. One of the states of the robot's state machine is responsible for each of the described stages. In order to get rid of stops at the intersection, the team changed the state machine so that when approaching the stop line, the bot immediately went into the state of going straight through the intersection.
The next step was to solve the problem of stopping the intruder bot. The team made the assumption that the patrol bot can have SSH access to each of the bots in the city, that is, have some information about what authorization data and what id each bot has. Thus, after detecting the intruder, the patrol bot began to connect via SSH to the intruder bot and turn off its system.
After confirming that the shutdown command was completed, the patrol bot also stopped.
The algorithm of the patrol robot can be represented as the following scheme:
Project work
The work was organized in a format similar to Scrum: every morning, students planned tasks for the current day, and in the evening they reported on the work done.
On the first and final days, students prepared presentations describing the task and how to solve it. To help students follow the chosen plans, teachers from Russia and America were constantly in the rooms where work on projects took place, who answered questions. Communication was predominantly in English.
Results and their demonstration
The work on the projects lasted one week, after which the students presented their results. Everyone prepared presentations in which they told what they had learned at this school, what were the most important lessons learned, what they liked or disliked. After that, each team presented their project. All teams completed their tasks.
The color calibration team completed the project faster than the others, so they had time to prepare the documentation for their program. And the team involved in the road graph, even on the last day before the demonstration of the project, tried to refine and correct their algorithms.
Conclusion
After graduation, we asked the students to evaluate past activities and answer questions about how the school met their expectations, what skills they acquired, etc. All students noted that they learned to work in a team, distribute tasks and plan their time.
Students were also asked to rate the usefulness and complexity of the courses they took. And here two groups of assessments were formed: for some, the courses were not very difficult, while others rated them as the most difficult.
This means that the school has taken the right position, remaining accessible to beginners in a particular field, but also providing materials for repetition and consolidation for experienced students. It should be noted that the course on programming (Python) was noted by almost everyone as simple, but useful. The most difficult, according to the students, was the course "Computer Architecture".
When students were asked about the strengths and weaknesses of the school, many responded that they liked the chosen teaching style, in which teachers promptly and individually provided assistance and answered questions.
Students also noted that they liked working in the mode of daily planning of their tasks and setting deadlines on their own. As disadvantages, students noted the lack of provided knowledge that was required when working with the bot: when connecting, understanding the basics and principles of its work.
Almost all students noted that the school exceeded their expectations, and this indicates the right direction for organizing the school. Thus, the general provisions should be preserved when organizing the next school, taking into account and, if possible, eliminating the shortcomings that students and teachers noted, possibly changing the list of courses or the time of their teaching.
Article authors: team Π²
PS Our corporate blog has a new name. Now it will be dedicated to the educational projects of the JetBrains company.
Source: habr.com