Week 16 - October 24-29

Mechanical/Control module

Soldering of the motor driver began on Sunday along with placing parts on the cart. The code example the motor driver provided for control was attempted to be used but upon wiring some problems occurred on testing. Some reasons for this occurring could be that the code may be written incorrectly, wiring error, or the way soldering was done to it. But with the wires that were used to connect a motor driver to the battery, it was successfully powered on which helps verify the driver can work without being connected directly to the Arduino.

After several attempts at modifying the code, motor control was successfully achieved between the motor drivers powering the motors in the direction the microcontrollers set them to. This verified the theoretical line of communication starting with the app on the phone giving an initial signal wirelessly and having all the appropriate lines send the correct signal within the cart to move a motor at the intended direction. The motor speed needed to be adjusted as initially the first PWM rate did not give it enough torque to rotate. It seems that once a high enough PWM frequency is introduced, the speed can be adjusted and can be set to a rate that is safe to operate with. No significant voltage or current spike or drop was noticed in the first test, but this was with one wheel; it will need to be observed with all 4 wheels to see if their voltage and current demand would affect the circuit. Work on the motor and wheel mounts also needs to be done so that the motion between both the wheels and motor does not shuffle any parts, as this did occur when the motor was turned on.

For this run only forward, backward, and stop were first programmed to verify that manual control could be done, and only one motor was turned but all actions needed were executed by the wheel. Figure 1 shows a video of the wheel turning. What was also verified was that when simulating a drop in charge from the battery, the designed voltmeter was also able to send a correct signal back to the motor-controlling Arduino that would temporarily pause the motor and send a buzz indicator to alert the user of a low battery.

Figure 1: Wheel movement demonstrating manual control and control using the app and all systems to do so.

Power Module

A setback had occurred with the power module that temporarily suspended construction of the cart’s mechanical module with regards to controlling and powering the wheels.

Upon successful movement of a motor turning and controlling polarity via the cart’s app, work on expanding the code to control the other three wheels was done. All the appropriate connections were made between controllers, drivers, and motors as shown in Figure 2 and the polarities for mecanum wheel control was added on the motor controlling code. When the power was turned on, no issues were initially detected with any systems connected and the cart was raised to observe motion of the wheels. However, when the command for the cart to turn all 4 wheels and perform moving forward, three of the motors stalled and only one of the four wheels remained turning. Resetting and verifying all motor, driver, and controller connections was done on several occasions and everything was seen as connected properly. Upon attempting troubleshooting and powering on the system, the wires connected to the battery terminals had overheated and melted through the insulation, causing the terminals to short and began touching each other. No further damage was done through the terminal blocks; however all systems need to be rewired and tested that this cannot occur again.

Figure 2: Placement of components on the cart, not final.

The cause of this was most likely attributed to the wires connected to the battery itself and connecting the terminal blocks to it. They were a smaller gauge than what was needed to handle the current being drawn, and most likely heated when all four motors were turning. The motor drivers were handed over to Victoria to ensure that they have no damage and all connections from soldering and wires are still fine after what happened.

Figure 3: Wires damaged due to overheating.

Once all proper wiring is in place, a demonstration of manual control will be performed and mechanical construction will continue.

Other issues noted when connecting all parts that were tested:

A hotter environment (being outside) negatively affects the IR transceiver, as it was receiving a false reading in all directions, and when tested indoors the error could not be reproduced. It should be adjusted in the system requirements that this will occur if the cart operates outdoors.

The battery was being read at 13.0V at full charge which is not a good charge to use, so some voltage will need to be dropped before connecting to the controllers. One possible solution would be to use the voltage divider made for voltage reading and double it as a way to drop the voltage not just for the controllers (place a potentiometer to decrease source voltage from 13V to 12V) but also for all sensors that require a maximum of 5V to operate without damage. Placement of this circuit needs to be strongly considered for this to work.

Gauge of the wires for the motors are larger than what the holes of the motor drive can allow to pass, so the wires need to be trimmed or resized somehow in order to work with the drivers.

It was also noticed that the motor driver keeps the same settings it was given even after it is powered off; meaning if you turned it off while the “forward” command was being issued the cart will immediately resume that same motion the moment it is turned on. This is not ideal and so a step might need to be placed so that if the cart experiences a drop to 0, the cart will set itself to “stop” or no motor turning. It would also be assumed the cart needs to be stopped before anybody can turn it off so it might not occur.

Sensor Module

Work on sensor conditions that trigger avoidance movement continued throughout the week and will go into the weekend to test the code.