Week 17 October 31-November 6

Power/Mechanical module

Over the weekend, the motor drivers had some trouble shooting tests performed on them to check and see if they were still operational following the setback that occurred last Monday. All ways to try and replicate the correct motors turning based on user command, but nothing was responding as expected between the motors, motor drivers, and control module. The next step was to trace the communication and signals by simulating the wheels responding to controller command via LED’s as done previously, only this time each LED represented a wheel, with an on, or HIGH representing forward wheel direction and off or LOW representing backward, and a red LED to represent stop, or when current through the motor would be stopped. When this was done, the wires connecting to the respective data ports of the motor driver worked as expected, so it was not an issue of wrong coding or signal being misinterpreted. This test board is shown in Figure 1.

Figure 1: Test board with LEDs connected to the same wires motor drivers were connected to.

What helped finally realize the cause was when the motor connections were swapped between motor drivers, as well as data pins after, and the same reaction persisted that occurred when the setback happened. This indicated that the motor drivers were unfortunately affected when the battery terminals were shorted, and thus no longer usable for this project. Control module and sensors were not affected when this occurred as they were powered through another source and not the battery.

In lieu of work on manual control tuning and autonomous program verification, it was decided to begin fixing this issue by purchasing a new set of motor drivers and replacing the damaged ones. In the meantime, however, the group would focus on other aspects that pertain to the overall control of the cart either in manual or auto operation. This includes finalizing and begin installing how all hardware would be wired for power and data transmission, as well as where the respective sources would come from to not only supply the right power but also to help keep sources separate so that no damage would be done on small electronics if a short were to occur again. Figure 2 shows a general idea of how the power terminal blocks will be placed on the board and what will be going where.

Figure 2: Power module tentative layout

On the plexiglass, there are four terminal boards, one breadboard, and the two motor drivers. The two larger terminal blocks will hold the positive and negative strips to connect both the motor drivers power source and the control module’s two Arduinos. The Arduinos will not be experiencing the same power input as the drivers, however, as their strip is not connected to the driver’s, and instead another wire from the battery’s positive and negative terminal will pass through the voltage divider with potentiometer at the beginning. What this potentiometer will do is adjust the battery’s voltage so that its output will always remain at below 12V. This output will be looped back out to the Arduino’s terminal block strip so that they can have a safe 12V or less to operate in. Voltage divider will still also be used to help observe battery voltage. The smaller two terminal blocks will be connected to the Primary Arduino’s 5V source voltage, which is what all sensors will require. This ensures all smaller electronics are completely isolated from the power wiring the motor drivers will be using and powered at a safe voltage. If another overheating scenario should occur again due to the high current demand from all motors and drivers, only their wiring and/or hardware should be affected and leave the rest of the circuit alone.

With this being done and gradual work on wiring throughout the week, we are hoping that by the time the drivers do arrive and are soldered properly that they can be connected to the motors and perform the manual operation as was intended last week.

Update: The motor drivers have arrived and once they are soldered, tested, and connected a video showing manual control of all 4 motors will be added to this progress log.

Software Module

Again, as the motor drivers are being delivered and prepared to connect, other aspects of the cart were worked on. This included continuing work on the code and the obstacle detection and avoidance procedures. All sensors have been initialized and added to the Primary controller’s program to allow each pin to digitally read the inputs the sensors will be providing. It was tested in the last few weeks obstacle avoidance when just two sensors were connected. The code, at that time, did respond appropriately when a specific scenario was introduced to the sensors, meaning when one or the other or both had an object in front it would output one movement type, and the expected reaction was seen in the code when running via its Serial Monitor. The final code will have 9 sensors to it, and as of right now it is being considered as many scenarios, or combination of HIGHs and LOWs, from the sensors as possible to have the cart react appropriately when presented with obstacles.