# Indoor WiFi-Beacon Dataset Construction Using Autonomous Low-Cost Robot for 3D Location Estimation
## 3 Overall System Architecture
### Backend Database and Web-Server Interface  
The server side was implemented using a MySQL/PHP/HTML trio, which is a standard arrangement for providing a dynamic web interface for quick storage and retrieval of all measured metrics, as demonstrated in Figure 7.  
The backend server had two web interfaces:  
1. A database-insertion interface with which the robot behaves as a client, where it can connect and submit compressed POST HTML requests that include all scanned access points for this iteration. The server in turn parses each request into tens of DB insertion commands, one for each scanned piece of access-point information.
2. A set of processing and filtering scripts through which one can quickly retrieve a selected subset of the measured metrics for further processing and analysis.  
Figure 8a,c show the metadata of the main table in the database and a sample of the recorded metrics, respectively. All recorded metrics are stored in one flat table, which greatly simplifies the implementation of the PHP scripts for manipulating and retrieving information from the database. Figure 8b indicates the next \"autoindex\" of the main table, which indicates that over 261 K samples were collected as part of this study.  
Figure 8: (a) Collected metadata information; (b) statistics of the database’s main table; (c) main database-table structure and few recorded metrics.  
Figure 7: Remote web-server flow.  
Figure 9 shows the flowchart of inserting data into the database, which is triggered by all the WiFi transceivers on the robot. This interface intended for the use of the robot is minimalistic, with simple inserts of the raw data transparently into the database.  
The link speed with the robot was about 50 Mbps, and the insertion of the data into the database did not utilize the full bandwidth. Each transmitted data packet was about 1 KB, conveying information of a full scan with all SSIDs and their signal strength. There were exactly 32 of those packets transmitted each minute, resulting in an average bit rate of less than 5 Kbps. Most of the delay was due to the nodeMCU's scanning algorithm. Furthermore, a dedicated uplink was used for transmitting the data to the server, but there may have been congestion issues in the global network that could have influenced the transmission delay and latency. However, latency, delay, timing, or congestion of the transmission/network were not taken into consideration in our analysis. We focused on reliability of the link with safeguards implemented as part of the robot's transmitting algorithm. Nevertheless, time stamps were collected for possible future use in an AI model.  
Figure 10 shows the flowchart for retrieving data from the database, which is triggered by users for post-processing of the recorded signal-strength information. The retrieval process is slightly more structured towards filtering the database for a selected set of known Aps, as indicated in Figure 10. In addition, the retrieval process organizes the data based on the height of the reporting-client sub-system in the collecting robot.  
All the data collected for this study, along with the firmware of the robot's main controller and client sub-systems, are now available under the ANNU-Beacon project on GitHub, as indicated earlier. This project portal will be used to publish any necessary source code and reference material that might be needed for reproducing this work.  
Figure 9: PHP flowchart intended for the use of the robot.