We started as a team of three students who were tasked with building an interactive object that utilize one sensor for phase one, and we had to add another sensor to it in phase two. When the strike happened it was a blessing in disguise as the materials we ordered online took a good 30 days to arrive. That's not to say the project went smoothly afterward as various issues arrived. Here is how we overcame them.
We wanted to build a self-perpetuating wheels, the wheels would be 3D printed and we could carve an empty space inside the wheels to house the electronics. There would be 3 different methods of activation. However after figuring out the limitation of 3D printed parts, we decided not to follow with this concept. There would not be enough space inside as the biggest size for the parts we could print out is 4 inches, even if we made them into 4 parts of 4 inch, the motors will destroy the wiring while they're moving if kept in such close proximity
Here I bought a 2 Wheel motor shield but uses 4 wheels instead. It was initially to lessen the burden on my wallet, however that decision backfired as we encountered later problem that took us a long time to find a workaround. For now, all you need to know is that the red board is connected to two motors on each side, which treat them as one motor.
The motors refuse to move despite everything seems fine
The motors refuse to move in the correct polarity
I checked the code for the L298 driver, mixed up the IN signals (the signal that order each side to go forward or backward) yet the same problem persists. The assembly of the motors were correct as shown in instruction and motor shield schematic so I had no idea what could cause it.
The problem did not pose a threat to the final goal of the design initially, as I assumed it simply steer the wheels whenever the robot moves. Until I discover later on that since the wheels aren’t rolling in the right polarity, when the robot encounters an object, it actually steps forward instead of backward because that’s where the wheels take it to as it tries to move backward.
digitalWrite(in1, LOW);//default high
digitalWrite(in2, HIGH);//default low
digitalWrite(in1, HIGH);//default low
digitalWrite(in2, LOW);//default high
This makes the bot goes forward AND back off at objects, the only flaw is that it runs in circle instead of forward.
Problem 3: The robot struggle to run on solid ground.
After the final assembly of the cap and the ultrasonic sensor (a sensor that perceive sounds as numbers which it sends back to the arduino to perform its logic), I let it run on the ground and the robot could only nudge ahead, as if out of battery. However, when lifted in the air or held on my hand, the wheels could turn with full throttle. This suggested 6 things:
Proceed with 3
Proceed with 2, also professor advised that I must not wire the ultra sonic sensor and the motor shield directly to the battery, as it would have burned the board, not just drain the battery.
Problem 4: The library doesn’t seem to apply / Ultrasonic sensor is dead
The VCC wire is currently connected to 3.3V port instead of 5V which is being occupied by the shield driver 5V wire. The ultrasonic sensor wasn't working at the moment.
Proceed with 4, also 5 was debunked as when tested the ultrasonic sensor on a demo code, Serial Monitor still caught activity so it didn't burn out. Library applied itself after I closed and reopened Arduino program.
Ultrasonic sensor was situated too high, won’t be able to see lower object
Our priority was to fix wheel polarity but phase 2 is near, so we made phase 2 into fixing the polarity instead, which would improve the bot's maneuverability.
We had a Light Dependent Resistor (LDR) we wanted to use for a light control wheel robot. However it turns out we needed a relay (a switch that allow small current to turn on big current, such as street lamps) as well to turn off the Arduino itself, which we didn’t have one on us. Despite the fact, I don’t see why we couldn't disable motorA and motorB with what’s basically a resistor that can go as high as a few megaOhm when there’s no light.
Idea 2: Adding a 2nd ultrasonic sensor at the back to fix the polarity problem
We were thinking of compensating for the fact that the old code would often make the bot bump into things when it back off. I personally wanted to learn how to get two if statements of similar module working as well, so we went with this idea.
I ran out of M-F jumpers and there is no time to buy more
I learned how to turn a M-M jumper into a F-M jumper, by opening the wedge that kept the metal inside so it slides out. I could then clip the pin which opens a hole for any wire to connect. They were used to extend the wires far enough to reach the back of the robot, where the 2nd ultrasonic sensor situated.
There weren't enough 5v slots for a 2nd sensor
I had to perform wire grafting onto the main 5 volt line, as you can see the grey wire in the pic. This operation required a very strong grip strength while adjusting enough force as to flay rubber off the middle part of the wire, without accidentally cutting it clean. Then the soldering process had to be precise and quick or the solder could melt other parts nearby, all while trying not to burn your finger due to how close you have to hold the wire in place. It was an arduous process.
Since inch<4 and inch = sonar.ping_in(), I assumed it works the other way around, so I changed the if statement to as shown. I changed the < 4 into < 10 to give the bot a wider berth when moving. I learned how to nest multiple if variables, as the result.
The result is that this 2nd supersonic sensor allowed the bot to turn 180 and moved away, not just going backward, as shown above