Add a general presentation at the top of the file, finish the things to do and especially the office space area description, as well as some fixes.
|8 years ago|
|figures||8 years ago|
|owlps-config||8 years ago|
|s01||8 years ago|
|s02||8 years ago|
|s03||8 years ago|
|s04||8 years ago|
|s05||8 years ago|
|s06||8 years ago|
|s07||8 years ago|
|s08||8 years ago|
|s09||8 years ago|
|s10||8 years ago|
|s11||8 years ago|
|s12||8 years ago|
|s13||8 years ago|
|s14||8 years ago|
|s15||8 years ago|
|s16||8 years ago|
|s17||8 years ago|
|s18||8 years ago|
|s20||8 years ago|
|s21||8 years ago|
|s50||8 years ago|
|s51||8 years ago|
|s52||8 years ago|
|s53||8 years ago|
|s54||8 years ago|
|README.org||8 years ago|
OwlPS experiments at Numerica, 2012
These experiments were conducted at the Numerica building in Montbéliard, France, in the summer of 2012. Two different areas were tested, a room in which the environment could be controlled to some extent, and a floor of an office environment. The main goal of these experiment was to be able to test the importance of various parameters on the Wi-Fi signal and on the positioning results.
scenario number, on two digits.
test number; for a given scenario, the first test number is 01, and each time the scenario is played the test number is incremented.
client device short name.
an optional informative string can be added, for example when a scenario has to be run several times with different parameters; when not obvious, the meaning of such suffixes should be documented in the report files.
an optional suffix can be added, separated by a +; suffixes have the following meanings:
the real coordinate were added in the file;
the file is a manual calibration file, containing calibration requests (type 1) (+coord is implied, as manual calibration requests always contain the mobile's coordinates); it can be made from real calibration requests, or from simple positioning requests with added coordinates and adapted type.
OwlPS Aggregator output file;
OwlPS Positioner log file (recorded at the input);
OwlPS Positioner results;
OwlPS Positioner standard output;
OwlPS Positioner standard error;
results formatted in a spreadsheet.
For the result files, the name of the similarity algorithm used to compute the positions is added after the suffix. For now it can be one of the following:
The following mobile terminals can be used:
Android smartphone (Samsung Nexus S);
When received by a Fonera 2.0, the default packet size is 103 bytes for a positioning request, and 116 bytes for an (auto)calibration request.
Unless stated otherwise:
the Fonera is equipped with a 1.8 dBi antenna and its transmission power is 18 dBm;
the transmission power of the EeePC is 14 dBm.
Except if stated otherwise, all the scenarios follow these rules (or should follow them for future tests). The description of the scenarios has precedence over these common rules. Moreover, the report files associated with each test should also warn about each noticed mistake, and each exception made to these rules or to the scenario description.
Mobile terminal: cf. the file names. The OwlPS Client version is v1.3.0-11-gc4e0352.
Aggregation server: Asus EeePC 701 4G running Debian GNU/Linux squeeze (Linux 2.6.32), with an Atheros AR 500 Wi-Fi interface. It runs OwlPS Aggregator v1.3.1-14-ge278aab.
Listeners: 4 Fonera 2.0 with 1.8 dBi antennas, running OpenWrt Backfire. They run OwlPS Listener v1.3.0-11-gc4e0352, and their transmission power is 18 dBm.
The aggregation server, the listeners and the terminal communicate through an ad-hoc network. This limits the rate at which positioning and autocalibration requests are transmitted, but allows for a quick deployment.
Each test's report file should report the temperature and humidity when the test was started. If the information is missing, one can assume that the temperature is controlled around 22-24°C, and the humidity varies from 38% to 55%.
OwlPS Aggregator is run with the default parameters as of the version used, with autocalibration enabled. These parameters can be found in the configuration file /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/owlps-aggregator.conf.
These parameters are not very important, except for the delay between two autocalibration orders. The default value is 1000 ms.
The default aggregation timeout should fit most test cases, but keep in mind that for requests as long as one second (including manual calibration request with the default parameters), it is too short and must be extended in the Aggregator's configuration.
You should also be aware of the fact that for a capture point to transmit autocalibration requests, it must be known by the Aggregator. Therefore, it is not sufficient to wait for 10 seconds (cf. Measurement procedure) after starting the Aggregator to guarantee that each capture point transmits autocalibration requests for 10 seconds. The counter must be started after the Aggregator received a Hello message from all the capture points.
At the end of a test, beware of not stopping the Aggregator too early, e.g. if requests are sent with long delays, or simply if the aggregate timeout is not reached for all the requests in memory (as of August 2012, OwlPS Aggregator does not flush the non-aggregated requests upon exiting, but simply deletes them; this was fixed in OwlPS v1.3.4).
The OwlPS Listener program runs continuously, with the autocalibration activated. It is launched with the following command:
owlps-listenerd -A -v -i 192.168.11.254 -I 192.168.11.254 -r ath1 -w ath0
The default autocalibration parameters are used, i.e.:
20 packets (-n20),
25 ms between two packets (-t25).
The mobile terminal continuously sends positioning requests with the following parameters:
20 packets (-n20),
10 ms between two packets (-t10),
800 ms between two requests (-F800).
Therefore, one request is transmitted approximately each second. The destination IP address is the Aggregator's one (i.e. 192.168.11.254 in our setup).
The complete command used to launch OwlPS Client is the following:
owlps-client -i 192.168.11.254 -n20 -t10 -F800
When using a metronome, the command should be adjusted so that exactly one request is transmitted for each beat of the metronome. For 60 bpm (one request per second), the following parameters have been found to be almost exact:
owlps-client -i 192.168.11.254 -n20 -t10 -F761
When a precise number of requests have to be sent during the scenario, one can use the -N parameter introduced in OwlPS v1.3.2.
During a manual calibration scenario, the default OwlPS Client's values are used for the number of packets and the delay, i.e. 20 packets separated by 50 ms (-n20 -t50).
The mobile terminal's antenna is vertical.
Three mobile terminal's altitudes are defined:
floor (0 m),
hip (0.82 m),
ear (1.57 m).
For the altitudes higher than “floor”, when the mobile terminal is not carried by a human operator, it is put on a non-metallic object. In our setup, the “hip” altitude is achieved by stacking an empty plastic trash (32 cm) on a cardboard box (50 cm); for the “ear” altitude, we add a stack of small boxes (75 cm).
When a human operator carries the mobile terminal, the altitude of the terminal is 1 m (hips/belly).
The antenna of the mobile terminal is vertical. When the mobile terminal is a laptop computer, the screen is vertical, and the computer is set up so that the display side of the screen is in direction of the wall opposite to the point where the mobile is located (when applicable).
The infrastructure (Listeners and Aggregator) must be started first and at least two rounds of autocalibration request done (i.e. each capture point must have sent at least two autocalibration requests) before the mobile terminal is started. As a best practice, the measurements should start at least 10 seconds after the Aggregator knows all the Listeners (cf. section Aggregator for more details).
In the scenarios in which a human has to move along a path, a metronome is set up with the tempo at which the person has to walk. For example, 60 bpm if the pace is of one step per second.
This series of scenarios is schematised in the figure . (You can play with the layers to hide or display various elements.)
The deployment area is a room of 5.80 × 10.60 metres. The origin of the plan is set to the South-West corner of the room.
This simple topology is described in the OwlPS Positioner's configuration file /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/room/topology.csv. The file is a panoramic (180°) photograph of the room.
The East wall is a weight-bearing wall made of concrete, whereas the others are simple partitions, 9.5 cm thick. The West wall has two doors and four windows made of Plexiglas. The doors and windows height is 2.5
A West-East room divider built from wood, metal, and plastic can be folded or unfolded to separate the room in two areas of approximately the same size.
The room is clear from any obstacle, except for the following elements:
Two technical columns made of aluminium containing electricity and network cables, and whose diameter is 12.5 cm, sitting at the coordinates (1.74;4.72) and (2.46;6.63).
Another technical column (which is likely to contain water) of floor dimensions 31 × 51.5 cm. It sits against the East wall, its centre being approximately (2.3;5.65).
The room divider. Folded its floor dimensions are 115 × 71 cm, and its centre is around (5.4;5.7) (against the East wall); when it is set up, it splits the room at approximately 5.25 m in the Y axis.
Four heaters (air conditioners) that measure each 150 × 23 × 92 cm, sitting at each end of the East wall and between the two doors of the West wall.
Two light metal and wood tables and three plastic and metal chairs.
The capture points are attached to the walls and all have their antennas in vertical position, in the direction of the ceiling. Their coordinates are given in the OwlPS Positioner's configuration file /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/room/listeners-fonera.csv.
To simplify the scenario explanation, the following measurement points are predefined:
The mobile terminal is still, without human operator, at hip altitude. Measurements are taken at each corner and the centre of the room (measurement points 1 to 5), during 1 minute at each position.
Repeat the scenario 1, but the mobile terminal is on the floor.
This scenario tests the antenna angle and measurement direction, with a human operator. The measurement points 2 and 5 are tested.
For each point, measurements are taken in two directions, with a 45° angle (clockwise) between the two directions. For the measurement point 2, the directions are:
For the measurement point 5, the directions are:
For each direction, three antenna orientations are measured:
Therefore, we have 6 measurements per point. Each measurement lasts one minute.
Test with a human operator carrying the mobile terminal. The operator moves along a path following the measurement points 1 to 5, and stands at each point for 10 seconds. The pace of the operator is 1 m/s (one second per step, with one-metre steps).
Timing: Before to start the timer, start the aggregation server (with autocalibration activated) and wait for all the listeners to send a Hello message.
Stand at MP#1 in the direction of MP#2, while the listeners send autocalibration requests.
Start the client, stay at MP#1 until t10.
Start walking to MP#2 (4 m distance).
Arrived at MP#2, start rotating in the direction of MP#3.
Rotation achieved, stay at MP#2 until t25.
Start walking to MP#3 (about 9.85 m distance, so the walk pace is around 1.1 m/s to achieve MP#3 in 9 seconds).
Arrived at MP#3, start rotating in the direction of MP#4.
Rotation achieved, stay at MP#3 until t45.
Start walking to MP#4 (4 m distance).
Arrived at MP#4, start rotating in the direction of MP#5.
Rotation achieved, stay at MP#4 until t60.
Start walking to MP#5 (about 4.74 m distance, so the walk pace is around 1.2 m/s to achieve MP#5 in 4 seconds).
Arrived at MP#5, start rotating to the right (in the direction of the mobile wall).
Rotation achieved, stay at MP#5 until t75.
Stop the client.
This scenario aims to evaluate the impact of the delay between the packets sent by the mobile terminal. The delay between two requests (-F), must be the same as the delay between two packets (-t). Each request lasts approximately for one second, and the total number of packets transmitted during each test must be approximately the same, in order to ease the statistical treatment.
The following parameters are evaluated:
10 ms, 100 packets, 60 requests (6000 packets);
20 ms, 50 packets, 120 requests (6000 packets);
30 ms, 33 packets, 182 requests (6006 packets);
40 ms, 25 packets, 240 requests (6000 packets);
50 ms, 20 packets, 300 requests (6000 packets).
The mobile is on the floor, at the centre of the room (2.5;5.5;0).
For each value, the following procedure is run:
The aggregation server is launched, and autocalibration requests from all the capture points are received for at least 10 seconds.
The aggregation server is restarted without autocalibration.
The client is run.
Alternatively, if the experiments are done during only one session, the autocalibration process can be run only once, at the beginning, and the autocalibration requests stored in a separate file.
Please keep in mind that for requests as long as one second, the aggregation timeout must be extended in the Aggregator's configuration (cf. Common rules for details).
This scenario uses measurement points 1 and 5-10. For each measurement point, three altitudes of the terminal are tested: floor, hip and ear. The room divider is half-closed (from the East wall to the centre of the room), and there is no human operator in the room.
For each point, each altitude is measured for one minute, in the following order:
Alternative procedure (advised for easier use of the measurements): a separate aggregation file is made for each point and each altitude.
Repeat the scenario 6, but with a human operator standing 0.5 m at the West of the terminal. Only the hip altitude is studied.
Repeat the scenario 7, but the human operator is always standing at the measurement point 11.
This scenario is similar to the scenario 5, but the parameter evaluated is the size of the packets:
This size is the parameter given to OwlPS Client, and is less than the size of the radio packet. The size of the packet received at the listeners must be written in the report files, as it can vary.
Please refer to the scenario 5 for details and measurement procedure.
Repeat the scenario 1 several times, varying the delay between two packets of the autocalibration requests (option -t of owlps-listenerd):
Repeat the scenario 4 several time with different autocalibration frequencies on the Aggregator (delay between two autocalibration orders). The autocalibration requests' settings (number of packets and delay between two packets) will be adjusted on the Listeners, so that a request emission lasts for around 20-25 ms less than the autocalibration frequency.
The following frequencies are tested:
100 ms (Listeners: -n10 -t8 = 80 ms),
250 ms (Listeners: -n16 -t14 = 224 ms),
500 ms (Listeners: -n20 -t24 = 480 ms),
1000 ms (Listeners: -n39 -t25 = 975 ms).
This scenario aims to evaluate the impact of horizontal capture points' antennas. The scenario 1 is repeated partially (for the measurement points 3, 4 and 5 only) two times:
Each capture point antenna is disposed horizontally, pointing in the direction of the opposite wall.
The antennas are still horizontal, but placed so that each antenna points in the direction of another capture point, in a circle: the North-West and South-East listeners' antennas stay in the same position as the previous test, but the North-East listener's antenna points to the West, and the South-West listener's antenna points to the East.
This scenario aims to evaluate the impact of the temperature. The terminal is on the floor, at the measurement point 1. The temperature starts from a maximum, and lowers to a minimum during the experiment.
This scenario is similar to the scenario 13, but its goal is to evaluate the impact of the humidity rather than of the temperature. Like in the scenario 13, the terminal is at the measurement point 1, but it is placed at hip altitude.
The humidity starts from a minimum, and is raised during the experiment. For this purpose, boilers and hot water basins can be used. That is why the client terminal should not be put on the floor, to avoid attenuation of the signal due to the liquid water itself.
Nobody should enter the room during the measurements.
Repeat the scenario 1, but without client. The terminal is instead replaced by a human operator. This scenario aims to evaluate the influence of the human body on the autocalibration requests.
This scenario follows the same principles as the scenario 15, but this time the scenario 4 is played instead of the scenario 1.
Repeat the scenario 16 (scenario 4 without mobile terminal), but with two human operators, each starting from two opposite corners of the room (measurement points 1 and 4). They move along the following measurement points:
Operator 1: 1, 2, 3, 4, 5 (same as scenario 16).
Operator 2: 4, 3, 2, 1, 5.
After 10 seconds at these positions, the operators start moving to the next measurement points: operator #1 goes to MP#2, while operator #2 goes to MP#3. The operators walk at a pace of one step per second, in the direction of the next measurement point. It takes 4 seconds to reach the next measurement point.
Each time the next measurement point is reached, the operators turn in the direction of the next measurement point and stand for 10 seconds (so at the second position, operator #1 turns in the direction of the MP#3, and operator #2 turns in the direction of MP#2). The time to turn is one second (so the total movement time is 5s in this case).
After 10 seconds at these positions, both operators walk to MP#5.
After 10 seconds at MP#5, the measurements are stopped.
The autocalibration is performed for 5 minutes, without mobile terminal and without human operator.
Repeat the scenario 17, but one of the operators carries the mobile terminal. (This scenario was not implemented.)
Manual calibration, without autocalibration running. The mobile device is carried by a human operator.
Please keep in mind that the default aggregation time is not sufficient to aggregate correctly manual calibration requests (cf. Common rules).
This scenario aims to evaluate the impact of an obstacle on the propagation. Only two equipments are used, one on each side of the obstacle. To evaluate the attenuation in both directions, the easiest way is to activate the autocalibration, but one can also use normal positioning requests.
This series of scenarios is schematised in the figure .
The Fonera use 5 dBi antennas.
Due to the fact that the antenna used on the client terminal in not bendable, to have it vertical in a fixed position, a little stand was used, which increases the terminal altitude by 13 cm. Therefore, the standard altitudes become:
floor (0.13 m),
hip (0.95 m),
ear (1.70 m).
The floor used is the second floor of the west wing of the Numérica building, which is the office space of the OMNI team of the DISC department of FEMTO-ST (formerly LIFC). The plan of this area is presented in the figure . It is mainly composed of four offices of identical sizes, and of two bigger rooms that are each equivalent to two offices in size. All these rooms are against the west wall and are served by a corridor at the east. The central staircase allows to go up from its north side, and down from its south side. The inner dimensions of the floor are 9 metres (west-east) by 29 metres (south-north, from the south wall to the doors at the north).
For historical reasons (i.e. previous experiments), the origin of the plan is located outside the building: the inner side of the west wall has the coordinate 1 on the X axis, and the inner side of the south wall is 0.5 on the Y axis. Therefore, the positioning area is between 1 and 10 metres on the X axis, and between 0.5 and 29 metres on the Y axis.
The west and east walls are load-bearing walls that include big glass windows with metallic armatures. The central wall that separates the offices from the corridor is a thick partition in which are installed electric and network cables as well as water pipes. In contrast, the partition that separate one office from another is only about 10 cm thick. The concrete slabs that separate the floors are about 30 cm thick and are lined with false ceilings.
In the room, various pieces of furniture are present: desks, tables, chairs, and metal cupboards and filing cabinets. The most clear room is the meeting room (room 1060 on the map), in which there are essentially a big table and chairs.
This space's topology is described in the OwlPS Positioner's configuration files /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/offices/topology.csv and /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/offices/waypoints.csv.
In this area, the temperature and humidity level are measured in the corridor, next to the office 0180.
The capture points are put on pieces of furniture, at an altitude of approximately one metre; for this experiment, it is considered that the altitude is exactly one metre. All the capture points have their antennas in vertical position, in the direction of the ceiling. Their coordinates, as well as their real altitudes, are given in the OwlPS Positioner's configuration file /mcy/owlps-experiments/src/commit/7377247179371d21aa682481af4a35999e858e82/2012-numerica/owlps-config/offices/listeners-fonera.csv.
This scenario is similar to the scenario 20. The calibration points are listed in the upper section “Calibration points”.
This scenario is similar to the scenario 1. The measurement points used are 1, 2, 5, 7, 10 and 11, and the terminal is at hip altitude, without human operator carrying it.
This scenario is similar to the scenario 2, i.e. a static measurement with the terminal on the floor, but with the following differences:
only the measurement point 8 is used;
the test lasts for at least 30 minutes.
This scenario is similar to the scenarios 15 to 18, except the environment is not controlled, i.e. people move in the corridor and offices in a regular office activity.
This scenario is similar to the scenario 4: a path is defined, going through all the 14 measurement points.
Before to start the timer, start the aggregation server (with autocalibration activated) and wait for all the listeners to send a Hello message.
Stand at MP#1, facing the North, while the listeners send autocalibration requests.
Start the client, stay at MP#1 until t10.
Start walking to MP#2 (6 steps).
Arrived at MP#2, face the North and wait until t26.
Start walking to MP#3 (7 steps).
Arrived at MP#3, rotate clockwise in two steps (until t35), to face the right side of the frame of the door between the two offices; wait until t44.
Start walking to MP#4 (5 steps).
Arrived at MP#4, rotating clockwise in one step (until t50) to face the office door (MP#5); wait until t60.
Start walking to MP#5 (4 steps).
Arrived at MP#5, face the stairway and wait until t74.
Start walking to MP#6 (4 steps).
Arrived at MP#6, face the West and wait until t88.
Start walking to MP#7 (5 steps).
Arrived at MP#7, rotate counter-clockwise in two steps (until t95) to face the middle of the office wall (the wall separating the office from the corridor); wait until t104.
Start walking to MP#8 (8 steps).
Arrived at MP#8, rotate counter-clockwise in one step (until t113) to face MP#9; wait until t122.
Start walking to MP#9 (4 steps).
Arrived at MP#9, rotate counter-clockwise in one step (until t127) to face the West; wait until t136.
Start walking to MP#10 (4 steps).
Arrived at MP#10, face the North and wait until t150.
Start walking to MP#11 (6 steps).
Arrived at MP#11, face the West and wait until t166.
Start walking to MP#12 (4 steps).
Arrived at MP#12, face the West and wait until t180.
Start walking to MP#13 (6 steps).
Arrived at MP#13, face the North and wait until t196.
Start walking to MP#14 (4 steps).
Arrived at MP#14, face the room door and wait until t210.
Stop the client.
One request should be transmitted each second, for a total of 210 requests. To help meeting this goal, the client can be launched with the -N210 option.
Note: this timing is based on test #7 (2012-09-11), with the slight time shift induced by the client's parameters (i.e. -n20 -t10 -F761 -N210). Due to this time shift, 210 requests are sent during 212 seconds, the end of the test (labelled “end” below) is therefore t212. The two “lost” seconds are rattrapées during the intervals indicated with a star (*).