Merge branch 'master' of https://git.frank-ebner.de/FHWS/IPIN2018

tex_review/review/01_review.txt

@@ -15,11 +15,8 @@ The paper presents a smartphone-based localization system using a particle filte
 -> Thank you very much for pointing this out. Your concerns are valid. This was a misformulation within the introduction of the paper. We have improved the relevant section of the text and made the basic statement clearer. Please refer to line xxx and xxx.
 
 5. The author mention that "Such buildings are often full of nooks and crannies, what makes it hard for dynamical models using any kind of pedestrian dead reckoning (PDR)","the error accumulates not only over time, but also with the number of turns and steps made". So "Thus, this paper presents a robust but realistic movement model using a three-dimensional navigation mesh based on triangles". However, Why does the three-dimensional navigation mesh can deal with the turns and steps error? The author should give the more detail description. The navigation graph uses 30*30 grid-cell, the navigation mesh uses triangles. But I don't find very clear that how does the triangles plan? More triangles can improve the accuracy or not? Why the the ground floor need 320 triangles? This the minimum?
-@Frank besser beschreiben?
-alles wird mit so wenigen 3-ecken wie möglich abgedeckt. hängt von der architektur ab
-leerer raum = 2 3-ecke. je nach hindernissen wird es mehr
-die anzahl der 3-ecke ist NICHT variabel sondern wird vom algorithmus bestimmt
-320 kam halt bei raus
+-> We completely changed the transition part, describing how both, graph and nav-mesh are generated automatically, based on the building's floorplan. The number of required triangles strongly depends on the building's layout. 320 were required for the building presented within the picture.
+
 
 6. The authors emphasize that "The goal of this work is to propose a fast to deploy and low-cost localization solution, that provides reasonable results in a high variety of situations". But for the 2500m2 building they used 42 WiFi beacon. I don't think the number is few. Is the whole 42 beacon necessary? The author should discuss the impact of the number of WiFi beacon. How many are the reference poits? What's the impact of the density of the reference points? If the authors want to emphasizen the fast deploy and low-cost, they should give more detail discussion, also the "high variety".
 -> 2500m2 sind nur die bereiche in denen gelaufen werden kann. ohne den innenhof. die zahl ist also etwas verwirrend... 

tex_review/review/02_review.txt

@@ -14,10 +14,9 @@ Using a MCL you do not need to mix observations and actions in the same concept
 From my point of view formulation of transition model T should be tackled using actions (steps) and observations (s_wifi) should be used like an observation model V (described like "Evaluation" in section 5).
 
 line 226: What is z_t? Is an observation o_t? nomenclature should be unified through the whole paper
-@Frank z_t position genauer beschreiben
-das nav-mesh geht erstmal nur 2D und das z interpolieren wir
-das z (höhe) wird ja wirklich vom stockwerk vorgegeben.
-x,y,z sind alle 3 teil vom state!
+-> we completely changed the formulation here. z_t is the z-component at time t, which belongs to the state q_t.
+   it is given be the nav-mesh triangles, which denote the buildings floor.
+   z_t stays constant, as long as the floor is flat. it only changes when stairs are involved.
 
 line 319: Are these thresholds able for all of pedestrians? have you tried with different actors and behaviors?
 

tex_review/review/03_review.txt

@@ -59,27 +59,21 @@ Ln 160 “are based on the nature of particle filter.” -> “are based on the
 -> Fixed in line 180.
 
 Ln 215: "Using variable shaped/sized elements instead of rigid grid-cells provide both higher accuracy for reaching every corner, and ..." Is accuracy the right word here?
--> TODO: @Frank
-hervorheben, dass das grid integer based ist. und deshalb die grid-punkte fallen wie sie fallen
-hervorheben, dass grid und nav-mesh auto-generiert werden
-anzahl der 3-ecke hängt einfach von der architektur ab. je mehr hindernisse und türen, desto mehr 3-ecke werden es
-für einfache recheckige räumen reichen sonst 2 dreiecke. aber die seiten der 3-ecke müssen ja zusammenhänge
+-> We completely changed the transition part, describing how both, graph and nav-mesh are generated automatically, based on the building's floorplan.
+We hope the new description points out why navigation meshes allow for a better (and more exact/accurate) representation of the building's floorplan compared to the grid-based approach.
 
 
 Ln 228: "If the destination is unreachable, e.g. due to the walls or other obstacles." This phrase is incorrect, the authors should reformulate it.
-@Frak umschreiben
+-> Thank you for noticing! We adjusted the sentence accordingly.
 
 Ln 237: "...the average acceleration..." This includes both linear acceleration and gravity, use "linear acceleration".
--> TODO: @Frank?
-hier gehts um die gravity. wir müssen die lage des phones erkennen. hervorheben.
-die >>linear<< acceleration interessiert hier nicht.
-das ganze wird sehr oft aktualisiert um die richtige lage zu haben
+-> we rephrased the complete paragraph. It should now be clear how the current gravity readings are used to
+determined the phone's current orientation, to undo the rotation, present within the gyroscope's readings.
 
 Ln 258 -  This equation needs revision. Should it be "p(s_i|p)  ~ N(u_i,p , std²_wifi)" ? Also the wall-attenuation-factor-model only takes into account attenuation by floors, not walls.
--> TODO: Eigentlich passt das mit der NV, für Ihn tdz ändern? Und das model nimmt keine wände, weil wir keine wände nehmen :D. 
-@Frank hervorheben dass wir nicht WAF sondern log-dist-ceiling benutzen
-walls wären problemlos möglich, allerdings kostet das dann viel zu viel zeit die schnittpunkte zu analysieren
-
+-> No, the equation is correct. Its the actual >result< of the normal distribution when questioned for the received s_i, given the model prediction was u_i,p with uncertainty \sigma^2_wifi
+-> We now made clear that our model is something in between the log-distance and the wall-attenuation factor model. To reduce computation time on the smartphone, only floors/ceilings are considered
+as this can be achieved without costly intersection tests. We also pointed out, that including walls would be more accurate, but is costly during runtime (intersection-tests).
 
 Ln 271-272: The authors mention that their WiFi fingerprinting approximation process is faster than classical fingerprinting, but they fail to provide a reference for an example of the latter or significant metrics such as the average time per square meter for fingerprinting a whole building. Furthermore, the authors should also take into account that while there are approaches where reference measurements are recorded on small grids between 1 to 2m, there are also approaches able to record reference measurements using faster methods. One example is walking by the building while registering ground truth points and using dead reckoning techniques (see Guimarães, V. et al. A motion tracking solution for indoor localization using smartphones. In Proceedings of the 2016 International Conference on Indoor Positioning and Indoor Navigation (IPIN)).
 -> TODO: vielleicht den satz hier entfernen und im related work darauf hinweisen, dass es auch andere schnelle ansätze gibt? Wobei wir im related work schon [20] gecited haben, der genau das macht! vielleicht erwähnen wir seinen noch, damit er zufrieden ist? Oder wir zeigen das kleine fingerprints schneller ist als laufen? was vermutlich nicht der fall ist.