Progress Log
Week 9
July 4th - July 10th 2021
The group finished the proposal presentation and presented to the panel of judges. The project was approved as designed and work on the project will begin on July 12th as planned in the proposed timeline.
June 27th - July 3rd 2021
Week 8
This week was spent finish final edits on the paper. The paper was then submitted by midday on Friday the 2nd of July. By the middle of this week, we began working on the project presentation. A basic outline and plan was made as shown in Figure 8.1 based on previous groups' proposal presentations and our final proposal report.
​
Figure 8.1: Table of Contents for Proposal Presentation
June 20th - June 26th 2021
Week 7
This week the focus was primarily on finishing the proposal Paper in preparation for the due date and presentation. Work was done ensuring relevant material was included in the report, as well as verifying all research to be used was properly cited and referenced. Not much more updates to research of components or project design, most of Red Rover's success requirements, features, and spaces of intended use are for the most part settled and agreed upon by both partners and overseeing Professor.
​
In the last meeting with the professor, it was suggested among various other things to include a brief description of the software to be used to program Red Rover. Research was since conducted to bring a more descriptive explanation of how the logic would be planned to look like and be written. From this, an updated logic flowchart was developed to include a basic idea of how the modules, sensors, and controller would communicate to each other, as well as an initial look at sensor interaction with objects during various object avoidance scenarios. They were updated on the website, but also can be found here. Note that this is not the final expected logic that Red Rover will have in its program, this is just an initial planned outline of how all data transmitting and receiving systems could process information and how each is expected to react.
​
Revised Logic Flowchart
Obstacle Avoidance Procedure
June 13th - June 19th 2021
Week 6
This week, the majority of time spent from both partners was on the project report, highlighting key aspects from the research process to add to the report and continuing finalizing the modules and components necessary. Fixes to the website and diagrams suggested from last week were done, and the next week will consist of continued collaboration on the project proposal report and presentation.
One of the focuses of the week was also to help detail some spaces in which the Red Rover can operate, and to more clearly outline the intended areas to narrow the scope of the project due to foreseen limitations to the Rover's design. To prevent unwanted entrances to spaces such as other worker's offices or rooms, these spaces would be deemed out-of-bounds and be predefined as such an area for the Rover to understand it cannot venture there when tracking or following. Instead, it will wait for the user to either return else it will go to sleep and wait for them to wake the Rover again. If it is trying to return to the user via Bluetooth, Red Rover will treat the bounded area as an obstacle and find a route clear of it on its way to the user. Examples of intended and out-of-bound areas can be seen in the requirement and budgets section of this website.
Week 5
June 6th - June 12th 2021
Victoria’s workplace was visited, and her coworkers provided several recommendations of chassis material type to use to fit the wheels, motors, and electronics to be used. A metal that was lightweight, affordable, and not too expensive was desired, and the 80/20 T-aluminum type was suggested as a good option for the project. 80/20 metals are described on the website 8020.net to “provide T-slot aluminum profiles, or bars, that have channels used to connect other bars and parts — for instance, panels, linear bearings or casters. It is a building system anyone can use to create custom solutions.”[16] They are described as easy to use and construct with and can hold varying weights based on the profile of the intended design.
The example in figure 5.1 of a Channel Drivetrain with Mecanum wheels could be used as a good example of what could be done to fit all that is needed to the cart and mobilize it. Although a smaller scale, this can give an idea of how the motors and wheels could fit onto a drivetrain.
​
Visiting Victoria’s workplace where her coworkers offered information and help relevant to the design and sensor methods was very helpful and in many ways proved to be successful in helping us both move forward in a productive direction, knowing more clearly what hardware would bet fit the scenarios to be expected, and what materials to look for to build a reliable base for motor system and electronics.
​
IR transceiver was ordered along with proximity sensors were ordered to attempt some initial testing and research, will be done once the sensors arrive.
​
Work on the Proposal paper began and was outlined.
Figure 5.1 - Channel Drivetrain, Mecanum upgrade[16]
After research and calculations we found that we would need 1/5 Hp, 4.8 lb/in, and 56.25rpm per motor with one motor driving each wheel. The motor shown in Figure 5.2 more than meets these requirements with specs as follows:
-
1/4 Hp
-
7lb/in
-
2300 RPM @ 7lb/in torque
-
Reversible rotation
Figure 5.2 - Bidirectional Electric Motor
Week 4
May 30th - June 5th 2021
Motor Driver
-
Capable of driving 2 DC motors or 1 Stepper motor
-
5V-12V Operating Voltage
-
2A max current per channel or 4A total
-
Capable of sensing motor output current up to 1.65V/A
-
Current will need to be stepped up for motors that need 25A at max load
HM-10 BLE Module
With a better block diagram to help visually demonstrate the overall operation of the Rover and how each module is connected, research began on sensors and Bluetooth capabilities of the controller. One parameter that was first considered for Bluetooth range-tracking would be the RSSI, or Received Signal Strength indicator. RSSI is “a measurement of the power present in a received radio signal… usually invisible to a user of a receiving device.”[13] RSSI is known to measure a variety wireless networks, in this case, only certain BLE beacon signal strengths will be measured for comparison.
Signal strength, the power output that the transmitter is delivering, is received by a reference antenna and is expressed in dB, or decibel to the receiving signal. This is what is measured and will be translated to distance for the controller to evaluate.
A somewhat similar project that uses the same concept found on Arduino’s Project Hub, created by Team Deodates provided some useful insight on an example of RSSI measuring distance by evaluating the signal strength between two devices and translating it into distance. What they do is receive primarily the Wi-Fi or Bluetooth signals of cellular devices and evaluate the distance of them from the base device by looking at the RSSI each is transmitting to the device and seeing if it is within a safe “socially-distant” range.
Taking a look at the sketch code the project used, the ArduinoBLE and WiFiNINA libraries from the Arduino library catalog were used, and both were written so that whichever method was used, the Arduino would be able to evaluate what RSSI was being delivered from a certain device.
Estimating the distance then required passing the signal value through a specific equation, which will be explained below, but after the final value is calculated, the final distance is compared to the ranges of distance and the user will know if a device falls under a safe range, or if one is too close. The equation introduced above is known here as a Location Estimation Algorithm based on RSSI Vector found in a report published on Sage Journals[14], which utilizes Gaussian fitting and interpolation to estimate the total distance to devices are from each other. With the equation derives from such concepts, the equation was rearranged to solve for distance.
Several details were noted about this project along with others like it. The board used was an Arduino MKR WiFi 1010 which has an on-board Wi-Fi and Bluetooth capabilities attached to it, not needing a Bluetooth device wired for the operation to work as intended. Nevertheless, an Uno R3 with the HM-10 Bluetooth beacon was wired up and tested to see if the same results could occur. With the same libraries connected, and other programs attempted with this wiring setup to test if RSSI reading could be implemented, it was found that the signal strength could not be translated into a readable value with the hardware that was used. The best explanation that could be made for this is that the Bluetooth/Wi-Fi transmitter or receiver needs to be on the board in order to read the RSSI; the beacon will simply just transmit data from one signal to another. Furthermore, the libraries Arduino supplies for Bluetooth RSSI reading only is compatible with specific boards ad cannot be applied to those that would even have Bluetooth Peripheral attached by wiring.
In short, it seems in order for the project to have proper signal strength evaluation in the relevant devices such as the Arduino MKR Wi-Fi 1010 needs to be used, which will also allow the correct Arduino libraries to run as needed. After some group discussion, the Arduino Uno Wi-Fi Rev 3 seemed to satisfy the same requirements.
​
Line following for out-of-bound areas
One factor that kept presenting a problem when looking at navigation scenarios the Rover will encounter is that if the Rover was operating in an office-type environment with cubicles or enclosed offices, how would it differentiate from the user’s proper office and ones it is not intended to enter to? If the user is in one office and calls for the Rover sitting at a distance from them, the Rover could potentially be seen as entering all cubicles or offices in its way before productively moving toward its intended direction. It was initially not seen as a problem, but the scope of the project was seen as an issue when looking at the scenario some more; the Rover would take too long to reach its intended destination, no matter how the Rover was tracking the user and their module.
An approach to this solution is to designate areas that would provide a prolonged path to the user as an “out-of-bound” area where if the Rover were to encounter them, it would treat them as an obstacle and run the same programmed routine for obstacle avoidance accordingly. Only instead of the ultrasound or proximity sensors tripping this routine, line tracking modules placed underneath the rover would detect predesignated lining around the out of bound area and alert the rover it has encountered an obstacle that way.
Once the Rover sees the line, instead of the proximity sensors guiding the Rover around said obstacle, the Rover will follow the line until the end is encountered, which will be intended to meet a wall so that the Rover can maneuver around the wall towards the user. In short, the line will act as a track the rover can use to keep itself away from either rooms that the user may not want the Rover to enter, or areas that could be nonnavigational for the Rover such as an inclined path, a part of the room that is steep, or stairs. This proved to be useful as it helps with multiple dead-end scenarios that the Rover could encounter in a more close-in office setting, but also even in a more open area certain hazards may be present to the Rover that the user may not want for it to encounter, so creating a boundary this way helps the Rover avoid them. The figure below demonstrates a general example of this.
DroneBotWorkshop.com explains its line following example as: “The object of the sensor and the code that drives it is to keep the detected line directly under the middle sensor.”[15] There will be up to three IR sending/receiving pairs that will compare the reflected IR signals they each are transmitting, and based on if one side or the other detects one they will send the data back to the controller, and keep the robot or whatever moving device on said tracked line. On the module, there is a potentiometer for increasing and decreasing sensitivity of the reflected light, and this might be helpful if the Rover is to operate as intended in different floor types.
The idea seems to be the one of the less distracting alternatives to this problem as the black tape would not be dramatic color to have on the ground, and it is rarely seen a black floor or carpet in professional areas, so the black tape should be relatively easy for the Rover to detect. Testing will be conducted once line tracking modules are acquired to test the sensitivity and accuracy of the sensors.
​
Between the future testing of the line tracking and other sensors, a test robot was requested and donated to help get an idea of the capabilities of various sensors and modules, such as the Bluetooth beacon and ultrasonic sensor and comes with IR functionality.
Week 3
May 23rd - May 29th 2021
​
Measurements of the cart for initial design were taken and research of its weight and other parameters were conducted. The exact cart brand and type were not found, but from other websites that sold the same model and type (steel mesh) helped provide details about the cart and its capabilities. Including information taken from Uline.com[11] wire products section, cart measurements are as follows:
​
Physical Dimensions:
-
Length: Approx. 35.5"
-
Width: 18”, 17.5 between bars
-
Heights: Total 39”
-
Bottom shelf 8” from ground
-
Top shelf 25” from ground
-
Shelf Thickness: 1.125"
-
Bar thickness: 1”
-
Wheel height: 3.5”
-
​
​
​
​
​
​
​
​
​
​
​
​​​​​
​
​
​
After evaluating all measurements that were found, it was decided that with either this cart or another with similar specifications that the goal total allowable weight Red Rover shall have will be 200lbs. Broken down the weights totaling this each come from:
​
-
50lb – Cart
-
100lb – Maximum allowable load
-
30-50 lb. – Electronics such as sensors, motors, circuitry
​
The Rover shall be able to move a combined net weight of 200 lb. with motors attached to the base of the cart as part of a chassis and will drive with the measured load at 3-4mph.
The Rover shall be able to operate with full load and all possible operation for 3 to four hours in between charges.
Weight Values:
-
Estimate weight: 50 lbs.
-
Max weight per shelf: 800 lbs. ​
Then general idea of operation is for the rover to have an initial goal of always wanting to head in the vicinity of the user beacon. When encountering obstacles, the Rover will activate a combination of sensors that will help it avoid collision and successfully maneuver around said object, and when cleared conditions have been met, the Rover will correct itself and reverse any turns it has made to return back to its intended path.
Some issues were noticed during a walkthrough of several scenarios such as some sensors not being accurate enough in real world obstacles, and when considering how the Rover will react to a sudden loss of the user's signal while following. Solutions to the problem will be found in the next week.
Week 2
May 16th - May 22th 2021
We met with our advisor to present our ideas. M.A.P.S was denied, Smart Gnome was deemed possible as long as some changes were made to make it different from other projects in the past. SafeSeat was more unique due to its method of cooling. If chosen we would need to add more alert functions in order to surpass a previous project. The most likely idea was the Rove Station. The proposed idea was good of itself as long as we were able to find a way to make the cart follow a signal while navigating a room.
​
After discussing, we decided to follow the path of the Rove station which has been renamed the Red Rover.
​
Found potential Uline utility cart to be used as base of project:
Possible Approaches to the problem of device tracking and following operation
​
-
Bluetooth tracking distance and position​
Update: May 20, 21
One possible method would be to have a Bluetooth-powered system that would be able to help the Cart and tracking device to communicate each other’s distance via Bluetooth signal strength, and help the cart achieve the targeted distance by continuing to follow the signal until a certain signal strength is reached. Cart will remain still as long as there is a minimum strength maintained and will begin searching/ following once the signal becomes weaker.
​
Update: May 21, 21
Several more methods were researched on how Bluetooth tracking would work with measuring distance through signal strength. An app called LightBlueTM Uses Bluetooth to measure the signal strength and its initial use is to help find Bluetooth-enabled accessories such as headphones, Tile on keys, and so on. The Bluetooth could work with IR or RF following sensors so that once the cart is in range, the cart will simply follow in close proximity to keep a target distance.
​
Update: May 25, 2021
From the app description, developer Punch Through Design Tools states that the app has “Full support of read, write, and notify is included to ease BLE firmware development efforts. You can also view the signal strength (RSSI) in real time to get an idea of how close you are to the BLE device, handy for finding lost Fitbits or other BLE devices!”[9] This app could possibly be the start of how Bluetooth technology can be implemented to track distance and possibly trigger certain tracking procedures.
​​​​
2. Lighthouse tracking system
​
A room-scale tracking space for VR headset found in the HTC Vive that uses area-sweeping lasers.
​
Analysis of Valve's 'Lighthouse' Tracking System Reveals Accuracy – Road to VR
​
​
Week 1
May 9th - May 15th 2021
We discussed possible projects ideas. These Ideas include an automatic agriculture maintenance system, an autonomous work station, a smart car seat, an automatic adjustable layout system, an RC drone for medicine delivery, and a automatic temperature and occupancy counting system. After deliberation we decided to present the first four ideas to the advisor.
Once the ideas were picked, we conducted research into similar products that exist. We also built block diagrams and wrote out proposals for each idea. The website was formatted and populated with the proposed ideas and then published.