One of many solutions to help our front liners fight this pandemic is automating some of their tasks, that doesn't need expert medical background to do it. One of those tasks is delivering things to the patient. Those goods could be foods, medicines, or family-givings to the patient. While it seems not-so-significant, it is actually one of the most frequent thing that our front liners do to the patient. It happens because not all of the patient are suffering chronically from the pandemic, and still doing some normal activities, but quarantined. According to WHO, only one of six person becomes seriously ill because of the disease, and 80% of people recovered without needing serious treatment. That's why in developing countries, there exists quarantine facilities that are being built from hotels, or rarely-used big buildings.
The delivery, despite of being an not-so-significant looking task, the front liners still need Personal Protective Equipment (PPE) suit to deliver goods to the patient. Meanwhile, in developing countries, those suits are rare commodities. Many medical personnel have to wear the PPE suit just in a single, short-term occasion of goods-delivering, and that would mean that they have to stock more of those suits, or in current cases, wash it more often, or in the extreme case, they would use the suits for all day and it will leave bruises on all of their face and body. Using the same suit for many times would decrease the durability, hence makes the front liners more vulnerable to the disease.
Existing SolutionsRobots are being deployed to hospitals and quarantine facilities in order to reduce contact between medical personnel and patients. Not only in developed countries, but also in developing countries. These are some of the examples.
"What's the possible price of those robots ?", you might think. According to the reports, most of those robots cost > 2000$ each. Yes, they are very sophisticated, having a great AI in their programs, expert computer visions, or other advanced technologies you can think of. Yes, they are expensive for a valid reason.
Proposed SolutionWhat makes those robots really expensive might be some of the followings : high-speed CPU, a decent camera, or high-precision motor encoders. That sums up, one of the most costly parts of building a robot is its mobility and localization systems.
In terms of mobility, a line following system is a pretty simple, yet robust way to control a robot. Just follow the line ! This is a cheaper approach that is also being used by some industries. But how can we do the localization or some specific actions outside of line followings for some events ?
Here comes the line-decoding part. Instead of modifying the robot, we can actually modify the environment. The idea is, to modify the line, such that the robot will recognize some patterns of the line to be the trigger of some events.
Another hard part of building a robot is constructing the mechanical structure. Not everyone has the ability to do the manufacturing process ( like welding, CNC milling, neat cutting, etc ) in their house. Our approach to this problem is a humble plastic shelf that you might often see in the kitchen or bathroom, with some modifications. The design is just perfect for the needs, and the structural integrity is pretty solid as well. Just do a bit drilling, screwdriver jobs, add some wheels, bolts, nuts, and there you have it, a robot base !
For the system itself, the robot will use Firebase Online Database from Google as a real-time database to communicate with a mobile app. The robot can be controlled with the app to give orders to the robot about the rooms that need goods to be delivered, and it will automatically follow the line to the specified room. This app will hopefully provide an easier environment for the operator of the robot to control it by not needing a manual system for operating.
For extras, just in case some communication is needed with the patient, a phone holder is provided in the top-most tier of the tray. With an internet connection, the medical personnel can communicate with the patient with a video call by messaging apps.
Overall, this project costs < 200$, and that's clearly cheaper with enough features to tackle the current problem. So enough talking and these are the steps !
Step One : Constructing The BaseThe shelf comes disassembled and can be assembled easily just by plugging one part to another. Start by taking one shelf tier and do symmetrical drilling left and right ( details in the picture ), attach the bolts and nuts. It doesn't have to be perfectly the same as the picture, but we use this arrangement ( or maybe it's just because we do not study and understand mechanical engineering lol ).
There are some tricky parts, like attaching the wheel with the motor. We tricked this by using the default hole wheels and attaching a circular acrylic piece with 7 cm diameter.
We personally get this specific shelf only available in my country, but some other shelf will do fine (like what is attached in the BOM), and they can come with ball wheels attached/not attached.
This shelf comes with no ball wheels attached (this might be better so we can configure optimal settings by ourselves), so we have to get 3 extra ball wheels. We encounter a problem where the ball wheel is not "tall" enough to support the main motorized wheels. We handle this by using PCB spacers (M3 Size) to support the ball wheels like the picture below.
The schematics are shown below. The design is pretty straightforward:
- ESP32 as the main processor
- A 5-channel TCRT-5000 based line following sensor
- A4988 motor drivers (You can use other motor drivers like DRV8825)
- A MINI360 buck-converter to step down the voltage, you can use LM2596 as substitute
- DFPlayer, LM386, and Speaker for audio
- A button for user input
The installation of the components on the robot-base is in this picture below.
Creating the Firebase Database is very easy. First, go to https://console.firebase.google.com/ and click on "add a project"
Give the project title
Press continue
Click on "Create project", and wait until the proccess is done
In the project dashboard, choose on the "Database" menu on the right panel, and choose "Create database", and choose "Start in test mode".
And its done ! The Firebase Database is ready. Save the Firebase Host URL and the Firebase Secret Key. Add the following node child :
Firebase secret key can be obtained by clicking on the "gear" symbol, go to "project settings", and choose the "Service Accounts" tab.
Look at the project name, and show the database secret, then keep it for the code later.
Step Four : The CodesI split the code into some parts in order to ease readings, since it might be a pretty long code. There are some external libraries that I use :
- FirebaseESP32 library from Mobizt
- AccelStepper library from MikeMcCauley
- DFRobotDFPlayerMini library from DFRobot
A note before compiling and uploading the code : you have to select the partition mode to be NO-OTA/HugeAPP (shown in the picture below), since it will need both Bluetooth and Firebase library and it took quite a space, even for an ESP32, it will give 2 MB (for no OTA, program memory instead of the default 1.2 MB program memory.
We used a semi-Finite-State-Machine (FSM) approach to the code, because personally, we think it made the code more explicit and gives clarity about what is happening with the robot.
The flow of the program will be like this :
- Through the mobile app, get the SSID and password for WiFi via Bluetooth (This is optional, if the code already contain the SSID and Password of the WiFi)
- When it get SSID and password for WiFi, go online and connect to Firebase database
- Get required parameters from database ( all rooms, target rooms )
- Move toward the target room
- Wait for the recipient to accept the goods and press the button
- Move toward next target room
- If reached the end of rooms, go back to starting point, and wait for next order
App Source Code : https://github.com/andresubagjamanurung/Hacksterobot-App
App APK : https://drive.google.com/file/d/1XZPRcuhLM8vUhi_UJ85aWQp0xNPcsT3x/view?usp=sharing
This robot will be controlled by mobile application via Firebase as a realtime database, so it will use the internet connection of course. Considering the floor in every hospital has been covered by WIFI/router, it will be easier to use this method to interacts with the robot.
Our application controller can be used to control 3 robot all at once (at least for now) with different IDs. It will present battery percentage, list of available room can be covered by robot, current location/room, notify the robot, and change the room command (set order of room the robot need to go)
In order to build the app to control the robot, you can either use entirely our system, editing source code, or build your own.
1. Our system : You have to use our robot and app source code entirely and don't changing anything, including IDs, firebase tag, and our app source code (or use our.apk in attachment).
2. Editing source code : You can build your app with your own firebase database and adjust it with your robot source code. Here you can manage the name of robot IDs, firebase tag, and UI & program of the app.
Important step for choosing option 2 (change to your own Firebase database):
a. Build your own firebase database, if you haven't you can check out in this :
b. Go to your Realtime Database, go to Rules and set ".read" and ".write" to true. Go to settings (on far left) then Project Settings.
c. In General tab, scroll down and see Your Apps, click Add App. They will request for package name, change the package name of our app source code (first line MainActivity.java), copy the package name, fill the package name. Download "google-services.json"
d. Open Android Studio (or other IDE you're using), check inside "app" directory, and see if there is google-services.json already. Delete that file and put your own google-services.json file.
e. Go to File and Sync Project with Gradle Files, finally the app will accessing your database. If necessary to ensure the app connected to your database, open Android Studio, go to Tools, Firebase, and connect to Firebase, choose your database.
Step Six : Line Rules and InstallationThe line will be made by using 3-cm-wide tape (any black-colored bands with the width of around 3 cm will do just fine, I chose electrical tape since it is easily available and cheap).
The lines can be classified into :
- Straight, regular line
- Dashed line
- Full line
The robot will recognize the straight line (or bent lines) as a regular path for the robot. The robot will just follow these lines without any special interpretations.
The robot recognize dashed lines as a room marker. Every dashed lines will be the landmark of the robot position, so it knows where is its position, and when to turn to a room. The dashed lines is made for a round-trip, so the robot will not misunderstand a junction and can get back to its starting position. The space is represented by the white space at the picture above. The distance of the space is set to be any number between 3 cm and 7 cm to handle setup inconsistencies.
Full line is a line that will block all of the sensors reading, means that is the start/end point of the trip. The robot will start from here, and also ends here.
The reason that stepper motor is used is to better follow these lines. It can track some of needed motor movements we need to track, like move with a specific distance even if it is not highly precise and accurate, as long as it still follows the line then it is fine. The calculation to rotate to certain degree can be done by following formula :
In this case, the number of steps of stepper motor for every revolution is 200 steps, the base width is 40 cm, and wheel diameter is 12 cm. So for example if the robot needs to rotate 90 degrees, each motor will have to move approximately 167 steps toward its opposite directions.
These stepper motors also can carry a quite bit of load (up to 2.5 kg). DC motors / Brushless DC motor can also work fine, and carry more load.
The TestThis is the demonstration with 4 "rooms" as example.
ScalabilityScaling up this project is very straightforward.
Need bigger load to carry ? Go for a bigger motor and batteries (Like 24 Volts motors and 6S LiPo batteries) ! And better motor drivers of course !
Need bigger space ? Go for a bigger and stronger shelf !
Need a more robust database ? Subscribe for an upgrade ! (This is not sponsored)
Vice versa also applies when scaling down is needed. The example is home quarantine situation, for the uninfected house member to reduce contact with the infected.
That's AllEvery system has a downside, and yes this system of course has flaws as well. There might be bugs on the programs that are not spotted (yet), some mechanical and algorithm redundancy, and lacking of aesthetics. We would be happy and really appreciate it to receive inputs for the improvement of the project !
Comments