Week 8: Final Stretch 😿

This week was another fun and intense week for us. We had to finish up a lot of things and really put our entire system together. We ended up meeting almost everyday, and working individually as well to grind out the details of our project and get it working.

Mechanical

In terms of mechanical, we had a few things that needed to be ironed out. We realized after testing our IR sensors that we needed to place our IR sensors on the sides of the pot further away from the wheel. This would give us more time between detecting an edge and starting the code to turn the pot away from the edge. Testing the IR sensors outside of the pot seemed to work really well for the team after initial testing, and so, bigger holes in the chassis were carved out to allow the IR sensors more space between the wheel.

Tank

Additionally, more thought went into the design of the tank. We had tested out 3 different iterations (the original interlocking acrylic tank, a tighter tolerance-d interlocking acrylic tank, and a mixture of 3D printed and acrylic tank with a smooth corner), as well as waterproofing techniques varying from hot glue, a gasket and silicon sealant. Unfortunately, none of these options were successful. However, after great brainstorming we came up with a solution! At first we were thinking of attempting to use aquarium sealant glue, as suggested by our profs, but careful research made us realize that the glue was only effective on glass materials, rather than our acrylic. We thought perhaps another material could be used instead then, such as glass, but that would be far too expensive, and so we thought of thinner plastics in the form of plastic bags or flexible pouches. These were other good options, but it would be hard to place these oddly shaped objects in our pot. THEN SUDDENLY, we realized we could use a bottle! Water bottles made of thick plastic had perfect waterproofing, and the plastic could be used with our level sensor! And to make things even better, we happened to have a 200mL bottle (perfect for our constraint of holding up to 2 weeks worth of water) that could be placed in our tank. We decided to test out this method with our level sensor and see where it would take us. Miraculously it worked really well, you can see the results below, but long story short is it worked with the capacitive level sensor! This makes sense because the container we were using was made out of a thin plastic. After we found out that this worked and performed some testing, we got around to 3D printing a fancy holder for it, and cutting off the top of the bottle. Here's a pic of the bottle with the 3D printed holder:

Ultrasonic Sensors

We also got around to 3D printing some small parts to hold up our ultrasonic sensors, these were fairly small and easy to print, but help out a lot in holding up the sensors securely. Other alternatives to putting these sensors in their correct position is tape and glue, but this method is far more secure and will give us more consistent results. Here's a pic of the pieces we printed along with the sensor to get a better feel of how it will fit in our robot:

Switch

We also ran into a bit of a minor issue while putting our switch into our robot. Turns out we were supposed to put the switch into the robot first, then solder in the wires... Oops. While this is what we were supposed to do, it didn't make much sense to solder the switch while in the robot as the spacing inside the robot is very small. Sooooo as a work around to actually get our switch into our robot we had to carve out the hole for the switch and sand it down. After what felt like an hour of sanding and cutting we managed to get the switch into the hole, we then secured it with some glue and were good to go.

Electrical

Electrical work from this week primarily went into soldering and wiring up our little pot. We had initially put everything on breadboards and placed it into our Arduino, but we realized this was getting far too messy and crowded in our robot. Instead, we soldered our parts to prototype boards, and wired them into our robot. Unfortunately, some of the prototype boards we used were a bit too large for our needs, and so, we went to the machine shop to cut our boards into cute little pieces that could be scattered throughout the inside of our pot. This would spread out the nest of wires centered around the motors, and would make it a lot easier to organize which wires connect to which sensors. After a lot of soldering, de-soldering and re-soldering, we were finally done with our mini-protoboards of wires. Here's a quick breakdown of our mini-boards:

1. IR sensors

2. Light sensors

3. Wheel motors and motor drive

4. Pump motor and motor drive

5. Level sensor

6. Buck converter and switch

7. Generic 5V rail to Arduino

8. Ground rail to Arduino

Here's a little pic of the current wiring status of our robot. You can see how we managed to separate a lot of our sensors into chunks, and organized the pot a lot better with our batteries and Arduino in their proper places:

3.3V Linear Voltage Regulator

We also had to solder up a linear voltage regulator to ensure we would get 3.3V from our Arduino. We'll talk about this a bit more later when discussing the WiFi module, but long story short we needed something to ensure we would get a consistent 3.3V to power our WiFi module, and so, we decided we could use a linear voltage regulator that went from 5V to 3.3V. After scrounging for some parts at the IDEAs clinic because RigidWare was closed, which was a big shock to us as it meant the hours on Google maps LIED TO US 🤥, we found a variable voltage regulator which could go down to 3.3V and so we used that along with some capacitors and resistors. We also managed to make a trip to RigidWare the day after (when they were open) and picked up a spare regulator in case things went sour. Here's a picture of the variable voltage regulator we found soldered to two capacitors and resistors to get to that 3.3V.

Other

Aside from our usual business, we also encountered a really big issue with our electrical work. We discovered that we actually burnt out the linear voltage regulator on our Arduino. After probing the regulator with our multimeter we found that while we were giving our Arduino 9V from our battery (as expected from our buck converter), we were only getting 2.7V from our 5V and 3.3V pins on the physical Arduino. This was waaaay too low of a voltage considering we were using the 5V pin to power all of our sensors and motor drives. We suspect that this happened a while ago when we were testing out our edge and object detection as at one point our regulator got really hot on the board, we had thought this was an issue with our batteries (as it turned out, the batteries were low so we charged them, which fixed another issue), but this was not the case. Turns out we were drawing far too much current. This is likely because we were using new IR sensors as our other IR sensors in which we calculated the current draw from was very low, but these new ones were probably way too high considering each sensor makes use of a small board with its own chip, along with 2 LEDs. We decided that for the purpose of what we needed to get done, it would be too much of a hassle to attempt and fix the regulator immediately. Instead, we would power the Arduino and the components through a laptop, and the motors through the battery (as they still require 12V to operate). Once we figured out all the logistics of our robot and got a really solid demo going, we would then swap out the voltage regulator with another one and attempt to get the overall current draw down. This could be done by removing some of the LEDs on the IR sensors, and shutting off power completely to certain components when not in use. However, making use of the laptop to ensure the logic of our system worked well was our primary focus for the end of this week.

Firmware

Object and Edge Detection

It was another busy week for the pot's firmware with more testing performed with the object and edge detection aspect of our robot. We decided that this was probably most important to the safety and lifetime of our system so we wanted to perfect this. As mentioned in the mechanical section of this blog post we had some issues with the placement of our IR sensors, but we also had more issues... Turns out when we were attempting to run the pseudo code mentioned last week, we ran into the issue where the robot would not turn long enough to be considered on the table. This meant that our robot would end up driving off the table. To fix this we implemented a new algorithm

if edge is detected
    loop until and edge is no longer detected
        move backwards
        turn right            

While the movements of this algorithm looked a bit janky and fidgety, it worked incredibly well on different tables, shapes and windowsills and so we knew this was the right way to go. Watch our video below to see our little guy successfully detecting an edge:

After adding in our edge detection code, we decided to work on object detection. In terms of logic we went with the following algorithm:

if object detected
    turn 45 degrees

This would allow us to detect an object and turn around until no object was detected. The algorithm worked really well and was successful in finding a window, box, bag, hand, etc. We did however notice that our ultrasonic sensors were not optimal in detected cylinders such as narrow cups. This is due to the nature of how the ultrasonic sensor works, where we emit a wave and have to wait for the wave to come back. With cylindrical shapes the emitted wave would bounce off the object in the incorrect direction and wouldn't get picked up by our sensor. This meant that we couldn't successfully identify where the object was. Another issue we ran into was with detecting certain sized objects. We were unable to detect objects such as a chapstick or phone lying on the table. This is likely due to our sensor placement at the top and sides of our robot. In future iterations we would considering using an ultrasonic sensor that can pick up cylindrical objects (better accuracy), and moving the sensor placement to the bottom of the pot or more in the center. Regardless, we discovered that our current system would be successful for all other cases and so we decided to move on. Watch the videos below to see some edge detection and object detection all together:

WiFi Module

After some rigorous testing we had to stop with our edge and object detection as our batteries were running low. Thankfully our friends had a charger (for their capstone project) and so we charged 'em up and we were ready to move the next day. In the meanwhile we got around to setting up our WiFi module so more investigation into our mobile app could begin. We first had to setup our module to be able to upload code to it through the Arduino by following a quick tutorial of the ESP8266 WiFi module. The tutorial taught us how to connect to our internet network, as well as change the upload speed from the default 9600 baudrate to a baudrate of 115200. And so, we began development into our WiFi module.

This went hand-in-hand with our high-level software development, and so our database was created (see below for more details). After this was created we investigated sending data from the WiFi module to the database. We discovered that there was an opensource Arduino-Firebase library which could be used with helper functions, and so this was implemented. After half a day of struggling, we finally got it to work. Our biggest challenge was uploading code to the WiFi chip because we were using a hack to upload code through the serial communication lines on the Arduino, rather than a separate module compatible with the ESP8266 (which would've cost a lot more). However, after this was done, we were ready to move onto integrating this into our state machine.

There was a lot more struggling with this aspect of the code as the serial lines between the Arduino and the ESP8266 chip were the same as the serial monitor on the Arduino (or where we were printing our debug statements). This meant that we were in the dark about the status of what our code was doing a lot of the time. However, we later discovered that additional digital pins could be used instead for our serial communication, opening up the serial monitor for use once again. After this realization, updated code was flashed onto the Arduino to send our WiFi module data regarding the battery and water level status (for now they were just randomized values). Unfortunately, this wasn't working as expected. As it turned out, the 3.3V required from the WiFi module coming from the Arduino was inconsistent. This meant that sometimes we'd get 3.3V, other times we'd get 3.0V. This was far too little to send to our WiFi module, meaning data wouldn't be sent or received. We needed a voltage regulator. This would allow us to use the 5V coming from the Arduino and lower it to a consistent 3.3V. We did have a spare voltage regulator lying around to use, but this one was far too bulky for our slim design, and so we realized that we would need to go to RigidWare and buy a smaller component. However, through testing with our large voltage regulator we were able to successfully send data from the Arduino to the WiFi module to the database live! Watch the video below to see our progress.

Pump

This week we also got around to testing out our pump (after soldering it to our mini proto-board with the H-bridge). We had to determine how long to keep the pump on to equate to 1 tablespoon of water, or 15mL of water. This was chosen as prior research shows that small houseplants need about 15mL of water each day. Furthermore, we also verified that we could pump out water to an accuracy of +-10mL. Watch the video below to see our pump in progress.

After lots of testing we were able to get our pump to successfully pump out 1 tablespoon of water consistently. As you can see in the image below there was still some error, but far less than 10mL.

Capacitive Level Sensor

Next on the list was testing out our capacitive level sensor again with our new water tank. We hooked it up the same as before, soldered it to a new prototype board, and uploaded our previous code. This showed that our capacitive level sensor was working as expected and so we began to accurately map an equation to determine the water tank level. We did this experimentally by adding in 1cm worth of water into the tank and recording the value returned by our level sensor. We performed this test 4 times and took the average of the good data. Plotting these results shows us a fairly linear equation, as seen below, which was added to our algorithm to be used to send the user notifications.

We tested out using this equation and it worked relatively well. Or at least provided us with good 10th percentile ranges which is sufficient for our needs.

Light Sensor

We also hit another big milestone this week! We finally got around to testing our light sensor logic. After a few days of thinking up the logic we decided to go with this pseudocode to get our pot to actually move:

Check light sensor values
find maximum light sensor value
if the maximum value > threshold
    if all the light sensor values are similar
        don't move the pot
    if the maximum light is on either of the center sensors
        if the light sensors at the back are also high
            rotate the pot
            move forward
        if the light sensor at the front is also high
            move forward
    if the maximum light is at the back of the pot
        rotate the pot
        move forward
    if the maximum light is at the front of the pot
        move forward
 else
     don't move

We also coded up some logic for telling the robot to stop once it started moving, the pseudocode looked something like this:

check light sensor values
find maximum light sensor value
if the maximum light is in the center and we're above the threshold
    this means we found the highest spot of light
    stop moving

After some testing, we found that it worked really well. Minor adjustments into the threshold values of the light sensor were adjusted, but other than that, we were on our way and happy with the results.

Software

As mentioned before, we began development into our mobile app first by creating our database. We decided to go with Google's free firebase which could be easily integrated into our system using the open source Arduino-Firebase library.