G04 Final Submission -- Enhanced Positioning, GeoFence, Displaying, and much more...

[Th3stral]

Release v1.1.0 Notes for LiveLink

Written by: Zhaohan Wang

On behalf of: Group04 (Jiayan Liang, Jingyu Sun, Zhaohan Wang)

---

TLDR

This release introduces upgrades and improvements in the following areas:

1. WiFi Positioning Module
2. Boosted Accuracy in Positioning using a Particle Filter and a Sliding-Window Weighted Smoothing Filter
3. Tagging Function for performance evaluation and route point highlighting
4. Introduction of GeoFence Logic
5. Recording & Replay Functionality Updates to process and display more detailed information
6. Enhanced User Experience

Major Updates

1. Wi-Fi Positioning Module

• Open Positioning API Integration
  The system can now estimate location and floor based on submitted Wi-Fi fingerprints.

• Improved Reliability
  Weak signals and unreliable access points are filtered out; only the top 30 strongest signals are retained before upload.

• Optimised Server Requests
  A new callback function handles server responses immediately, triggering necessary processes.

• Redundant Request Prevention
  A flaw causing repeated identical requests has been fixed. A filtering layer now discards duplicate responses to improve efficiency.

• Enhanced Initial Positioning
  The system prioritises Wi-Fi over GNSS for the initial location, improving indoor accuracy. If Wi-Fi data is unavailable or more than 30 seconds old, it falls back to the latest GNSS position. The user interface also displays Wi-Fi availability and shows the timestamp of the last update.

2. Sensor Fusion

The sensor fusion module combines data from:

• PDR (Pedestrian Dead Reckoning)
• GNSS
• Wi-Fi

to estimate the user’s trajectory and position. Two main filters have been introduced for more accurate indoor and outdoor positioning:

1. Dynamically Adjusted Particle Filter (in FilterUtils.java):

   • Trigger: Driven by PDR estimations, using Wi-Fi positions as primary anchors. GNSS data is used if Wi-Fi signals are unreliable.
   • Timeliness: Considers the age of Wi-Fi data, applying time-varying weights to reduce the influence of outdated readings.
   • Directionality: Adjusts the weight of Wi-Fi anchor points based on orientation.

2. Sliding-Window Weighted Smoothing Filter (in TrajectoryOptimizer.java):

   • Substitutes batch optimisation to smooth and refine the predicted trajectory without high computational overhead.

An EKF (Extended Kalman Filter) is also provided in FilterUtils.java for future use.

Evaluation Pipeline

• Tags can be added while recording a trajectory for subsequent performance evaluation.
• An external pipeline quantitatively assesses filter performance and supports parameter tuning.

Trajectory Storage

• Wi-Fi and tagged positions are now stored in the existing gnss_data entry with providers labelled as wifi_fine and fusion.
• Fused trajectory points are stored in the new fusion_data entry, using a existing protocol Pdr_Samples.

3. GeoFence

• Accurate Geofences
  Geofences help correct predicted trajectories in specific scenarios.
• Floor Change Detection
  By identifying main staircases and lift areas in the Nucleus Building, the system automatically adjusts floor levels. Field tests confirm reliable performance.
• External Geofence Labelling Tool
  Accelerates the process of acquiring geofence coordinates.

4. Display and User Experience

• Recording

  • Colour-Coded PDR, fused trajectory, GNSS, and Wi-Fi positions, with toggles to enable or disable each (except fused trajectory).
  • Only the latest five GNSS and Wi-Fi positions are shown to maintain a clear view.

• Replay

  • Displays the same elements as recording mode, preserving all Wi-Fi and GNSS positions.
  • Shows GNSS error as circles for improved clarity.

• User Experience

  • A default account is available to avoid mandatory registration.
  • More status messages appear via toast notifications.
  • Wi-Fi acquisition status is now visible on the initial positioning interface.

---

5. Known Issues in the Original PositionMe App

Incorrect Coordinate Conversion Function (Fixed)

• The calculateNewPos() function in UtilFunctions had an error in its latitude correction term, producing incorrect east/west conversions. This has now been fixed, an individual pull request about this problem shall be submit later this month..

Wi-Fi Positioning Request Issue (Not Fixed)

• The current mechanism relies on Volley, which does not gracefully handle HTTP 404 errors, causing repeated Wi-Fi registrations. While this does not severely affect core functionality, it remains unresolved.

Screenshots from the new release