Arven - Specs

Arven is a personal medication delivery robot designed and built by 3 students (myself [Kia] being one of them) for their Computer Engineering Technology capstone. This page primarily pulls relevant exercepts from the Final Report that was produced as part of that project.

This page will predominantly cover the aspects that I contributed to; you may download the Full Report if you would like to view it in it's entirety. All quotes on this page have been taken directly from the report.

Premise
Scope
Design
Final Result

Premise

There are some people who are in need of a support animal who brings them medication, for various reasons. However, there are some people who are unable to have a support animal due to financial reasons, health reasons, or otherwise. The purpose of this project is to make a non-living replacement for this type of support animal in the form of a robot.

I initially had the idea when I was watching a youtube video and I saw someone talking about how having a support animal helped them remember to take their medication. This is something I have struggled with in the past, however I have 2 senior cats, who would not get along with another animal, and aren't really trainable, so I thought of what would be an alternate solution so I could have the same sort of support. I was also thinking about how some people use reminders for a specific time to take medication but, again, I have run into issues myself with getting the reminder, but not being physically near the medication, and then forgetting it. So combining the reminders with a robot that could bring it to you seemed like the perfect project.

Screencap taken from HowToADHD on Youtube

Scope

The robot will not be able to retrieve medication, it must be placed on the robot ahead of time. It will also not be able to dispense medication; the user will be responsible for taking their medication. Medication compliance will be tracked based on predefined user values, not accurate measurements. The robot's delivery zone will be limited to a single floor of a building and will not be able to open doors. A web application will be provided to manage medication and view a brief overview of the robot's operating information. The web application will be limited to a single device per user. The robot will only be able to deliver medication to a single tracking device.

Design

The below diagram represents the initial intended layout of all the components. I didn't design the overall body of the robot but I did plan out and design the placement of the components within the robot. Some of the highlights are: 2 downward facing IR sensors mounted at the front for detecting a drop (i.e. stairs) [10]; 2 snap action switches mounted at the back for detecting bumping into an obstacle while backing up [11]; 3 ultrasonic sensors mounted in an array at the front for detecting obstacles before running into them [2]; a UWB module for detecting position in relation to the user, and the dock [6]; a force sensing resistor located in the medication holder for detecting whether the medication is present or not [5]; and a custom PCB for connecting everything [4].

Line drawing of the final assembly of the robot broken up into top and bottom views with parts numbered 1-11 — Top (Left), parts 1-9 Bottom (Right), parts 10-11

Motors and Wheels

Ultrasonic Sensors (HC-SR04)

Motor Controllers (DRI0002)

PCB with Raspberry Pi Pico W and ATmega328P

Medication Holder

UWB Module (DWM1001-DEV)

12V Lead-Acid Battery

Power Jack (PJ-096H)

12V Lead-Acid Battery Charge Module (DFR0580)

IR Sensor Modules (SEN0427)

Bump Sensors (Snap Action Switches)

Circuit Design

Circuit diagram showing all the connections of the various modules and components — The complete circuit diagram for the main PCB of the robot.

I created the circuit design fairly early in the project, before we decided to go with only 2 wheels and motors so it shows a total of 6 motors and 3 motor controllers. However, one crucial mistake I ended up realizing near the end of the project is that I had misunderstood the requirements for the motors and the capabilities of the motor controllers, I had believed I could run 2 motors off of 1 motor controller. Because of the size of our motors, the controller could only handle 1 motor which you can see during our early tests. Some slightly odd behaviour when trying to drive which was later confirmed to be because we were slowly killing the motor controller by drawing too much power through it. Unfortunately, right near the end of the project when we realized this discrepancy, we accidentally hooked up the motor backwards which ended up frying about half of the modules on the board. This resulted in us being unable to finish the project in time as it would require ordering new components. It was a painful reminder that having someone double and triple check your work can be a time saver.

PCB Design

A 3D rendering of what the PCB looks like with momst of the components soldered on

Web App UI Design

I came up with the overall design for the web application, making sure to take into account accessibility when selecting colours as well as taking into consideration use from various devices such as a mobile phone, tablet, or desktop computer. Feel free to download the pdf of the mockups or visit the actual web app to view what it looked like. The mockups do not include the mobile renderings but the mobile view can be seen by visiting the app. While I didn't built the web app entirely on my own, I did a good chunk of it due to time constraints, with a strong focus on the styling of the application.

Final Result

In the video above you can see a semi-successful test where the robot navigates to the user, represented by the box on the ground. After the medication is removed and replaced, the robot then attempts to navigate home, however in the test the home dock wasn't actually present so the robot just drives off as the video ends. This was the one and only time the robot worked as shortly after this we performed a couple less succcessful tests before the single motor controller we were using died, followed by our tragic misconnection that burnt out half of the components. In the time allowed we weren't able to determine why the robot did a little spin before stopping. I hope one day to revisit the project, as I retained all the components and access to the code, and get it working with brand new components and a correct motor calculation. If possible, I would also love to actually complete it with the strait climbing functionality.

If you wish to view the code that allows the robot to function, it can all be found on my Github

For more information on how a user would interact with the robot, feel free to download the User Manual