Wednesday 31 July 2013

Timeline of the work in the next 4 weeks:
1. Today - 4th August
     Improve Location accuracy: This involves
  • Correcting orientation of the location trace when landmarks are encountered [ currently just the vector difference is added to the future values to correct the location].
  • Test with dummy landmarks entered into the database. These dummy landmarks are encountered when the "Tick" button is pressed along the trace.
  • Minimize error while turning or stationary. The pedometer algorithm seems to introduce a large error when the person is not walking. This will be done by detecting if the person is walking or not and accordingly decide to apply the algorithm or not.
2. 5th August - 11th August
    Build a desktop application to visualize the analytics got so far, for the mall owner
  • This involves going through all the images generated on the server by the landmarks generated.
  • Heat map of the mall according to the landmarks generated
  • Going through the comments / ratings left by the users at the various landmarks
3. 12th August - 18th August
  Implement Incremental Localization:
  • Currently the phone app does not maintain a session with the server
  • Instead of updating the information at the end of logging, it periodically logs the data with the server.
  • The server stores the result of each log and carries on as and when it receives the information
4. 19th August - 25th August
Push data to the phone
  • When the phone logs the data periodically, it receives a response regarding the comments/ ratings of the landmarks nearby.
  • A brief description of the offers/ discounts near the landmarks is also downloaded



Sunday 28 July 2013

Fixed app crashes by changing decreasing the sensor polling rate from FASTEST to that suitable for UI and other UI modifications. Also, started testing in my apartment with a couple of seed landmarks. The option to tick is added to derive the error in the approximate location. The whole mechanism is now automated. Will perform multiple tests tomorrow and come up with the accuracy of the system.

Saturday 27 July 2013

Updated the code (server and phone) to get the seed landmarks and correct the location according to it. Next step would be to test this with a proof of concept map of a shopping mall. Will simulate that in my apartment and will get back to you with the results tomorrow.

Thursday 25 July 2013

Done with the server side of detecting the seed landmarks. An approach similar to the one mentioned in the Unloc paper implemented in getSeedLandmarks.m... Now working on the phone app to allow the users to annotate with these initial landmarks and their location. This strictly speaking has to be done by one user initially [ like the owner of the mall]. But subsequent users will be given this option also. Inducting these user annotated landmarks as actual landmarks will be up to the owner to decide. 

Tuesday 23 July 2013

Started working on gathering the initial seed landmarks in a mall. Adding the option of recording the sensor signature of the landmark, and then manually annotating its location thereafter to the phone app. This way, the user has a bunch of landmarks to start with, thereby increasing location accuracy. Also, to check if we are close to a seed landmark, a signature comparison module has to be built. This is different from the ones for Organic landmarks where inter-cluster distance is the metric to determine if we are close to one of those landmarks.
Thresholds for landmark identification is now updated such that only clusters which are better than the 80th percentile values are accepted as stable landmarks.

Monday 22 July 2013

The whole process of finding landmarks, stabilizing them and annotating the comments with the nearest landmark is now automated.

A couple of issues need to be addressed to ensure correctness of landmark detection. I found them interesting after observations from preliminary testing:
1. The thresholds which determine whether a cluster is a landmark [intra-cluster area closeness + sensor feature closeness], a landmark is a stable one [inter-cluster closeness] have to be learnt over time. Initially they were hard-coded to some value suitable for the conditions under which they were tested.

Solution: To learn them from the clusters got. For example an 80 percentile value of cluster-nearness taken as threshold.

2. Seed Landmark detection module, which the paper argued to be non-essential over a period of time; does in fact affect the initial accuracy of the system. We need to identify these (initial seed) sensor signatures like going up a lift, etc.

Solution: To use a tree like structure to identify the signatures of each place (like in page 6 of the paper).

Implementing the first solution now, should be done with the second one also by Wednesday. Also, I'll be starting testing with my new phone Google Nexus 4 from today. [ This should give us an idea of what these latest smartphones are capable of, with respect to collecting sensor data].


Friday 19 July 2013

Changed the primitive stabilization algorithm. Initially was combining closely located landmarks irrespective of their feature values. Now there is a threshold to check for their closeness in feature space as well. Also made changes to populate the landmark database accordingly. 

Also, I have to make a design choice regarding storing the landmark data. Performance wise, is it better to have a database or maintain a Matlab object storing a stable set of landmarks? Currently I have both implemented, but will phase out one of them.

Wednesday 17 July 2013

Done with integrating the stabilization of landmarks code. So the feedback loop to increase accuracy of landmarks is complete. Have to tweak the thresholds for combination of clusters after performing experiments. So the basic code is up and running...(Also committed the latest Matlab code to the git repository). 

Monday 15 July 2013

Done updating the code to populate the landmark and comments database. Now started with integrating the 'stabilization of landmarks' code to fully automate the Kalman filter approach.

Sunday 14 July 2013

Installed Matlab, jdbc driver and made connection to the postgresql server. The tables are available in the database 'sample'. Now making changes in the code to insert landmarks, comments and user info in the database. This will automate the process of storing landmarks and seeing if they're converging to stable ones.

Thursday 11 July 2013

Written the basic code for annotation of comments with the nearest landmark after querying the database. Using a JDBC driver to connect to Postgresql on Matlab. Code currently running on local system. Will upload it to the server tomorrow after setting up Matlab on it.

Wednesday 10 July 2013

Tested the Matlab code on my local machine with the same data. It is way faster (50x) than Octave. So, moving on to Matlab. Until I set it up on the server (waiting for the ISO); I'll be looking into storing the clusters created, in a MySQL database. I've created the tables for Landmarks, Comments, Users and Metadata. I'm connecting to the database using a JDBC driver.

Today, I'll start writing the code for annotating a particular comment/rating with its nearest landmark.

Tuesday 9 July 2013

Sorry for the delay between my posts. I was stuck in getting the octave modules to run on the server.  A couple of bugs held me back for the past 1-2 weeks.

1. Found some bugs in the kmeans module of octave. The processing of the optional parameters was not working if one of those parameters was missing. Also, the parameter 'start' now takes user defined initial seeding for the clustering. Wrong usage of 'lower' and 'tolower' functions in the file. Note that Octave is running slowly on the system, so debugging it is also becoming tedious (~5m per simulation). Other options like Matlab will also have to be looked into, to compare performance in real-time.

2. The issue of permissions/paths to generate the required files in the /var/www/data directory and process them using octave programatically.

3. The app was earlier tested on an older version of android. I ran it on Galaxy S2 this week and found that network operations like multipart-upload cannot be done on the main thread. So moved that part of the code to AsyncTask. Now the app is running smoothly with less crashes.

Now, the server code is running without any error, but is taking a long time to finish clustering (~10-15 min per data folder). 
Internet was down yesterday in my place. So, could not work on the server part. Updated the phone app to take comments and ratings as input. These will be sent to the server along with the other sensors' data when the user has opted to stop logging the information.