Over the past couple of years, countless companies have developed prototypes of delivery robots that are simply impractical and not designed for daily life. A large reason for this can be drawn to the complexion and overambitious nature of the machines. They rely heavily on GPS tracking and machine learning, but in order for a robot to operate in the busy and unpredictable setting that daily life offers, we believe it is best to keep the design simple, sensible, and much more resistant. We wanted to create an equitable delivery robot that can be used for a very wide variety of purposes depending on the users/organizations' needs.

What it does

The robot has a line sensor at the bottom of it that we programmed to track where it is with respect to the line and how to correct itself. If it gets lost, it is programmed to move either left or right depending on where it is with respect to the line. The robot also has indicator lights that show which direction the robot will be turning so that people can see where it is going. The robot follows this line until it reaches an end indicator line that is just two lines on the side of the original line in a specific place. The robot detects this and stops, indicating that the route is finished and food/drinks can be picked up by people on the dance floor. If the robot bumps into something, it triggers a switch that automatically stops the robot. The robot is programmed with FSM states. The first state is the “waiting” state where nothing happens. A switch is then pressed and the robot starts going into states depending on where it is with respect to the line.

How we built it

To begin the process of building our delivery robot we designed a finite state machine to handle different states as the robot is following the line. We then implemented a basic version of the finite state machine to test our progress using only the LED indicators and not the motors.

In order to see where on the line our robot is, we used a reflectance sensor which is essentially an array of IR emitter and receivers. How it works is first the pins to the sensor are set as outputs and an emitter is turned on for 10ms. Then the pins are changed back to inputs and after 1 ms of waiting the values are read. The receivers over the black line don’t have any input since light emitted is absorbed by the black line whereas the light emitted not over the black line is reflected back. We converted the output of the reflectance sensor into a series of bits and through a series of bit shifting and logic we mapped the different possible values to the different positions that the robot could be in: left of the line, right of the line, centered on the line, and off the line.

We created a finite state machine (FSM) for each of the aforementioned states of where the robot is on the line and created outputs to match such as turning right when the robot is to the left of the line so that we are able to follow the line. We also added in the functionality that when a bump sensor is pressed the robot is stopped. Since the MSP432 board, we used for this project is single-threaded we are unable to do the computation involved with the FSM and get live values from the sensors at the same time we had to get creative. We used an interrupt to update the values from the sensors at a periodic time interval. At every interval, the interrupt service routine is triggered and the flow of the program is interrupted until a flag is cleared that states that the sensor value has been updated. This process occurs so fast it is imperceivable through the observation of our robot.

We tested our FSM by first confining the outputs of each state to LED indicators and after confirming the desired behaviors we then added the corresponding output for each state involving the motors to the FSM.

Lastly, we added additional sensors to increase functionality. This of course complicated the FSM further. Using the BOOSTXL-SENSORS Module and updating the values through interrupts, we modified the FSM so under low light conditions the robot would slow down, when there is no light the robot stops, and when the Z-acceleration passes a certain threshold or in other words when the robot is picked up, it also stops.

Challenges we ran into

While developing this project, we ran into numerous challenges. Firstly, coding was a somewhat new experience for one of our members and they had never done hardware implementation before. However, he was eager to learn and we were able to integrate his ideas into our robot’s design. Additionally, turning the robot on and off using the light sensor was a challenge for us to implement and we performed many tests to develop a threshold that would keep the robot functioning when we would like it to. We also developed a Twilio message that is sent to the user saying delivery was complete. While the Twilio implementation works, due to time constraints, we were unable to merge the ideas together.

Accomplishments that we're proud of

One of our big goals was to make a low-cost and mass-producible robot so that people or organizations can use it on a larger scale. We believe this was accomplished by avoiding extremely complex code, like, GPS tracking or AI which can be reliant on external factors and are more prone to malfunctioning. We had a beginner on this project who learned a lot about computer science through application and hands-on learning by testing. We were especially proud of being able to merge hardware and IoT to create a fun and equitable multipurpose delivery robot.

What's next for Delivery Robot

For the future of the Delivery Robot, the possibilities are truly endless. Using this robot to deliver in an indoor setting through buildings for transporting items from one place to another or in a much larger environment where businesses can operate using our robot to provide a specific service. In 2021, the robot delivery industry was worth $211.5 million, so implementing our product in daily life settings is definitely a possibility.

Built With

Share this project: