In the world of engineering education, there are many excellent courses, but often the curriculum built around them has one serious drawback — a lack of good coherence between various topics. One might argue: how is that possible?
When forming a curriculum, prerequisites and a clear order of disciplines to study are indicated for each course. For example, to assemble and program a simple mobile robot, one needs to know a bit of mechanics to create its physical structure; the basics of electricity at the level of Ohm's and Kirchhoff's laws; the representation of digital and analog signals; operations with vectors and matrices to describe coordinate systems and the robot's movements in space; and the fundamentals of programming at the level of data representation, basic algorithms, and control structures, etc., to describe behavior.
Is all of this included in university courses? Of course it is. However, with Ohm's and Kirchhoff's laws, we get thermodynamics and field theory; in addition to operations with matrices and vectors, we have to deal with Jordan forms; in programming, we study polymorphism — topics that are not always necessary for solving a simple practical problem.
University education is extensive — students explore a wide range and often do not see the meaning or practical significance of the knowledge they acquire. We decided to shift the paradigm of university STEM education (Science, Technology, Engineering, Math) and create a program that relies on the coherence of knowledge while allowing for the accumulation of completeness in the future, meaning it implies an intensive mastery of subjects.
Exploring a new subject area can be likened to navigating an unfamiliar terrain. There are two options: either we have a very detailed map with a vast amount of details to study (which takes a lot of time) to understand where the main landmarks are and how they relate to each other; or we can use a basic plan highlighting only the main points and their relative positions — such a map is sufficient to start moving in the right direction while refining the details along the way.
We tested the intensive STEM learning approach at a winter school, which we conducted together with students from MIT with the support of
Material preparation
The first part of the school program consisted of a week of classes covering key topics, including algebra, electrical circuits, computer architecture, programming in Python, and an introduction to ROS (Robot Operating System).
The areas were chosen intentionally: complementing each other, they aimed to help students see the connection between seemingly different aspects — mathematics, electronics, and programming.
Of course, the main goal was not to deliver many lectures, but to give students the opportunity to apply their newly acquired knowledge in practice.
In the algebra section, students practiced matrix operations and solving systems of equations, which were useful when studying electrical circuits. By learning about the structure of transistors and the logic elements built on their basis, they could see their application in a processor's design, and after studying the basics of Python, write a program for a real robot.
Duckietown
One of the school's tasks was to minimize the use of simulators wherever possible. Therefore, a large set of electronic circuits was prepared for students to assemble on a breadboard from real components and test them in practice, using Duckietown as the project base.
Duckietown is an open project that includes small autonomous robots called Duckiebots and a network of roads they navigate. The Duckiebot is a wheeled platform equipped with a Raspberry Pi microcomputer and a camera.
Based on this, we prepared a set of possible tasks such as mapping roads, object detection, and stopping near them, along with several others. Students could also propose their own problems and not only write a program to solve them but also immediately run it on a real robot.
Teaching
During the lecture, instructors presented the material using pre-prepared presentations. Some sessions were recorded on video, allowing students to watch them at home. During lectures, students used materials on their computers, asked questions, worked on tasks together and independently, sometimes at the board. As a result of their work, a rating was calculated for each student separately across different subjects.
Let's take a closer look at the classes for each subject. The first subject was linear algebra. Students studied vectors and matrices, systems of linear equations, etc., over the course of one day. Practical tasks were structured interactively: proposed problems were solved individually while the instructor and other students provided comments and hints.
The second subject was electricity and basic circuits. Students learned the fundamentals of electrodynamics: voltage, current, resistance, Ohm's law, and Kirchhoff's laws. Practical tasks were partially done in a simulator or completed on the board, but more time was spent on building real circuits, such as logic circuits and oscillatory circuits, etc.
The next topic, Computer Architecture, is in a sense a bridge connecting physics and programming. Students studied fundamental concepts, the significance of which is more theoretical than practical. As practice, students designed arithmetic-logic circuits independently in a simulator and earned points for completed tasks.
The fourth day marked the first day of programming. Python 2 was chosen as the programming language since it is used in programming for ROS. The day's schedule was structured as follows: instructors presented the material and provided problem-solving examples, while students listened from their computers and repeated what the instructor wrote on the board or slide. Afterwards, the students tackled similar problems independently, and the solutions were assessed by the instructors.
The fifth day was dedicated to ROS: the students were introduced to robot programming. Throughout the day, students sat at their computers, running the code explained by the instructor. They were able to launch the basic units of ROS on their own and also got acquainted with the Duckietown project. By the end of this day, the students were ready to embark on the project phase of the school—solving practical tasks.
Description of the chosen projects
Students were invited to form teams of three and select a project topic. Ultimately, the following projects were accepted:
1. Color Calibration. The Duckiebot needs to calibrate its camera when lighting conditions change, which creates the task of automatic calibration. The challenge is that color ranges are very sensitive to brightness. Participants implemented a utility that would highlight the required colors (red, white, and yellow) in a frame and build ranges for each color in HSV format.
2. Duck Taxi. The idea behind this project is for the Duckiebot to stop beside a certain object, pick it up, and follow a specific route. A bright yellow duck was chosen as the object.
3. Road Graph Construction. There is a task to construct a graph of roads and intersections. The aim of this project is to create a road graph without providing a priori data about the environment for the Duckiebot, relying only on data from the camera.
4. Patrol Car. This project was conceived by the students themselves. They proposed teaching one Duckiebot, the 'patrol,' to chase another—the 'offender.' To achieve this, a target recognition mechanism using an ArUco marker was employed. Once recognition is complete, a signal is sent to the 'offender' to indicate the end of the task.
Color Calibration
The goal of the Color Calibration project was to adjust the range of detectable line marking colors for new lighting conditions. Without such adjustments, the recognition of stop lines, lane separators, and road boundaries became inaccurate. Participants proposed a solution based on preprocessing color templates: red, yellow, and white.
For each of these colors, a preliminary range of HSV or RGB values was defined. Using this range, all areas on the frame containing suitable colors are identified, and the largest one is selected. This area is taken as the color that needs to be remembered. Statistical formulas, such as calculating the mean and standard deviation, are then used to estimate the new color range.
This range is recorded in the configuration files of the Duckiebot camera and can be used later. The described approach was applied to all three colors, ultimately forming ranges for each of the marking colors.
Tests showed nearly perfect recognition of the line markings, except in cases where reflective tape was used as marking materials, which reflected lighting sources so much that from the camera's perspective, the markings appeared white regardless of their original color.
Duck Taxi
The Duck Taxi project involved creating an algorithm to locate a passenger duck in the city and then transport it to the required point. Participants divided this task into two parts: detection and graph traversal.
Students carried out the detection of the duck, assuming that a duck is any area in the frame recognizable as yellow with a red triangle (beak) on it. Once such an area is detected in the current frame, the robot should approach it and then stop for a few seconds, mimicking the passenger's boarding.
Then, with the predefined road graph of Duckietown and the bot's position, as well as receiving the destination as input, participants build a path from the starting point to the arrival point using Dijkstra's algorithm for finding paths in the graph. The output is presented as a set of commands — turns at each subsequent intersection.
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 the roads. For this, the Duckiebot must explore the city and analyze its route.
During the work on the project, the idea of creating a weighted graph, where the cost of an edge is determined by the distance (time to traverse) between intersections, was considered but then abandoned. Implementing this idea turned out to be too labor-intensive, and there wouldn't be enough time within the school framework.
When the Duckiebot reaches the next intersection, it selects a road exiting from the intersection that it has not yet traveled. Once all roads at all intersections have been covered, the bot retains a formed adjacency list of intersections, which is converted into an image using the Graphviz library.
The algorithm proposed by the participants is not suitable for arbitrary Duckietown, but worked well in a small city consisting of four intersections used in the school framework. The idea was to supplement each intersection with an ArUco marker containing the intersection's identifier to track the order of passage through the intersections.
The operational scheme of the algorithm developed by the participants is shown in the figure.
Patrol Car
The goal of this project is to search for, pursue, and detain the bot-offender in the city of Duckietown. The patrol bot must move along the outer ring of roads in the city in search of a pre-identified bot-offender. After detecting the offender, the patrol bot should follow the offender and force it to stop.
The work began with finding an idea for detecting the bot in the frame and recognizing the offender within it. The team proposed equipping each bot in the city with a unique marker on the back—just as real cars have license plate numbers. ArUco markers were chosen for this purpose, as they had been previously used in Duckietown, being easy to work with and allowing for the determination of the marker's orientation in space and the distance to it.
Next, it was necessary to make the patrol bot move strictly along the outer circle without stopping at intersections. By default, the Duckiebot moves in its lane and stops at stop lines. It then uses road signs to determine the configuration of the intersection and makes a decision about the direction to proceed through the intersection. Each of the described stages is handled by one of the states of the robot's finite state machine. To eliminate stops at the intersection, the team modified the state machine so that as the bot approached the stop line, it would immediately transition to the state of passing straight through the intersection.
The next step was to solve the problem of stopping the offending bot. The team assumed that the patrol bot could have SSH access to each of the bots in the city, meaning it had some information about the authorization data and which ID each bot had. Thus, after detecting an offender, the patrol bot would connect via SSH to the offending bot and turn off its system.
After confirming that the shutdown command had been executed, the patrol bot would also stop.
The algorithm for the patrol robot's operation can be represented in the following scheme:
Project Work
The work was organized in a format similar to Scrum: each 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 at hand and the methods of solving it. To help students adhere to their chosen plans, instructors from Russia and America were constantly present in the rooms where project work was taking place, answering questions. Communication predominantly occurred in English.
Results and Their Demonstration
The project work lasted one week, after which the students presented their results. Everyone prepared presentations in which they shared what they had learned at this school, the most important lessons they took away, and what they liked or disliked. After that, each team presented their project. All teams successfully completed their tasks.
The team responsible for color calibration completed their project faster than others, allowing them to prepare the documentation for their program. Meanwhile, the team working on the road graph was still trying to refine and correct their algorithms on the last day before the project demonstration.
Conclusion
After finishing school, we asked students to assess the activities they participated in and answer questions about how well the school met their expectations and what skills they acquired, etc. All students noted that they learned to work in teams, distribute tasks, and plan their time.
Students were also asked to evaluate the usefulness and complexity of the courses they took. Two groups of evaluations emerged: for some, the courses posed little difficulty, while others rated them as extremely challenging.
This implies that the school chose the right approach, remaining accessible to newcomers in various fields while also providing materials for review and reinforcement for experienced students. It is noteworthy that the programming course (Python) was marked as easy but useful by nearly everyone. The most challenging course, according to students, was 'Computer Architecture.'
When students were asked about the strengths and weaknesses of the school, many responded that they appreciated the chosen teaching style, where instructors provided prompt and individual assistance and answered any questions that arose.
Students also mentioned that they enjoyed working in a daily planning mode for their tasks and setting deadlines independently. As downsides, they pointed out a lack of knowledge provided that was necessary when working with the bot, including connection, understanding the basics, and principles of its operation.
Almost all students noted that the school exceeded their expectations, indicating the correct direction taken in organizing the school. Therefore, it is essential to maintain the general principles in organizing the next school while considering and addressing the shortcomings noted by students and instructors, possibly changing the list of courses or the timing of their delivery.
Authors of the article: the team downward API support (simultaneously with this in
P.S. Our corporate blog has a new name. It will now be dedicated to the educational projects of JetBrains.
Source: habr.com
