Food Delivery Robot Year 2 Project

Overall Poster: Introduction: Schematic: Where these are the schematic diagrams, with the robot one being in the Introduction Entry and the track viewed across the Week entries to show the progress. Software: Where this is the summary of the alternative methods mentioned in the blog entry for Week 4. Hardware: Where the images can all be viewed in higher quality in the Introduction Entry of the blog. Method: Where this is simply a summary of the tasks we completed in order to finish the robot.  The code flow chart can be seen below: Results:   Where this is a general overview of the functionality of the robot and the main components that allow for the robot to work. Conclusion: This section summarises on if we met the aims we originally created and given more time, what would improve the functionality of the robot.

  Week 4 Pre-Lab: During the weekly meeting, there was an issue with the motor and wheel mechanism of the car, after meeting with the supervisor, we discovered that the screw that connects the gear for the track-wheel to the motor had moved out of place, therefore causing the whole system to not function correctly. As the solution was to simply return the screw to its original position, the problem was overcame. The plan for the Week 4 Lab was also discussed, as with limited time and the track design not being finalised, we had to decide on the best solution if the track with black tape doesn’t work; with alternatives including using paper with the track printed on. We confirmed that the original track design was too thick as the tape caused an overlap with the Infra-Red Sensors and caused unwanted turning as well as stops that we didn’t anticipate.   Week 4 Lab: As the motor issue was fixed in preparation for the final lab session, we swiftly progressed onto testing, re-design

  Week 3 Pre-Lab: Post week 2 lab, the weekly meeting was held and it was decided to change the fundamental design of the code. Where it was originally based on a map where an (x,y) co-ordinate was input and the robot moved to this point, it now functions on a track model where the robot will follow a track, avoiding potential obstacles through moving off the track temporarily and returning back on to the track as soon as the path is clear. In order to do this, we needed to design a track pathway and a code for the Infra-Red Sensors to follow. We decided to focus on this task for the lab, taking the Ultrasonic Distance Sensor away temporarily as the path didn't include obstacles at this time. The design for the track was discussed and originally is: Week 3 Lab: As the main focus of the lab was to implement the new code and create the track, the original track we designed was tested, using black tape.  However, an issue occurred with the robot turning due to the Infra-Red Sens

  Week 1 Pre-Lab: We reviewed the original design plan to see if any new modules would be beneficial the function of the robot, the only component that we decided to add was a servo motor so that the ultrasonic module obstacle avoidance could be improved. This was documented in the lab book on the original design plan, which will need to be redrafted. In addition to this, a solution to secure the module has been possibly found, but the decision for a permanent solution will be further discussed after the Week 2 Lab session, where more tests will have been conducted. The plan for the lab session: Week 2 Lab: In the lab session, the code was reviewed and it was decided that this would be the topic of discussion in the Week 3 Group Meeting, as small changes might be necessary. After the brief group meeting, we continued to work on the hardware as the main driving code was separately tested.  Following the plan to focus on the sensors, we started with connecting the infra-red sensor in

  Week 1 Pre-Lab: In order to prepare for the Lab session, the design for the hardware connections and the code was finalised, as well as a plan for the lab: Week 1 Lab: As the resources had arrived, we first checked that all of the modules and components were provided correctly. We noticed there was an issue with the AA batteries and the holders and determined that these were not suitable for the project and instead discussed an alternative. A battery bank was decided upon.  The development of the code started, alongside the testing of hardware that will be used in the circuit, starting with connecting the Arduino pins to the Stepper Motor using jumper cables and to the Breadboard so that it could be wired to a Power Supply Unit in order to check the state of the motors.  The set up can be shown as: The Arduino and Stepper Motor Connections:   The Battery Pack was also tested to verify it works correctly. As the motors are in working order, the movement abilities need

  Background: During recent years, the use of robots as a novelty in hospitality has significantly increased, with robots initially being used in industrial settings. These robots were used for placing orders, however, this expanded to serving and delivering items, in particular food. Hotel delivery robots are efficient as they are a 24/7 service allowing for room service to improve a guests stay, without requiring specific overnight hotel staff.  Goal: Overall, the vision for the Hotel Food Delivery Robot project is for the robot car  to be able to move from a starting point, manoeuvring itself along an ideal path, through any potential obstacles in the way, using the sensors that will be integrated into the robot. The 'map' for the robot will be referred to as a standard two-dimensional graph, where the X-axis represents horizontal movement and the Y-axis is the vertical translation of the car. The total length of the room determines the maximum value for the Y-axis and the t