Performance Checkpoint 1
Our design met the specifications perfectly. The goal was to drive up the ramp and to touch the wall. This required the robot to have the drivetrain completed and the code that allows the robot to drive forward and turn. This checkpoint also required a mounted opt sensor for the robot to start the course. These specifications were simple to have, and our robot satisfies them. Our design performed as expected. The team expected the robot to drive and turn like a car, which was exactly what the robot did. Despite our wheels being in the wrong orientation, as the incorrect wheels were connected to the motors, the design worked properly. The four wheels allow for easy navigation and control on the ramps. The light sensor is also at a great height and the cone shape allows for easy light detection.
While our design is quite solid, we were advised to change the wheel orientation; we had our omni wheels as powered wheels, and this will be changed by the next exploration. During this exploration, our robot had hardware and software issues. Within the hardware, our wheels broke off a couple of times. The hot glue attachments were not strong enough to handle the constant rotation of the wheels. Our wires were also not wired correctly, this was causing shaft encoders to not read properly. The team was ready to run into problems as we set us up with enough time to handle any issue. We were able to test the robot enough to solve all these problems. The main issue was that this was the first checkpoint, and the team had never attached the wires before. We now have proper documentation for the wires and so those mistakes will not be repeated. Since the wheels will be rearranged, they will have stronger mounts, which this will stop them from falling off.
Performance Checkpoint 2
For this checkpoint the robot was required to do the previous checkpoint, but now read the color of the ticket kiosk, and then click the proper button. This required the robot to use the sensor to read the color, display which color was read to the screen, and then click the proper button. The robot has an attached sensor to meet the color reading requirement. To be able to click the button, the team decided to run into the button with the chassis.
The robot performed under suspicious circumstances which made it complicated to navigate around. In certain tests the robot would line up on top of the light and read the correct light color. Yet, there were certain runs where the robot would be off slightly and automatically set the light value to blue. The light sensor and the wheel orientation work as expected and will remain into further developments of the robot. The robot experienced many problems with hardware. Specifically with the axles of the wheels, they were not aligned properly, and the robot would sometimes drift. This would cause the testing to be inconsistent and difficult to fix. The team had enough time to redo the axles to allow the robot to consistently drive forward. However, there is still an issue with positioning, and it is unknown why this issue exists.
Through this exploration the team discovered the robot became too long to meet the final design requirements. For the future the robot will be shortened as it has become too long with all the additional attachments. The team has curated a plan to use either RPS or line following to conquer the position issue. The other issues that the team experienced have been resolved and should not be an issue when other elements are added. Since the wheels are attached stronger and straighter the robot consistently drives straight and any software problem was fixed and documented in case a similar issue arises. Additionally, the team will add a mechanism to click the button in the future.
Performance Checkpoint 3
Performance test 3 required the robot’s mechanism to be fully built and functional enough to flip a fuel level up and down. The team was able to meet this requirement with a forklift mechanism that works with a pully system. This design worked but had some major difficulties. The first issue was that there wasn’t enough force to push the lever down. Then one of the solutions to this problem, which was to add springs, caused the pully on the servo motor to pull off under the stress.
Though this design has some struggles, people are enthralled by watching the robot. The design works in a unique way that people find interesting. This element of design will be kept in further iterations. Additionally, the forklift can comfortably move upwards at a steady rate, so this function will also be kept.
There are several improvements that will solve some of the problems the robot encountered. The string will have a yo-yo like guide to help keep the string in place, the forklift plate will be heavier to use the force of gravity to push things down, and the mounts will be reinforced.
All problems were hardware based, either something would pop off, there wasn’t enough force, or the proteus level of charge would under power of overpower the motors. These will all be solved with future improvements and making sure the proteus is fully charged before every test.
Performance Checkpoint 4
Performance checkpoint 4 required the robot to be able to lift the lever arm of the
passport task to a specific height at which the passport stamp will fall over onto the other side of
the task. Succeeding in this, yields full credit for the checkpoint. Bonus points can be awarded by
pushing the lever arm back down to its original position. The team’s forklift design worked
perfectly when task with lifting objects up and down so it would work perfectly when lifting the
lever arm. There was one unforeseen issue though, the plate of the forklift could not be lifted
high enough to completely flip over the red passport stamp. To fix this issue, the robot was
coded to do a small turn to the left once the forklift has reached its maximum height to push the
lever arm further. This proved successful and the checkpoint could be completed with the current
design.
Going forward into the final checkpoint, the robot’s design does not need to be changed
at all. During testing, the robot performed extremely consistently. Therefore, there are no design
changes that need to be made, rather the code can be further refined to eliminate other issues that
could come up in the future.
All issues that were experienced during testing for the checkpoint were strictly software issues. These were mostly issues with aligning the forklift with the lever arm of the passport task. These software issues were fixed with rigorous testing resulting in the aforementioned
consistency.
Performance checkpoint 5 required the robot to be able to deposit the luggage into either
of the two different luggage sections. After the luggage has been deposited and it remains in its
respective section, the robot must press the final button to yield full points for the performance
checkpoint. Bonus points can be awarded if the luggage is deposited into the higher of the two
sections. The team’s forklift design worked somewhat well for this checkpoint.
The difficulty with our design was that it heavily relied on lining up the robot perfectly at the start of the run. If the robot was slightly misaligned, the luggage would never make it into the deposit area, instead
it would balance on the outer edges of the overall luggage area which does not count for any
points. To fix this issue, the team created a system to properly position the robot as to try and be
as consistent as possible.
Going forward into the in–class performance test, the overall design of the robot needed to be smaller. A guide/stencil should be created so that the robot will be lined up in the same manner for every single run. This way, the inconsistency that was experienced during testing will
be eliminated with the line up tool. Rigorous testing helped to alleviate some of these issues by
making the code more robust also allowing some of the inconsistency to be eliminated.