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 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 thorough discussion and understanding of the task from the beginning, anticipate all the possible difficulties we might encounter, and keep track of the project’s progress. That’s why our group discussion took 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 it would be very challenging to make a robot that can do something practical, 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 from making something that can actually complete a task.

Another reason we chose this topic is that we are students majoring in Measurement and Control, and our strength lies in programming and control, not in mechanical design. So, making 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 work together seamlessly. Since we didn’t have a guidebook to follow, we had to design and make all the components ourselves. Fortunately, we were familiar with the functions of each component and were confident in assembling them. Our group members went through a process of discussion, making, and optimization. When our goal became unclear, I, as the group leader, took the initiative to discuss and communicate with the members, encouraging them to break down the task and implement a strategy to tackle it one by one. As a result, each group member was able to actively propose solutions to problems, making the entire production 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, we encountered a serious problem - we didn’t consider how to combine the components. We started making each component separately, and when we tried to assemble them, we encountered many unexpected problems. For example, the screw feeder mechanism, which worked normally before, couldn’t work properly after assembly. Some components collided with each other, and we couldn’t assemble them together… Fortunately, we quickly communicated and discussed the problems, modified the design, and finally assembled the upper component of the robot.

After completing the component-making process, we faced the most challenging stage - programming. Compared to the mechanical design, our robot’s programming was not complex. Since shutting down a computer only involves a few actions, our robot’s movement was mainly used 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 it perform a cool “show” like other groups’ model robots. 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 the deviation if the robot goes off track, how to ensure the robot’s hand can press the power button, how to move to the next computer, how to confirm if the computer is really shut down… These practical problems loomed over our group like dark clouds. During that time, we were the first to arrive at the laboratory in the morning to debug the robot and adjust the program parameters, and at night, I would search for others’ JC program codes online and learn from their programming ideas. Other group members would also think about solutions to problems before falling asleep. To work more efficiently and save time, we redeployed our tasks. I, who was good at C programming, was responsible for the robot’s core programming, while other 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 by dividing tasks and avoiding repetitive work. Since 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 an array structure to store various light-sensitive data, making our program readable and expandable, and avoiding problems caused by hardcoding using flowcharts.

Another noteworthy aspect is the debugging process after completing the programming. When we actually started debugging, I realized that there were many more problems to solve than I had anticipated. For example, making the robot car move in a straight line seemed simple, but in reality, it was not. The wheels of the car and the ground would produce a bias angle, and as the car moved, 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 a phone as a light source, and every time the robot failed to track the light, we had to fine-tune the program. After many rounds of debugging and refinement, our robot was finally able to track the light relatively accurately. However, the next day, we encountered another problem - when we put the heavy feeder mechanism on the robot car, the original program failed again. The system introduced new errors, and the original parameters could no longer be used. At that time, I felt very frustrated, but soon I thought of a solution - to let a group member modify and improve the fixation and center of gravity of the robot and the car, aiming to make the car move normally again. Meanwhile, I adjusted the program to make it adaptable to “fuzzy” control. The result was that my “fuzzy” control program failed, but the group member’s adjustment of the mechanism and my removal of some redundant parts made the robot very sensitive again. By then, the final presentation was approaching, so I quickly completed the other parts of the program and added manual fine-tuning to prevent unexpected situations during the presentation. After that, everything went smoothly.

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

In the end, maybe our robot was not very beautiful, maybe it couldn’t precisely find the shutdown button, maybe… but these didn’t matter anymore. The struggle over the past few days, the solution to each problem, the trust and understanding among group members - all these will become valuable assets in my future life.