Performance Test 1:
class day early and the bonus challenge of going back down the ramp. Our design matched and
met all the specifications for the first checkpoint, which included being able to move across the
course and being able to turn effectively.
Our design took 4 test runs to master the checkpoint criteria, but in the end, it performed
exactly how we expected it to. Some successes of our robot include correctly adjusting the
chassis to be parallel with the edge of the ramp at the start, as well as the robot being powerful
enough to make it up the ramp. We will be keeping the robot exactly how it is for the next
checkpoint but will be adding things on top such as the QR code mount and a servo. The design
could be improved by securing the back wheels better on to the Igwan motors as they fall off
frequently.
The design could be improved by speeding the motors up to move and turn the robot
quicker. Some problems we experienced during the test runs was that the robot was not going
down the ramp correctly, as it would turn too far into the side of the course while going down.
This was a software problem and was addressed by updating the code to make sure the robot
didn’t turn too far. A few simple hardware problems we encountered were that the wires
connecting the motors were being dragged across the course and that the front wheels axles were
very loose. The wire issue was easily fixed by taping the wires to the sides of the robot, and the
front wheels issue was fixed by changing the front axle system from one small axle for each
wheel to one long axle for both wheels.
Although we had a few simple hardware problems, we encountered a large hardware
problem regarding the back wheels, where our back wheels were not sticking to the axles
correctly. First, we attempted to use Loctite 242 to hold the wheels onto the axles. However, we
found out that Loctite 242 was an ineffective option for this task. We then removed all traces of
Loctite 242 from the wheels and axle and used hot glue to keep the wheels on the axle.
We were not behind schedule at all and were pleased with the design and the execution.
Our team efficiency was great, and we did ample amounts of testing beforehand. To ensure
success in the future, we will try to catch all problems during test runs and make sure that our
robot is precisely ready to go when it comes time for the checkpoint.
Performance Test 2:
For Checkpoint 2, our design met all the specifications required for this checkpoint. The checkpoint required the robot to move through the course and up the ramp, press any of the kiosk buttons, and move back down the ramp. To complete this checkpoint, our robot included a fully functional and stable chassis, and an adequate drivetrain to move around the course.
Although our design met all the requirements and specifications, it did not perform exactly how it was supposed to. We had a lot of trouble in our code to move our robot through each part of the checkpoint, which will be explained later. Some strengths of the design included our strong chassis, and our shaft encoding was extremely accurate, which allowed us to move our robot easily. We will be keeping our robot design the same for the next checkpoint but will be adding a mechanism in the form of a metal arm to complete the remaining tasks.
Our design could be improved by decreasing the friction between the axles and the wheels, as there is a noticeable slowed speed and slipping of the front wheels. This would help us complete the tasks quicker, which could help us in future checkpoints. Another way the robot could be improved is creating holes in our chassis to organize our wires better. Currently, all our wires can tend to hang out of the sides, so wiring them through the chassis would keep it clean and out of the way. Our main problems were software related, which was mentioned earlier. Our timings to move the robot through each part had to be experimented with a lot until the right numbers were found.
We did not encounter any major hardware problems besides some minor tweaks that could be made, so our physical design did not need to be altered. Our team was ahead of schedule, getting the checkpoint completed early and receiving bonus points for it. This allowed us to have ample time to write our code, create our design, and conduct enough testing beforehand. Overall, the only major problem we encountered was software related, and all other aspects of the checkpoint (design, team efficiency, etc.) were great.
In the future when a problem is encountered, we will first attempt to locate where the problem is happening from. Once that is found, we will do all the necessary tweaks and testing to fix the problem. This has been working well for us and we will continue to employ this tactic.
Performance Test 3:
Our design was able to complete all normal and bonus tasks for the performance test earlier than the deadline, and therefore met and exceeded the necessary specifications. The design for the robot performed as expected for the first two levers, but for the third lever the design of the robot required a different process for flipping the lever than expected.
The strengths of our design were that the arm was extremely good at holding and moving the lever as its U-shaped design allowed for the arm to hook onto the lever and easily flip it. This means that we should keep our whole current design when going into the next performance test as all elements of the robot function well and allow the robot to easily complete the tasks. Although, the design can be improved by increasing its stability by ensuring that parts like the QR code will be stable throughout runs.
There were both hardware and software problems leading up to the checkpoint. The main hardware problems were finding appropriate ways to attach the QR code and arm to the robot. Hot glue was initially used to hold the QR code up and Epoxy was initially used to connect the arm and the servo, but neither worked well. To fix the QR code problem, Velcro was used to hold the QR code between the stands. To fix the servo and arm problem, angle brackets were used for the arm to connect the arm to the servo in the most stable way. The main software problem was that the robot, when going to the last lever, bumped into the wall when turning towards the lever, so a unique set of movements was made for the last lever so it could be flipped properly. All the problems in this checkpoint were in the execution, as the initial design theoretically functioned well.
We will address future problems of stability by going to angle brackets as the first method of connection, as they are extremely stable compared to all other methods we attempted. We will also address future problems in the software by determining unique solutions which work with the design of the robot to help align the robot and complete tasks.
Performance Test 4:
Our design met the specifications and requirements of the checkpoint, as the point of this checkpoint was to have a fully working mechanism to complete the stamping task. Our design was able to complete the stamping pass effectively, although it required many attempts with two different strategies. The final strategy involved using our robot’s arm to push up then turn the stamping pass.
The design at first did not perform as expected, as we approached the stamp from the front which required an extreme amount of precision for our robot, which was not realistically possible. However, when we switched to approaching the lever from the side, the design performed perfectly as expected when flipping the stamping pass.
Our robot was quite precise during most tests, and so the hardware of the robot should remain the same, generally, for the next test. Some improvements we could make include getting the robot into position faster, as it takes a lot of time to set it up in the correct position. This would help in the final competition, as well as even helping in the regular tests as we could dedicate more time to other tasks of the course. Another improvement we could make is that we could use RPS to line the robot up better in arbitrary positions.
The main problems during this checkpoint arose from software problems, as we realized that our arm mechanism to complete the stamping task requires high precision when approaching from the front. Once we changed from approaching the front to the side, the robot functioned as expected. Our team was ahead of schedule, getting the checkpoint done early. Overall, our problems were in the design of the program of the robot. Once a better methodology for completing the task was discovered, it became much easier to complete the checkpoint.
We will address future problems regarding software by doing a lot of testing and isolating specific implementations of our ideas which are either flawed as a solution in general or can be changed to properly implement our given ideas.
Performance Test 5:
Our design met all the specifications and requirements for the checkpoint. This included a mechanism that can securely hold the luggage while the robot is moving and that can safely drop the luggage into its designated place. Our design performed almost just how we thought it should have performed, with a minor software problem that will be discussed later. It was able to hold the luggage on our metal arm mechanism and drop it into the designated drop-off zone.
Some strengths of the design include that the luggage is safely held on the arm and is never in danger of falling off. Another strength includes its accuracy in dropping the luggage in the designated spot, as there is not much ambiguity on which spot the luggage will drop into. We are going to keep all hardware and software the same going into the competition, as our robot easily and successfully completed the checkpoint. If we had to improve our design, we would more accurately and precisely test the robot to see how the luggage affects the weight of the robot and find the most optimal way to take this into account.
Our robot did not experience any hardware problems but encountered an important software problem. Our code was running with regards to the weight of the robot before the luggage was added. This means that all the speeds and timings were applicable to the robot’s weight before the luggage applied its weight to the robot. Once the luggage was added to the robot, the code (timings and speeds) had to be updated to take the new weight into account. This was done by creating a multiplier that is used from the start of the run until the luggage is dropped off. This successfully fixed the problem, and we will be using this strategy going into the competition. Our team was very ahead of schedule, finishing the checkpoint two class periods early and gaining all the possible points and bonus points. Overall, the problem was not with the design, but with the execution. This was fixed by a minor code change.
If another problem like the one encountered in this checkpoint arises again, we will isolate the problem to discover the underlying issues. Once that is done, we will do consistent testing to figure out the best solutions to the problem.
Final In-Class Performance Test
Our design met the specifications and requirements of the Class Performance Test, as the point of this test is for the robot to complete all the tasks set by the robot course in under two minutes. Our design was able to complete all the tasks and bonus tasks in under two minutes.
The design performed as expected, as the robot ran through the same course as it did in our testing and checkpoints and completed all the tasks. There were not any changes made on test day. On test day, we were able to complete all the tasks and bonus tasks on the first and second runs, with the robot receiving about 60 points on the third run due to some problems with the code for the C course specifically.
Some strengths of the design include its movement accuracy, having one mechanism for all the tasks completion, and the 4-wheel drivetrain helped with the accuracy of the robot. We plan on keeping all the hardware of the robot the same, and plan on making minor tweaks to the software for more accurate task completion.
As said earlier, the robot can’t really be improved hardware wise in such a short time, but we plan on tweaking the software slightly to make certain parts of the course more accurate. This includes the code for course C, as well as other small parts of other tasks. Another change that could be made could be that the wires could be organized better to ensure no wires will interfere with the robot running, even though the wires do not usually interfere with movement.
Some problems that occurred during the test included a slight bump with the passport stamping task as completing the boarding pass, but it did not affect our results. Another problem occurred before the second run, where the proteus had to be restarted around five times before the code was able to be run. The last problem had to do with the code for course C, as the robot was not in the correct spot for the passport stamping task. Our team was on schedule for this test, as we did ample testing beforehand. Overall, the problem with robot had to do with the execution of the robot before and during the test, which was fixed by tweaking some of the timings and speeds in the code slightly and continuously restarting the robot.
If we encounter similar problems in the future, we will first isolate the problem, whether that is in the hardware or the software. Once the problem is isolated, we will make changes to the hardware or software along with enough testing to fix the problem. We will also have to now determine solutions which are time-efficient, as the robot has only one week before the final test.