Week 12 - September 26 - October 2

Sensor Module

In preparation for the construction of the cart’s mechanical module and sensor mounting, sensor verification and code implementation was continued for the ultrasonic and IR proximity sensors. The proximity sensor pins were all soldered on and tested for their distance and range capabilities. Directly in front of them it could be around 2ft of detectable range, and a foot or little less on the sides. When designed to work with a code, the sensors could light an LED when an object or movement was detected. Due to the size of the cart, there may need to be an additional IR sensor in the middle of the cart to help avoid further contact in the event that an object or person is in the direct center of the side of the cart and both IR sensors on that side cannot pick it up in time. Placement of the sensors should also be considered if it is to react to as many scenarios as it can. Possibly in the middle of the cart’s height between its top shelf and the ground, along with the ultrasonic sensors, as this would cover both lower objects and people walking around the cart.

Also, working with the proximity sensors will be done a bit more carefully as one of the Proximity sensors was damaged upon testing and possibly due to wiring error. A better video demonstrating the proximity sensor reacting to detecting movement in its range can be seen below.

Figure 1 - IR proximity sensor triggering a red LED when an object is detected in its range.

Upon adding code to the program that will allow sensors to detect obstacles and pause movement to avoid collision, a couple of errors occurred during compiling and execution of the program. Primarily, when first putting calls to specific commands, the program froze and would disconnect from the app after a few seconds. It is unclear as to why this was happening, as several features were added in the same way that this feature was, so it was difficult to pinpoint the cause of the program crashing. After having a small group meeting Monday, it was considered maybe having a function call while the app is running multiple loops could be the issue, but even then there are several other modules running in the background while the CALL function is being activated, but regardless an attempt to have the sensor readings called and compared in a different section of the code, or where the RSSI is being compared. This seemed to at least allow the SR04 ultrasonic sensor’s data to be pulled and compared, but now it is a matter of reaction time for the code as the delays that would represent the coding would stall the sensor from acting on an object, which is not the ideal case. The sensor is set to check distance every time an RSSI reading is taken, so it is fine during that scenario. But the turning portion to adjust its path needs to be reconsidered.

A loop was created that would run a count of how long to turn the cart to test a new path of it getting hot or cold, while also scanning for obstacles with sensors. This way, at any moment the sensor detects an object, the cart will perform a new subroutine called obstacle_avoidance() until the sensors are cleared. Once done, the cart will continue new path testing and see if the signal has increased or decreased.

As of now, the board does take inputs from the transceiver’s readings, but not giving the appropriate direction to turn. Troubleshooting will be done to determine whether the cause is due to the code’s logic or the way the wiring is set up. Work will continue into the weekend to verify the proper path can be taken when the IR transceivers communicate location to one another.

Power module

Purchased toggle switch and parts to begin connecting electronics to terminal blocks and then to battery.