On our robot, we tried to incorporate sensors to calibrate the robot with ease from anywhere on the board, not just in base where we can touch the robot.
In addition, we also tried to comment frequently and make our code easy to read, so other people who worked on the robot can easily understand the previous code and debug it, and/or change it if they feel that they have an idea that could work more consistently than the current one.
Also, we tried not to just “hard-code” the distance and rotations in our programs, as the table surface can vary. As our programs are simple - we tried to minimize the use of sensors to use them to calibrate and reset the robot rather than have our missions depend on them, which can be unreliable to a certain degree - but effective, we should be able to easily change our missions should we decide to change one or more parts of our robot.
Finally, all of our programmed missions are located inside one project, and the aforementioned project is backed up in 5 different places - 3 computers, Zion Lions team drive, USB - just in case of any emergencies. As well, we tried to have multiple bricks loaded with our programs at any given time, in case the battery runs out.
We are most proud of our proportional, integral and derivative (PID) line follow, which tracks the raw value of the reflected light intensity, then adjusts the motor speeds based on that, the current speed, and the past actions.
We had originally planned on using either a tilted robot design or a robot with treads, but neither quite worked out how we’d planned. The robot with treads didn’t work at all and kept on flipping over, while the tilted robot had no space for a medium or large motor to perform other tasks. Aside from “crater crossing”, “observatory” and “food production”, the tilted robot couldn’t perform to our expectations. After those attempts, we decided to stick with a more standard, yet still creative design. Our robot has touch sensors to automatically stop it from slamming in the wall and a large motor and a medium motor to help complete missions. The robot has a back bumper to guide the starting alignment. We needed the large motor as well as the medium motor because missions this year (e.g. Escape Velocity) are quite power-demanding, while others require precision (e.g. Extraction) don’t need as much power as compared to the level of precision that is required. We also attached some parts to our ball bearing to absorb shock, so the robot doesn’t flip or break in the unlikely case that collides into anything, is mispositioned, or malfunctions.