You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
99 lines
4.0 KiB
99 lines
4.0 KiB
# A Proposal for An Advanced Smartphone Campus Map
|
|
|
|
## Always-On Chip
|
|
|
|
* The always on chip will send out signals specifying the exact location of itself.
|
|
* Through triangulation, find the current location of the smartphone.
|
|
|
|
### Chip Options
|
|
|
|
* An ESP-based board will take very *very* minimal power, but it would also have very little capability.
|
|
* If we use the chips as locators only with triangulation and mapping logic stuck to the application/cloud, then this would be possible.
|
|
* Through the use of a more powerful hardware: RPi Zero W, for example, we could add additional logic and communication capabilities to the network.
|
|
* RPi could be powered over ethernet, but it would be insanely difficuklt if the building is not wired correctly.
|
|
* Would tiny solar cells be an option for something like this? I doubt it could reach the wattage required, especially in the basement of a building or where there is not light.
|
|
* RPi Zero 2 W can disable cores to conserve power in the case where you do not need all the cores.
|
|
|
|
## Example of Voice Feedback
|
|
|
|
* "Turn left into the hallway. MC207 is the third door on your left."
|
|
* Example, MC207 to Butchery.
|
|
* "Go forward 50 meters. Turn right. Go down the stairs.
|
|
* "Take a quick left-then-right turn, then proceed forward for 50 meters."
|
|
* "Walk 10 meters forward and go through the doors."
|
|
* "Go down the stairs."
|
|
* "Turn right. Walk 50 meters. The butchery will be on your right."
|
|
|
|
## Technical Notes
|
|
|
|
* Thin-client or thin-server?
|
|
* Do the devices interact with eachother to manage information.
|
|
|
|
## Advanced Ideas (Mesh)
|
|
|
|
* Use distributed principles to make the job easier.
|
|
* If the chips are able to triangulate themselves using the existing mesh, then construction or special projects which require the exclusive use of an area would allow the tech to be more resiliant.
|
|
* If you are able to do this with many chips. Say have a "is_synced" variable. When retriangulating, look for other chips with "is_synced" = true. Then, multiple units can be reset all at once in the same area by retriangulating from the outside in.
|
|
|
|
## Additional Use Cases
|
|
|
|
Central website has synced data, but the individual locations should manage their own data by default.
|
|
The last synced data may be used if they either: don't want to handle it themselves, or if the ability to access the yvr. subdomain is unavailable.
|
|
|
|
* Airports
|
|
* yyc.BLAH.BLAH
|
|
* yvr.BLAH.BLAH
|
|
* Other Schools
|
|
* sait.BLAH.BLAH
|
|
* Museums
|
|
* cmch.BLAH.BLAH (Cambridge Museum of Computing History)
|
|
* Large Libraries
|
|
|
|
## How To Do GPS
|
|
|
|
### Option 1
|
|
|
|
GPS for all devices.
|
|
|
|
Advantages:
|
|
|
|
* Easy to sync
|
|
* Can be automatically synced
|
|
* Can be made to very rarely have incorrect coordinates.
|
|
* Could sync with the rest of the world, if required.
|
|
* Can calcualte an average across time and get more accurate. (10-20 seconds, but still useful).
|
|
|
|
Disadvantages:
|
|
|
|
* High cost
|
|
* (Very) High power consumption
|
|
* More likely to require maintainence as more parts are involved.
|
|
* Could potentially go out of sync temporarily if automated.
|
|
* For example: a chip in a basement could potentially receive bad data due to the concrete/metal between it and a GPS satealite.
|
|
|
|
### Option 2
|
|
|
|
* Separate into two models of triangulation chips.
|
|
* One with GPS
|
|
* One without
|
|
* Use the outermost chips as GPS trackers. Get valid data at all times so that they are always in sync.
|
|
* Generally outdoors or next to windows.
|
|
* Only a few are necessary on the edges, and all other nodes sync by relative coordinates.
|
|
|
|
### Option 3
|
|
|
|
* No GPS.
|
|
* Allow a GPS connection through USB-C(?)
|
|
* Allow the GPS to syncronize *once* per device.
|
|
* Potentially high maintainence cost if GPS needs to be recalibrated.
|
|
* It shouldn't happen, but if it did... big oof.
|
|
* However, due to the meshing capabilities, in theory two to five correctly located notes would be able to cascadingly correct issues further away from the edge nodes (the ones with GPS).
|
|
|
|
### Option 4
|
|
|
|
* Use the user's phone to manage GPs locations.
|
|
* This can update potentially inaccurate data.
|
|
* Find a way to figure out if the phone is providing bad/invalid/inaccurate data.
|
|
|
|
|