Reflections on Robot Making

It’s been a long time since I last wrote something. This is a reflection on making a robot when I took the elective course “Robot Innovation Design and Practice”.

In the final big experiment, our group made a robot that can automatically shut down a computer. This experiment was different from the previous ones, as we had to come up with our own topic and make it ourselves. This was a challenge for us, as we were used to receiving tasks and following instructions. As the group leader, I knew that we had to have a deep discussion and understanding of the task from the beginning, and anticipate all the possible difficulties we might encounter, while keeping an eye on the project’s progress. This was the only way we could succeed. Therefore, our group discussed for a long time, and many creative ideas were proposed during the discussion. In the end, we chose to make a robot that can automatically shut down a computer. I thought that making a robot that can do practical things would be very challenging, and it would require us to combine theory with practice. If we just made a model robot, it would be too idealistic, and we wouldn’t have the sense of accomplishment that comes with making something that can actually complete a task. Moreover, as students majoring in measurement and control, our strength lies in programming and detection, not in mechanical design. So, a robot that can detect its surroundings and shut down a computer through complex programming was the best choice for us.

After the previous experiment, our group members were able to cooperate well with each other. Since we were making something on our own, without any guidance or reference materials, we had to design and make all the components ourselves. Fortunately, we had gained experience from the previous experiment, and we were familiar with the functions of each component and how to assemble them. Our group members went through a process of discussion, making, and optimization. When our goal became unclear, I, as the group leader, actively discussed and communicated with the group members, encouraging them to break down the task and implement a strategy of tackling one problem at a time. As a result, during the entire making process, each group member was able to actively propose solutions to problems, making the process very smooth.

When making the robot, our group’s approach was to first make the individual components, and then assemble them on the intelligent robot car. During the component-making process, our group made a serious mistake - we didn’t consider how to combine the components. We started making each component separately, without a unified idea, and when we finally assembled them, many unexpected problems arose. For example, the screw feed mechanism, which had worked normally before, couldn’t work properly after assembly. Some components collided with each other, and couldn’t be assembled together… Fortunately, after realizing the problems, we quickly communicated and discussed, and then modified the design. Finally, our group’s overall upper component was assembled successfully.

After completing the component-making, we faced the most challenging stage - programming. Compared to the component design, our robot’s mechanism was not complex. Since shutting down a computer only involves a few actions, our mechanism only had one movement for shutting down, and most of the movements were for environmental detection. If the component-making process was smooth, the programming stage was like a nightmare. Because our robot had to actually shut down a computer, we couldn’t just make a model that performs a cool “show” like other groups. We had to consider very practical problems - how to find the power button, how to ensure the robot can reach the power button, how to correct deviations, how to ensure the robot’s hand can press the power button, how to move to the next computer, how to confirm that the computer is completely shut down… These problems were like dark clouds hovering over our group. During that time, we would arrive at the laboratory early in the morning to debug the car and modify the program parameters, and at night, I would search for others’ JC program codes online, learning from their programming ideas. Other group members would also think about solutions to problems before falling asleep. To work more efficiently, we redeployed our tasks. I, who was good at C programming, was responsible for the robot’s core programming, while other group members were responsible for writing a program for the upper component using flowcharts (which I would later convert to JC code and add to our overall program file). We worked efficiently, avoiding redundant work, and because I was responsible for the final code arrangement, we didn’t encounter problems with different program versions. The modular programming approach also allowed us to work on the upper component and the robot car simultaneously on two computers without conflicts. During programming, I used array structures to store various light-sensitive data, making our program readable and expandable, and avoiding problems that would arise from hardcoding using flowcharts.

Another thing worth mentioning is the debugging process after completing the programming. When we actually started debugging, I realized that applying the computer program to the real world required solving many more problems than I had anticipated. For example, making the robot car move in a straight line seemed simple, but in reality, it was not. The car’s wheels and the ground would produce a bias angle, and as the driving time increased, the initial small deviation would be amplified, resulting in serious errors. I thought about many solutions, such as introducing PID algorithms to rewrite the drive() function. We also had to test the light-tracking program in the dark, using our phones as light sources, and repeatedly adjusting the program. Every time the robot failed to track the light correctly, we had to fine-tune the program. After many rounds of debugging, our robot was finally able to track the light relatively accurately. However, the next day, we discovered that when we put the heavy feed mechanism on the robot car, the original program failed again - the system introduced new errors, and the original parameters couldn’t be used anymore. At that time, I felt very frustrated, but soon I thought of a solution - let one group member modify and improve the fixation and center of gravity of the robot mechanism and the car, aiming to make the car move normally again, and then I would adjust the program to make it adapt to the “fuzzy” control. The result was: my “fuzzy” control program failed, but the group member’s adjustments to the mechanism, and my later removal of some redundant parts, surprisingly made the robot very sensitive again. At that time, the final presentation was approaching, so I quickly completed the other parts of the program, and to prevent unexpected situations during the presentation, I added manual fine-tuning parts, and started the final overall debugging. After that, everything went smoothly.

When I heard the teacher say “your group passed”, I finally felt relieved, and the several days of hard work came to a successful end.

Finally, maybe our group’s robot was not very beautiful, maybe it couldn’t precisely find the shutdown button, maybe… but these were no longer important. The struggles of the past few days, the solutions to one problem after another, the trust and understanding among group members, all these would become valuable assets in my future life.