diff --git a/.readthedocs.yaml b/.readthedocs.yaml index 0166621..4b1bb75 100644 --- a/.readthedocs.yaml +++ b/.readthedocs.yaml @@ -23,6 +23,7 @@ sphinx: # fail_on_warning: true # Optionally build your docs in additional formats such as PDF and ePub +formats: all # formats: # - pdf # - epub diff --git a/source/gettingstarted.rst b/source/gettingstarted.rst index a76d15c..45b8c8f 100644 --- a/source/gettingstarted.rst +++ b/source/gettingstarted.rst @@ -26,50 +26,39 @@ the RoboCup Soccer Simulator. Getting and installing the server ================================================= -The procedure shown was performed on a computer running SuSE -7.3-GNU/Linux 2.4.10-4GB (check your version with ``uname -sr``) -with gcc 2.95.3 and gcc 3.2 (check your version with ``which g++``) -but any reasonably up-to-date installation should work. -prompt. - +The procedure shown was performed on a computer running Linux. +We recommend using a stable Linux environment for running the +simulation server and monitor. Get tar.gz files for the version you are after from the Simulator's code repository: * `rcssserver `_ performs the actual simulation. * `rcssmonitor `_ allows you to watch game in progress. -* `rcsslogplayer `_ allows you to replay logs (\*.rcg files) created by rcssserver. - -At the time of this writing (May-1-2021) the latest version is 16.0.0 -and will be used in the example below. Please substitute 16.0.0 for the -latest version available. - +* `rcsslogplayer `_ allows you to replay logs (\*.rcg files) created by rcssserver. -If you have downloaded rcssserver-\*.tar.gz, then first extract the +Unless there is a particular reason, we recommend using the latest +released version. +If you have downloaded rcssserver-x.x.x.tar.gz, then first extract the source files by running:: - $ tar zxvf rcssserver-16.0.0.tar.gz + $ tar zxvf rcssserver-x.x.x.tar.gz -directory to **rcssserver-16.0.0**. This directory contains the following +directory to **rcssserver-x.x.x**. This directory contains the following files:: - $ cd rcssserver-16.0.0 + $ cd rcssserver-x.x.x $ ls - acinclude.m4 compile configure install-sh - Makefile.in README.md aclocal.m4 config.guess - configure.ac ltmain.sh missing src - AUTHORS config.h.in COPYING.LESSER m4 - NEWS ylwrap ChangeLog config.sub - depcomp Makefile.am rcssbase + AUTHORS Makefile.in compile configure m4 + CMakeLists.txt NEWS config.guess configure.ac missing + COPYING.LESSER README.md config.h.cmake depcomp rcss + ChangeLog acinclude.m4 config.h.in install-sh src + Makefile.am aclocal.m4 config.sub ltmain.sh ylwrap -Always read the **README** file first:: - $ more README +Always read the **README.md** file first:: -The **COPYING** file contains details about the license under which you -may use and modify the software. Please, make sure you read it in your -own time:: + $ more README.md - $ more COPYING ================================================= Quick Start @@ -402,33 +391,6 @@ processes that have a specific name is by means of the **killall** command, for example: ``killall rcssserver`` is sufficient to kill all processes with the name **rcssserver**. -================================================= -Supported platforms -================================================= - -The Soccer Server supports quite a few unix style platforms but we haven’t actually -compiled a list. The simulator (grouped by version numbers) is known to work on the -following platforms [#f2]_: - -- 9.2.2 - - - SuSE 7.3 with gcc 2.95.3 or 3.2 (Tom Howard) - - Windows 2000 with Cygwin with gcc 2.95.3 (Tom Howard) - - SuSE 8.1 with gcc 3.2 (Jan Murray) - - Debian 3.0 (woody) with gcc 2.95.4 (Jan Murray) - - SuSE 7.0 Linux with gcc 2.95.2 (Kernel 2.4.16) (Goetz Schwandtner) - -- 9.1.5 - - - SuSE 8.1 with gcc 3.2 (Jan Murray) - - Debian 3.0 (woody) with gcc 2.95.4 (Jan Murray) - - SuSE 7.3 with gcc 2.95.3 or 3.2 (Tom Howard) - - Windows 2000 with Cygwin with gcc 2.95.3 (Tom Howard) - -If you have a platform not listed above for a particular simulator version and -you have managed to get the simulator running on it, please let us know at -. - ================================================= Troubleshooting ================================================= diff --git a/source/soccerclient.rst b/source/soccerclient.rst index ae9a79a..923de55 100644 --- a/source/soccerclient.rst +++ b/source/soccerclient.rst @@ -315,27 +315,28 @@ Sample Client ---------------------- The Soccer Server distribution includes a very simple program for soccer clients, called -sampleclient. It is under the ”sampleclient” directory of the distribution, and is +rcssclient. +It is under the "src" directory of the distribution, and is automatically compiled when you make the Soccer Server. -The sampleclient is not a stand-alone client: It is a simple ‘pipe’ that redirects +The rcssclient is not a stand-alone client: It is a simple ‘pipe’ that redirects commands from its standard input to the server, and information from the server to its standard output. Therefore, nothing happens when users invoke the sampleclient. The users must type-in commands from keyboards, and read the sensor information displayed on the terminal. (Actually it is impossible to read sensor information, because the server sends about 17 sensor informations (see information and sense_body information) per second.) -The sampleclient is useful to understand what clients should do, and what the clients +The rcssclient is useful to understand what clients should do, and what the clients will receive from the server. -**How to Use** sampleclient +**How to Use** rcssclient Here is a typical usage of the sampleclient. #. Invoke client under sampleclient directory of the Soccer Server. :: - % ./client SERVERHOST + % ./rcssclient -server SERVERHOST Here, SERVERHOST is a hostname on which Soccer Server is running. Then the program awaits user input. @@ -343,11 +344,10 @@ Here is a typical usage of the sampleclient. port (6000), the users should use the following form. :: - % ./client SERVERHOST 6005 + % ./rcssclient -server SERVERHOST -port 6005 #. Type in init command from the keyboard. - (init MYTEAMNAME (version 7)) Here MYTEAMNAME is a team name the users want to use. @@ -356,29 +356,34 @@ Here is a typical usage of the sampleclient. typical output :: - send 6000 : (init foo (version 7)) - recv 1567 : (init r 1 before_kick_off) - recv 1567 : (server_param 14.02 5 0.3 0.4 0.1 60 1 1 4000 45 0 0.3 0.5 ... - recv 1567 : (player_param 7 3 3 0 0.2 -100 0 0.2 25 0 0.002 -100 0 0.2 ... - recv 1567 : (player_type 0 1 45 0.4 5 0.006 0.3 0.7 0 0 1 0.6) - recv 1567 : (player_type 1 1.16432 28.5679 0.533438 8.33595 0.00733326 ... - recv 1567 : (player_type 2 1.19861 25.1387 0.437196 5.92991 0.00717675 ... - recv 1567 : (player_type 3 1.04904 40.0956 0.436023 5.90057 0.00631769 ... - recv 1567 : (player_type 4 1.1723 27.7704 0.568306 9.20764 0.00746072 ... - recv 1567 : (player_type 5 1.12561 32.4392 0.402203 5.05509 0.00621539 ... - recv 1567 : (player_type 6 1.02919 42.0812 0.581564 9.53909 0.00688457 ... - recv 1567 : (sense_body 0 (view_mode high normal) (stamina 4000 1) ... - recv 1567 : (see 0 ((g r) 61.6 37) ((f r t) 49.4 3) ((f p r t) 37 27) ... - recv 1567 : (sense_body 0 (view_mode high normal) (stamina 4000 1) ... - - The first line, “send 6000 : (init foo (version 7))”, is a report what - the client sends to the server. The second line,”recv 1567 : (init r 1 - before_kick_off) is a report of the first response from the server. Here, the - server tells the client that the assigned player is the right side team (r), its uniform number is 1, and the current playmode is before_kick_off. The next 9 - lines are server_param and player_param, which tells various parameters used in - the simulation. Finally, the server starts to send the normal sensor informations, - sense_body and see. Because the server sends these sensor information every - 100ms or 150ms, the client continues to output the information endlessly. + (init foo (version 7)) + (init r 1 before_kick_off) + (server_param 14.02 5 0.3 0.4 0.1 60 1 1 4000 45 0 0.3 0.5 ... + (player_param 7 3 3 0 0.2 -100 0 0.2 25 0 0.002 -100 0 0.2 ... + (player_type 0 1 45 0.4 5 0.006 0.3 0.7 0 0 1 0.6) + (player_type 1 1.16432 28.5679 0.533438 8.33595 0.00733326 ... + (player_type 2 1.19861 25.1387 0.437196 5.92991 0.00717675 ... + (player_type 3 1.04904 40.0956 0.436023 5.90057 0.00631769 ... + (player_type 4 1.1723 27.7704 0.568306 9.20764 0.00746072 ... + (player_type 5 1.12561 32.4392 0.402203 5.05509 0.00621539 ... + (player_type 6 1.02919 42.0812 0.581564 9.53909 0.00688457 ... + (sense_body 0 (view_mode high normal) (stamina 4000 1) ... + (see 0 ((g r) 61.6 37) ((f r t) 49.4 3) ((f p r t) 37 27) ... + (sense_body 0 (view_mode high normal) (stamina 4000 1) ... + + The first line, “(init foo (version 7))”, is a report what + the client sends to the server. The second line, ”(init r 1 + before_kick_off) is a report of the first response from the + server. + Here, the server tells the client that the assigned player is + the right side team (r), its uniform number is 1, and the + current playmode is before_kick_off. + The next 9 lines are server_param and player_param, which tells + various parameters used in the simulation. + Finally, the server starts to send the normal sensor informations, + sense_body and see. + Because the server sends these sensor information every 100ms or + 150ms, the client continues to output the information endlessly. #. Type in move command to place the player to the initial position. The player appears on a bench outside of the field. Users need to move it to its initial position @@ -416,7 +421,7 @@ Here is a typical usage of the sampleclient. Overall Structure of Sample Client ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The structure of the sampleclient is simple. The brief process the client does is as +The structure of the rcssclient is simple. The brief process the client does is as follows: #. Open a UDP socket and connect to the server port. (init_connection()) @@ -475,141 +480,6 @@ process, which controls to send commands, in parallel. **[Planning]** To make a plan of play: Using sensor information, the client needs to generate appropriate command sequences of play. Of course, this is the final goal of developing soccer clients!! -Here are two simple examples of stand-alone players, sclient1 and sclient2, which -just chase the ball and kick it to the opponent goal. The sources are available from - - ftp://ci.etl.go.jp/pub/soccer/client/noda-client-2.0.tar.gz - -In the examples, the functions listed above are realized as follows: - - - * For Sensing function, both examples use common facilities of class BasePlayer, class FieldState, and estimatePos functions. By these facilities, the example programs do: - * receive data from a socket connected with the server, - * parse the data as S-expression, - * interpret the expression into internal data format (class SensorInfo), - * and in the case the received data is visual sensor information, estimate player’s and other object’s positions. - - For more detail, please read the source code. - - * For Action Interval and Parallelism functions, the two examples use different methods. The first example, sclient1 uses timeout of select() function. The second - one, sclient2 uses the multi-thread (pthread) facility. These are described below. - - * For Planning function, both examples have very simple planners as follows: - * If the player does not see the ball in recent 10 steps, or if the player can not - estimate its position in recent 10 steps, it looks around. - * If the ball is in kickable area, it kicks the ball to the opponent goal. - * Otherwise, the player rushes to the ball (turns to the ball and dashes). - -sclient1 - -The sclient1 uses the timeout facility of select() function to realize Action Interval -and Parallelism. - -The key part of the program is in MyPlayer::run(). Here is the part of the source -code - - .. code-block:: c - - //---------------------------------------- - // enter main loop - - SocketReadSelector selector ; - - TimeVal nexttic ; // indicate the timestamp for next command send - nexttic.update() ; // set nexttic to the current time. - - while(True) { - //------------------------------------------------- - // setup selector - - selector.clear() ; - selector.set(socket) ; - - //------------------------------------------------- - // wait socket input or timeout (100ms) ; - - Int r = selector.selectUntil(nexttic) ; - - if(r == 0) { // in the of timeout. (no sensor input) - doAction() ; // enter action part - nexttic += TimeVal(0,100,0) ; // increase nexttimetic 100ms - } else { // got some input - doSensing() ; // enter sensor part - } - } - -Here, class SocketReadSelector is a class to abstract facilities of select() and is -defined in ”itk/Socket.h”. In the line “Int r = selector.selectUntil(nexttic) -;”, the program awaits the socket input or timeout indicated by nexttic, which holds -the timestamp of the next tic (simulation step). The function returns 0 if timeout, or -the number of receiving sockets. In the case of timeout, the program calls doAction() in -which a command is generated and sent to the server, or otherwise, it calls doSensing() -in which a sensor information is processed. - -sclient2 - -The sclient2 uses the POSIX thread (pthread) facilities to realize Action Interval and -Parallelism. - -The key part of the program is also in MyPlayer::run(). Here is the part of the -source code: - - .. code-block:: c - - //---------------------------------------- - // fork sensor thread - - forkSensor() ; - - //---------------------------------------- - // main loop - - while(True) { - if (!isBallSeenRecently(10)) { - //------------------------------ - // if ball is not seen recently - // look around by (turn 60) - for(UInt i = 0 ; i < 6 ; i++) { - turn(60) ; - } - } else if (kickable()) { - ... - } - } - -The statement “forkSensor() ;” invokes a new thread for receiving and analyzing the -sensor information. (The behavior of the sensor thread are defined in ”SimpleClient.*” -and ”ThreadedClient.*”.) Then the main thread enters the main loop in which action -sequences of “chasing the ball and kick to the goal” are generated. Because Sensing -function is handled in the sensor thread in parallel, the main thread needs not take care -of the sensor input. - -In order to keep action interval to be 100ms, the sclient2 waits for the next -simulation step by the function ThreadedPlayer::sendCommandPre() defined in -”ThreadedPlayer.cc” as follows: - - .. code-block:: c - - Bool ThreadedPlayer::sendCommandPre(Bool bodyp) { - cvSend.lock() ; - - if(bodyp) { - while(nextSendBodyTime.isFuture()) - cvSend.waitUntil(nextSendBodyTime) ; - } - while(nextSendTime.isFuture()) { - cvSend.waitUntil(nextSendTime) ; - } - return True ; - } ; - -In this function, MutexCondVar cvSend provide a similar timeout facility of select() -function used in sclient1 described above. (MutexCondVar is a combination of -condition variable (pthread_cond_t) and mutex (pthread_mutex\_ ), and is defined in -”itk/MutexCondVar.h”.) Because the function is called just before the player sends a -command to the server, and nextSendBodyTime is controlled to indicate the timestamp -of the next simulation step, the thread waits to send a command in the next tic. - -------------------------- Tips -------------------------- diff --git a/source/soccerserver/protocols.rst b/source/soccerserver/protocols.rst index 5d16f7e..44948e9 100644 --- a/source/soccerserver/protocols.rst +++ b/source/soccerserver/protocols.rst @@ -60,7 +60,8 @@ Initial Settings +-----------------------------------------------------------+-------------------------------------------------------------+ | (synch_see) | (ok synch_see) | +-----------------------------------------------------------+-------------------------------------------------------------+ - +| (gaussian_see) | (ok gaussian_see) | ++-----------------------------------------------------------+-------------------------------------------------------------+ @@ -231,4 +232,3 @@ The following table shows the protocol for client version 14 or later. | (stamina *Stamina* *Effort* *Recovery* *Capacity*) | | [k\|t\|f] [r\|y])) | +--------------------------------------------------------------------------------------------------------------------------+ - diff --git a/source/soccerserver/sensor-models-body-sensor-model.rst b/source/soccerserver/sensor-models-body-sensor-model.rst index b5bd6bf..c2669a8 100644 --- a/source/soccerserver/sensor-models-body-sensor-model.rst +++ b/source/soccerserver/sensor-models-body-sensor-model.rst @@ -28,6 +28,7 @@ The format of the body sensor message is: | | (tackle (expires *ExpireCycles*) (count *TackleCount*)) | | | (collision {none\|[(ball)] [(player)] [(post)]}) | | | (foul (charged *FoulCycles*) (card {red\|yellow\|none}))) | +| | (focus_point *FocusDist* *FocusDir*)) | +------------------------------------------------------------------------------------------------+ - *ViewQuality* is one of ``high`` and ``low``. @@ -42,7 +43,7 @@ The format of the body sensor message is: - *ExpireCycles* - *FoulCycles* -**TODO: add descriptions about values. arm [8.03], focus [8.04], tackle [8.04], collision [12.0.0_pre-20071217], foul [14.0.0] in NEWS** +**TODO: add descriptions about values. arm [8.03], focus [8.04], tackle [8.04], collision [12.0.0_pre-20071217], foul [14.0.0], focus_point [18.0.0] in NEWS** The semantics of the parameters are described where they are actually used. diff --git a/source/soccerserver/sensor-models-vison-sensor-model.rst b/source/soccerserver/sensor-models-vison-sensor-model.rst index 3a27f46..8b4762a 100644 --- a/source/soccerserver/sensor-models-vison-sensor-model.rst +++ b/source/soccerserver/sensor-models-vison-sensor-model.rst @@ -4,15 +4,22 @@ Vision Sensor Model -------------------------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Basics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + The visual sensor reports the objects currently seen by the player. -The information is automatically sent to the player every -**server::sense_step**, currently 150, milli-seconds, in the default setting. -If players use the synchronous mode, the frequency of the visual information is synchronized with the simulation step. -The simulation parameters related to the visual information are listed in :numref:`param-visualsensor` and :numref:`heterogenious-param-visualsensor`. +The information is automatically sent to the player with the frequency +determined by the player's view width, view quality, and the +synchronous/asynchronous mode. +Furthermore, the server mixes noise into the information sent to the +player. There are two types of noise models: the quantiazaiton model +and the Gaussian model, and the default is the quantization +model. Gaussian model was introduced from version 19 Visual information arrives from the server in the following basic format: - (see *ObjName* *Distance* *Direction* *DistChng* *DirChng* *BodyDir* *HeadDir*) + (see *ObjName* *Distance* *Direction* *DistChng* *DirChng* *BodyDir* *HeadDir* [t|k]) *Distance*, *Direction*, *DistChng* and *DirChng* are calculated in the following way: @@ -24,14 +31,15 @@ following way: p_{ry} &= p_{yt} - p_{yo} \\ v_{rx} &= v_{xt} - v_{xo} \\ v_{ry} &= v_{yt} - v_{yo} \\ + a_o &= AgentBodyDir + AgentHeadDir \\ Distance &= \sqrt{p_{rx}^2 + p_{ry}^2} \\ Direction &= \arctan{(p_{ry}/p_{rx})} - a_o \\ e_{rx} &= p_{rx} / Distance \\ e_{ry} & = p_{ry} / Distance \\ DistChng &= (v_{rx} * e_{rx}) + (v_{ry} * e_{ry}) \\ DirChng &= [(-(v_{rx} * e_{ry}) + (v_{ry} * e_{rx})) / Distance] * (180 / \pi) \\ - BodyDir &= PlayerBodyDir - AgentBodyDir - AgentHeadDir \\ - HeadDir &= PlayerHeadDir - AgentBodyDir - AgentHeadDir + BodyDir &= PlayerBodyDir - a_o \\ + HeadDir &= PlayerHeadDir - a_o where :math:`(p_{xt},p_{yt})` is the absolute position of the target object, @@ -89,40 +97,47 @@ The kicking state is visible the cycle directly after kicking. Asynchronous mode and Synchronous mode ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -There are two modes available for all players: asynchronous mode -and synchronous mode. +There are two modes available for all players in in the vision sensor: +asynchronous mode and synchronous mode. The asynchronous mode functions exactly like the default time step in version 11 or older. -In server versions 17 and below, asynchronous mode is still the -default mode for all players, including versions 12 to 17. - -In server versions 17 and below, asynchronous mode is the -default mode for all players, including versions 12 to 17. -If players wish to switch to synchronous mode, they can do -so by using the "(synch_see)" command. Once they have switched -to synchronous mode, they cannot return to asynchronous mode. -Additionally, players using version 11 or older can also use -the "(synch_see)" command to access synchronous mode. - -In server versions 18 and above, players using version 18 are -required to use synchronous mode. However, players using older -versions can still switch to synchronous mode by using the -"(synch_see)" command to change the default view mode. - - - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Range of View -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Until server version 17, asynchronous mode is the default mode for all +players. +Since version 18, synchrnonous mode is the default mode. +If v17 or older players wish to switch to synchronous mode, they have +to send the ``(synch_see)`` command. +Once they have switched to synchronous mode, they cannot return to +asynchronous mode. + + +In asynchronous mode, the information is automatically sent to the +player every **server::sense_step**, currently 150, milliseconds, in +the default setting. +The frequency is changed according to the player's view width and view +quality. +Please note that the message arrival timig is not synchronized with +the simulation step interval. + +In synchronous mode, players' view quality is always set to 'high' and +they cannot change their view quality. +Instead of that, the message arrival timing of the visual information +is automatically synchronized with the simulation step interval. +The server executes the visual information transmission process +**server::synch_see_offset** milliseconds after the simulation step +update. +The frequence is changed according to the player's view width. + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Range of View and View Frequency in Asynchronous mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The visible sector of a player is dependant on several factors. -First of all we have the server parameters **server::sense_step** and -**server::visible_angle** which determines the basic time step between -visual information and how many degrees the player's normal view cone is. -The default values in the asynchronous mode are 150 milli-seconds and 90 degrees. -If players use the synchronous mode, the frequency of the visual information -is synchronized with the simulation step. See the next section in detail. +In asynchronous mode, we have the server parameters +**server::sense_step** and **server::visible_angle** which determines +the basic time step between visual information and how many degrees +the player's normal view cone is. +The default values in the asynchronous mode are 150 milliseconds and 90 degrees. The player can also influence the frequency and quality of the information by changing *ViewWidth* and *ViewQuality*. @@ -273,9 +288,12 @@ Range of View and View Frequency in Synchronous mode In synchronous mode, the "low" view quality is not available, and the view widths in :numref:`setting-synchronousmode-v17` are available. In all view widths, rcssserver send see messages at -**server::synch_see_offset** milli-seconds from the beginning +**server::synch_see_offset** milliseconds from the beginning of the cycle. +The amount of information the player can receive changes depending on +the distance to the target object, the same as in asynchronous mode. + .. .. table:: Settings of the synchronous mode in server v.17 and older versions .. table:: Settings of the synchronous mode @@ -325,37 +343,48 @@ of the cycle. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Focus Point ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + The focus point concept was developed in server version 18 to make observations in the game more closely resemble those made by human observers and camera -lenses. The position of the focus point affects the observation noise model. +lenses. +The position of the focus point affects the observation noise model. In brief, the server introduces more noise to the distance of an observed object if the object is farther from the observer's focus point. The default position of the focus point is the player's position. However, the player can change the focus point by sending the -"(change_focus dist_moment dir_moment)" command. +``(change_focus DIST_MOMENT DIR_MOMENT)`` command. It's worth noting that the focus point cannot be outside the player's view angle, and its maximum distance from the player is 40. This feature is available to players using version 18 or above on server versions 18 or above. + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Visual Sensor Noise Model: Protocol v17 or older +Visual Sensor Noise Model: Quantization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -In order to introduce noise in the visual sensor data the values sent from -the server is quantized. +The quantizaiton noise model is the default mode for all players. +In this mode, in order to introduce noise in the visual sensor data +the values sent from the server is quantized. For example, the distance value of the object, in the case where the object in sight is a ball or a player, is quantized in the following manner: .. math:: + p_{rfx} &= p_{xf} - p_{xo} \\ + p_{rfy} &= p_{yf} - p_{yo} \\ + f &= \sqrt{p_{rfx}^2 + p_{rfy}^2} \\ + f' &= \exp({\mathrm Quantize}(\log(f),quantize\_step)) \\ + d'' &= {\mathrm Quantize}({\mathrm max}(0.0, d - (f - f')), 0.1) - d' = {\mathrm Quantize}(\exp({\mathrm Quantize}(\log(d),quantize\_step)),0.1) - - -where :math:`d` and :math:`d'` are the exact distance and quantized distance -respectively, and +where :math:`(p_{xf},p_{yf})` is the absolute position of the focus point of the observer, +:math:`(p_{xo},p_{yo})` is the absolute position of the observer, +:math:`d` is the exact distance of the observer to the object, +:math:`f` and :math:`f'` are the exact distance and quantized distance +of the focus point to the object respectively, +and :math:`d''` is the result distance value sent to the observer. +:math:`Quantize(V,Q)` is as follow: .. math:: @@ -363,11 +392,11 @@ respectively, and This means that players can not know the exact positions of very far objects. -For example, when distance is about 100.0 the maximum noise is about 10.0, -while when distance is less than 10.0 the noise is less than 1.0. +For example, when distance from the focus point is about 100.0 the +maximum noise is about 10.0, while when distance is less than 10.0 the +noise is less than 1.0. -In the case of flags and lines, the distance value is quantized in the -following manner. +In the case of lines, the distance value is quantized in the following manner. .. math:: @@ -375,31 +404,55 @@ following manner. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Visual Sensor Noise Model: Protocol v18 +Visual Sensor Noise Model: Gaussian ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -If players use the protocl version 18, the visual sensor noise model is changed as follows: - -.. .. math:: -.. quantize\_step' = quantize\_step \cdot ViewAngleNoiseTerm +The Gaussian noise model has been introduced in server version 19. +Players can change their noise model by sending ``(gaussian_see)`` +command. +All version players can use this command. +If the command is accepted, rcssserver sent a reply message, ``(ok gaussian_see)``. +In this model, the noised distance in the player's observation is +determined by a Gaussian distribution: .. math:: - p_{rfx} &= p_{xf} - p_{xo} \\ - p_{rfy} &= p_{yf} - p_{yo} \\ - f &= \sqrt{p_{rfx}^2 + p_{rfy}^2} \\ - f' &= \exp({\mathrm Quantize}(\log(f),quantize\_step)) \\ - d'' &= {\mathrm Quantize}({\mathrm max}(0.0, d - (f - f')), 0.1) -.. f' = {\mathrm Quantize}(\exp({\mathrm Quantize}(\log(f),quantize\_step')),0.1) + s &= d \times r_d + f \times r_f \\ + d' &= d \times max(0.0, NormalDistribution(d, s)) + +where :math:`d` is the exact distance from the observer to the object, +:math:`f` is the exact distance from the focus point to the object, +and :math:`d'` is the result distance value sent to the observer. +:math:`NormalDistribution(mean,stddev)` is a random number generator +based on a Gaussian distribution with given mean and standard deviation. +Therefore, the resulting value :math:`d'` is generated from a Gaussian +distribution with mean :math:`d'` and standard deviation :math:`s`. + +:math:`r_d` and :math:`r_f` are the noise rate parameter defined as +heterogenious parameters. +There are four parameters, **dist_noise_rate**, **focus_dist_noise_rate**, +**land_dist_noise_rate**, and **land_focus_dist_noise_rate**. +The former two paramters are used for movable object (ball and +players), and the latter two paramters are used for landmark objects +(flags and goals). +In server version 19, all heterogeneous players use same values +defined in server.conf (:numref:`server-param-gaussian-model`). + -where :math:`(p_{xf},p_{yf})` is the absolute position of the focus point of the observer, -:math:`(p_{xo},p_{yo})` is the absolute position of the observer, -:math:`d` is the exact distance of the observer to the object, -:math:`f` and :math:`f'` are the exact distance and quantized distance -of the focus point to the object respectively, -and :math:`d''` is the result distance value sent to the observer. -This noise model is applied to observations made by players using version 18. -When the observer's focus point is set to the default position (i.e., the observer's position), -this model functions in exactly the same way as the visual sensor noise model in server version 17. +.. list-table:: Server parameters for Gaussian model. + :name: server-param-gaussian-model + :header-rows: 1 + :widths: 60 40 + + * - Parameters in player_type + - Value + * - dist_noise_rate + - 0.0125 + * - focus_dist_noise_rate + - 0.0125 + * - land_dist_noise_rate + - 0.00125 + * - land_focus_dist_noise_rate + - 0.00125