Four eyes are better than two

 


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.

Initial concepts

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

Idea 2

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.

Problem 1

‍The motors refuse to move despite everything seems fine

Solution:

Problem 2

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.

Hypothesis:

  1. Focus on fixing the polarity so the bot moves in a straight line at all time
  2. Mix up the code until the bot moves in a way that doesn’t go against the sensor, which is the main function. (went with 2)

void motorAForward()

{

digitalWrite(in1, LOW);//default high

digitalWrite(in2, HIGH);//default low

}

void motorABackward()

{

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:

  1. The cap placed on top of the robot was too heavy, it needed to go away (tested, wasn’t the cap’s fault)
  2. The contradicting polarity of the wheels is what causing it to stand in one place, therefore back motors needed to be swapped and the wheels switch side. However that would go against the schematics and the motor wires weren’t cut long enough to reach the output ports of the motor driver if they were flipped outside 
  3. The 9v battery went down to 8v, unable to support all motors which each consumes 3v.

Proceed with 3

  1. Buy new 9v, which now have to support an additional ultrasonic sensor, immediately plummets down to 8v after mere 3 minutes. Battery got heated up.
  2. order 8x AA holder and use that in place of the 9v for longevity

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.

  1. We could try grafting the VCC wire on the 5V wire so they both go into the arduino’s 5V port. (tested, no power going into the sensor)
  2. The code is missing some items
  3. Connecting the pin through the 10k resistor to the TRIG input pin (tested, no power in sensor)
  4. There is not enough juice to power both the sensor and the motors
  5. Need new one or replace with photoelectric sensor

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. 

Problem 5:

Ultrasonic sensor was situated too high, won’t be able to see lower object

Solution:

‍I turned it upside-down

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.

Phase 2

Idea 1: Add a Photoresistor as a global switch

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.

It did not work

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.

Problem 1

I ran out of M-F jumpers and there is no time to buy more

Solution

 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.

Problem 2

There weren't enough 5v slots for a 2nd sensor

Solution

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.

Going back to the polarity problem

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.

Sonar 2: if encountered object within 10 inch, go backward, then turn right

The result is that this 2nd supersonic sensor allowed the bot to turn 180 and moved away, not just going backward, as shown above

Similar project

Contact Me

Address: 1456 Whiteoak Blvd, ON
Email: vutal@sheridanc.ca
docthoi@yahoo.com
Phone: (905)-399-9845