Weeks 1-7 July 11 - Aug 28

After a brief hiatus following the Design proposal presentation, the group began working on some initial design planning for the hardware and starting a template for the code that would help organize all work moving forward. Two “soft” goals were set to be worked on in between semesters in addition to following the Timeline:

1. To begin work on the mechanical aspects of the Rover which includes purchasing and building the frame, motor and wheels as well as decreasing the weight of the cart, and

2. Begin the code the Rover will operate from so that at least the Control module can communicate with a user’s phone and read the signal strength.

Beginning work on these two goals helps set less focus on the beginning phases of designing the Rover’s hardware and software aspects and allows more time to work on the more complex aspects in the fall, which will include the Sensor module communicating with the Control boards for proper obstacle avoidance.

A summary of the work done is detailed below, as work was done periodically throughout this time and not continuously throughout each week.

Work began by researching how the Power Module will be connected not only to the Rover’s control and mechanical modules for power supply, but also how the battery could be charged via wall outlet when on low power. This was recommended by the Judge Panel during the Senior Design Proposal and the group has decided to move forward with implementing this suggestion as it is important for accessible operation for a user of this product. Electronics surplus store Skycraft was visited in search of an initial solution along with some possible options for the mechanical module such as motors and frame construction, but unfortunately not much came out of the search other than supplies for the electronics and some components such as a potentiometer to control voltage being sent to the board and smaller sensors. One possible solution for charging power is to include in the Rover’s Power Module is a 12V Battery Charger/ maintainer which will be connected to the terminals and ready to be connected to the wall in the event low battery is detected. The charger consists of a Battery regulator that helps prevent overcharge, and the regulator has a wall plug that will allow it to charge the battery over a period of time. The charger has a maintainer LED that will indicate when the charge is complete, and can be attached to the side of the rover to help keep it accessible.

12V Battery Charger

Several parts were purchased upon completing the Senior Design proposal, mainly parts that were limited stock. As the parts were purchased, they were tested to see that they function correctly and that they would perform the actions needed for the project. Sensors such as the Ultrasonic sensors, IR proximity sensors and the IR transceiver were purchased and received throughout these few weeks, but the Arduino Uno Wi-Fi board with Bluetooth capabilities and a 12V battery were purchased immediately to begin testing that they would work as intended. The Uno board was required as soon as possible because the group wanted to verify its Bluetooth capabilities and ensure that wireless connection can be established between one’s phone, while also allowing data to transmit through this connection. Purchasing the battery early was done to not only secure the size of one needed in terms of Voltage and power, but also to verify the weight and physical dimensions would work for what we needed. The battery was weighed and overall was suited for its purpose, connection and powering of modules will be performed during the design portion.

Several parts were purchased upon completing the Senior Design proposal, mainly parts that were limited stock. As the parts were purchased, they were tested to see that they function correctly and that they would perform the actins needed for the project. Sensors such as the Ultrasonic sensors, IR proximity sensors and the IR transceiver were purchased and received throughout these few weeks, but the Arduino Uno Wi-Fi board with Bluetooth capabilities and a 12V battery were purchased immediately to begin testing that they would work as intended. The Uno board was required as soon as possible because the group wanted to verify its Bluetooth capabilities and ensure that wireless connection can be established between one’s phone, while also allowing data to transmit through this connection. Purchasing the battery early was done to not only secure the size of one needed in terms of Voltage and power, but also to verify the weight and physical dimensions would work for what we needed. The battery was weighed and overall was suited for its purpose, connection and powering of modules will be performed during the design portion.

Verification of the Uno Wi-Fi board’s Bluetooth capabilities was done periodically throughout the weeks preceding the next semester, which began by comparing how the BLE module connected to other devices to a Bluetooth module “beacon” that was acquired previously. Several libraries and programs found on Arduino’s Project Hub were used to test which were compatible with the hardware and open up its serial port for Bluetooth receiving and transmitting data. Again, testing certain calls to functions on both a board with Wi-Fi / BLE (Bluetooth Low Energy) and a BLE Beacon device does not produce the same results; the BLE beacon device only can send and receive data but cannot provide information about the signal strength or device information of something connected to it, while the Uno Board can execute all the functions mentioned. The Bluetooth beacon is, however, more reliable as far as connection strength and consistency goes, but since it cannot provide signal strength, this further verified the need for an Arduino Uno with on-board Bluetooth.

Testing all Bluetooth possibilities how to take values from a phone using LightBlue Bluetooth app.

After confirming the Arduino can differentiate the values given from the App, RSSI (Received Signal Strength Indicator) was next tested to see if it can tell the strength of a connected device which can be used to determine distance. Various methods were attempted such as taking an average of every “x” amount of values and the filter researched during Design Proposal but nothing was as accurate or consistently stable as need when testing the filtering types during this week. The figure shown provides how the RSSI is received and is not as accurate as needed.

Unfiltered RSSI Signal

What did provide a possible solution was a Kalman Filter that was seen on Arduino’s website. The filter had a set amount of values for gain and used statistical theory to help predict where the next value given should be based on the values provided before. The figure shown provides an example of how the filter helps clean up the signal to give a more stable read of the signal strength, what was needed to be modified for the use of this project was the rate at which a signal was given to the filter so that it would be more accommodating to our needs. Giving an RSSI signal at 500ms (every half-second) provided at this time to be the best possible result for determining distances between devices through signal strength.

Original Signal with Kalman Filter Applied

LightBlue did not allow for creating apps, only send/receive values, so MIT app inventor was first found as a way to create an app that would connect to the Uno board and provide information to it. MIT app inventor is a free application developing software described on their website as an “intuitive, visual programming environment that allows everyone to build fully functional apps for Android and iOS smartphones and tablets.” Some of their online tutorials gave insight on some of the Bluetooth functionalities the app inventor has and a draft of the app was developed that will continue to be built upon.

Finding out how many pins were needed for the project and how many pins the Uno board had introduced a roadblock in module design, so a possible solution was formed which involved another Arduino Uno board, this one with no Bluetooth involved, just one that would help take some of the pins from the Uno Wi-Fi and free up the pins for other uses.

Red Rover App v.1

Several methods were used to establish communication between the two boards such as serial or Primary-to-Secondary communication, but ultimately what was found to be a less complex solution for what was needed was having three digital pins connected to three other digital pins that would send a combination of High and Low’s to signify a Binary value (000, 001, etc.) what the Main Uno board will tell the other Uno board via this digital binary signal is an instruction that was first given to the Uno Wi-Fi board from the user via app, and the binary signal will signify a direction that the Rover will take, either front, left, back, etc. The pin-out diagram shown below displays an initial layout of how this will be implemented. So in short, the Design of the way the Mechanical and Control module would communicate was expanded with another Arduino Uno in between the main Uno and the Motor drivers, which “bridge” the signals and thus will have one Control board tell the other control board which direction the Rover needs to take, while the latter controller will provide signal to the drivers which wheels to move in what direction. Physical design is shown above.

Mechanical and Sensor Module Pin-out