Was able to iron out the bugs with a little bit of brain storming and idea bouncing with the professors.
Decided to use a hashmap to store the adjacent beacons to the previous beacon in the graph, which allows me to determine if
we are actually getting closer to the "closest beacon" or if we are currently just transitioning from one beacon's range to the other.
This thought process works flawlessly, requiring me to do a little bit of testing to see what the tolerance was when getting closer
to a beacon (tolerance as in how much the estimated distance would change over the course of time).
Below is one of the many tests I did which includes me completely turning back to test the re-routing and turn-around capabilities/logic.
I'm pretty satisfied with the outcome.
April 22nd 2022
As the presentation is coming up, have made some finishing touches including
adding a nice looking "graph" GUI to allow the user to see all the beacons.
Everything is programatically done other than the x / y relative coordinates of each beacon.
Still have some slight issues with beacon latency, as well as beacons being sporadic and flipping between each other.
This I believe is hardware related though and logically there might not be a way to get around this.
Here is a working demo of the app, not every run goes as smoothly as this.
As you can see, at the intersection beacon, I had to pause for a second until the phone finally registered the beacon.
As mentioned before, I believe this may be a hardware issue and not sure if theres anyway around this.
April 21st 2022
I have finished routing, have a pretty nice working example
with a simple right turn. Will need to start working on edge
cases and cases where individuals are not following directions well. Running into latency problems in close ranges,
shouldn't be an issue when beacons are more spread out and I am able to make the "I'm here" buffer larger.
Will also need to decide on how I will be handling locations...
I have a database column for this, however have not implmented anything for saying
"this beacon is close to these rooms... [list of rooms]"
April 7th 2022
Updates to Routing
Have somewhat completed the routing portion of this project, having issues with the beginning of the UI
Since I pull down from a database at the beginning,
and the main thread is unable to to networking, I'm unsure on the correct method to this.
After looking at documention on this, there are multiple methods but most of them are depricated.
After brainstorming session in class, it was decided to take the approach of only directing the
user once they get within a certain range of a beacon, correct path or not. Once they get off-track, telling them to turn around and then if they go past a second beacon, re-routing them.
Just adding the runnable "runOnUiThread" seems promising, will need to look into it.
March 20th 2022
I've begun working on the logic for routing the users.
Will have to include a cache like system that will hold on
to distances to compare to the next "scan's" distances.
Thankfully Java includes this class pretty easily.
The design is proving harder than I anticipated,
since there are a fair amount of different ways to go about how to compare distances etc...
I think I'll have a working "demo" in about a week if I continue working at it.
Created a branch to save what I have currently,
which displays all the beacons and their current distances.
Should allow testing to be easier if I have capabilities to "debug" an area with that
app compared to trying to use the directions version.
March 7th 2022
I am now able to see the MAC Addresses listed with the distance on each beacon.
I'm currently scanning every 1.1s, which poses some challenges considering I will only be receiving user
distance every second. Speeding up the scan, resulted in sometimes dropping the
amount of beacons to 1-2 less than whats in the area.
I have also somewhat nailed down what the database should look like:
I'm not completely sold on the location structure, something that I will revist once implementing "routing".
February 19th 2022
Testing with Beacons
After testing with the project, found that the Beacon UUID is
used for scanning which beacons we want to connect to.
If I instead use the Beacon MAC address, I am able to refer to each one individually like I intended.
So far, I have an app that will start to scan for and print out in the
log the distance between it and all the beacons that are currently connected to the phone.
I intend to try to get a working demo with the 5 beacons I have as of now done soon,
need to complete the logic that will allow a user to connect to the nearest beacon,
and basically ask to go to another beacon for the time being.
Also learned through testing that the beacons severely interfere with each other,
messing with the approximate distance. Will need to decide on how far from each other these beacons need to be.
February 8th 2022
Decided on a structure for the JSON for adjacent beacons:
So on so forth. These will go clockwise and allow me to route a user correctly based on desired location.
I now have a working test app that allows for
requesting permissions on startup as well as retrieving and storing the beacons in a JSON object format.
I also setup a github repository to help with version control.
February 7th 2022
Changing the requirements
After researching things,
I realized that most of this would already be done for me...
Not much to figure out, after meeting a few times, we came
to the conclusion that we could add guidance functionality to the app using the Bluetooth beacons
Created the database I will be using, the schema is:
1. BEACON_UUID : VARCHAR(20)
2. BEACON_LOCATION : JSON
3. BEACON_ADJACENT : JSON
I decided to use JSON for these two columns since creating new tables would add no performance benefits, and simply complicate retrieving data.
I was also able to establish a connection to the database on the test app I have been working on. Able to connect and query rows etc.