Week 7: Firmware F R E N Z Y

The start of this week was a bit slow as most of us were wrapping up our midterms, followed by reading week. However, we did manage to make some time by coming back to Waterloo a tad bit earlier to work on our Plant Buddy prototype. Let's see what we did!

Mechanical

Most of our mechanical assembly was done at this point, except for our water tank. As mentioned before, we've been having a lot of issues successfully waterproofing our tank and decided to test out silicon sealant, the type of stuff you find in bathroom showers and sinks. With the help of Jess' dad who was able to deliver us some silicon sealant we attempted to seal our water tank. Fortunately, we had 2 different water tanks we had used in the past to test out the silicon sealant before actually putting it on our finalized tank design. After an hour of trying to push the silicon out of the tube and onto our tank we got it completely coated. We waited until the next day to test it (as the silicon required 4-6 hours to dry) and discovered that while it still leaked, it was much better than our design with hot glue. The places it actually leaked was areas where we did not lather on as much silicon, and the interlocking bits that were removed in the new design. The video below shows us testing the water tank, notice how it doesn't leak as much as before:

And so, we decided that this was sufficient and we decided to coat our new tank with the silicon. To do this, we squeezed a bunch of silicon along the edges of the 3D printed part, then placed our acrylic on top, squeezing out as much additional silicon as possible. Once we had done so, we took a wooden chopstick and scraped any excess off that made the tank look ugly, and let it set over night. We were also careful to keep an exposed part of acrylic to ensure our level sensor could still operate as tested. Below you can see a side by side of our old tank coated in silicon beside our new tank. Notice how the new design doesn't have the interlocking bits which was a lot easier to seal.

Unfortunately, testing the new water tank proved to be unsuccessful. While the silicon sealant helped prevent major leaks we ran into 2 issues. The first was with the 3D printed part of the tank. We found that even though we prevented leaks from the sides, gaps between the filament of the 3D printed tank caused leakage at the bottom. This showed us that a new method would still need to be determined for our tank. Another issue we ran into was with the silicon sealant. We discovered that after a couple of minutes, more leakage would appear in the tank at the sides which were supposedly sealed with the sealant. The reason behind this? Because the sealant was constantly coming in contact with the water, which prevented the sealant from being perfectly dry and returning it to its sticky-pasty-leaky state. What were we going to do 😭. Watch the video below for the sad results of our 3rd tank test:

Electrical

In terms of electrical, we got around to doing some much needed soldering for our little guy. We soldered up all our IR sensors, light sensors, the battery cable and even did some through-hole soldering for our two wheel motors and our H-bridge. We decided to put this on a mini proto-board because we finished our initial testing a couple weeks ago with great success, and the jumper cable-breadboard-arduino combo really wasn't working for us (waaaay too many flyaway wires that kept coming undone when we were testing). After a couple of hours, testing with the multimeter, and plenty of testing with our new technique "the pull test" (where we just try and pull our wires away to see if the connection is strong enough) we were done!

P.S. pro-tip we discovered was you can actually use copper tape as make-shift wick so kudos to us for being so resourceful.

With most of our sensors now properly soldered, we were able to start some basic wiring into our pot starting with the motors and the IR sensors. This was our main focus for this week as we really wanted to get our edge-detection software perfected before working on obstacle detection and the other sensors.

While wiring, we did encounter a couple of issues. We found that we had a TON of wires in and around our pot and it was making it super difficult to properly place our sensors in, as well as keep the wires connected to our Arduino. In the future, we'd definitely try to adjust our chassis in terms of taking it apart for easier assembly if possible. We're also thinking about finalizing the placements of components on our other protoboards and hoping to get those soldered to avoid the issues of wires popping-out. Hopefully this will make it easier when testing, but as you can see from the image below there's a big bird's nest of wires in the way. Another big concern we have is if the wires get caught on our wheels, we tried to keep all our wires away from the wheels and are hoping to tie or fasten wires down to the sides of the chassis to ensure they don't get caught.

Firmware

In terms of firmware it was a big week for us! We started by testing out the new IR sensors we ordered with some basic tests on our mini-bread board and discovered that it was working really well. The new sensors came with a built in chip that allowed us to simply read a digital value indicating whether or not an edge was detected (1) or not (0). We were also able to adjust whether our robot could detect edges up to 10cm with the use of a built-in potentiometer on the board. However, we discovered that this wasn't really necessary for our application as we only needed to detect if there was an edge less than 1cm away. Furthermore, the new IR boards were equipped with some (rather bright) LEDs that would turn off if an edge was detected. This would definitely help with debugging as we wouldn't be able to access our serial monitor on the laptop while running the robot from our 12V battery.

Once we got the IR sensors working on our test set-up, we integrated it into our FSM and were ready to test it with the rest of the system. We have 3 pairs of IR sensors; at the front of the robot, in front of the left wheel, and in front of the right wheel. These will aid us in detecting where exactly the edge is. We decided on only have them at the front of the robot as our robot primarily moves forward, meaning IR sensors behind the wheels would provide us with no new information, be additional weight, and increase our cost. Next, after a bit of struggling to place the sensors into the rest of the chassis we finally got them down, but not secured tightly. This created a bunch of issues for us because the placement of the sensors is integral in accurately detected an edge on time. This placement would need to be finalized and properly secured when we demo-ed our project. However, for our initial integration our make-shift securing with electrical tape was sufficient enough in detecting edges. The video below shows us simply testing our three IR sensors without the motors attached.

After testing out the IR sensors we got to testing out the motors on the ground with our H-bridge protoboard. We needed to do some additional tweaks to ensure the wheels would rotate in the correct directions, but after that we had ourselves a moving pot!! Look at it goooooo. As you can see the robot drifts a bit because the left motor seemed to be a bit faster than the right, so this was modified in the code by setting the motors to different speeds.

With these tests working out well we decided to add in our logic for edge detection. We decided on the following basic logic:

if front edge detected
    move backwards
    turn left
    move forwards
if left edge detected
    move backwards
    turn right
    move forwards
if right edge detected
    move backwards
    turn left
    move forwards

After some testing, we discovered that this wasn't working out too well and got ourselves stuck in a corner. This would happen when our front IR sensor detected an edge, causing us to turn left, followed by the left IR sensor detecting an edge, causing us to turn right. This cycle of turn left, turn right, turn left, turn right would never end and we'd be stuck. Because of this we modified our code a bit to be more like this:

if front edge detected or left edge detected or right edge detected
    move backwards
    turn right
    move forwards

Code wise this was a lot easier to implement, and it also removed the edge case where we'd get stuck in a corner so that was great! Once we finalized our logic we moved onto small adjustments to make sure the robot was moving at a reasonable speed to accurately detect the edges. We found that setting the speed to be maximum was quite fast, leading to a large latency in terms of when the edge was detected, and when our robot would move backwards. This meant that there were times where our robot would drive forward, detect an edge, continue to drive forward, fall off, then move the wheels backwards. Through rigorous testing we found that this ended up happening maybe 1/10th of the time which was way too risky for our system. To slow our robot down we decided to change the speed from max speed to 50% of 75% speed. However, we found that these speeds caused our wheel motors to stall. This meant that our motors were trying to rotate, but it wouldn't. This happens when our load torque is larger than the motor shaft torque, or our motor is trying to draw the maximum current but our motor doesn't have enough and can't rotate. We discovered this was happening because of a loud humming noise that could be heard from the motors. And so a new technique was investigated to perfect our edge detection. Watch the video below for our exciting progress on edge detection!

Other