Q1: I wanted more clarification about our deliverables by 19 Nov 2007. Do we need to submit our code or just the paper describing our strategy by 19th Nov? I just wanted to check if we have next month for development or 19th Nov is the deadline for that also.
A1: By 19th Nov, we just need a short paper (up to 4 pages but obviously can be less), formatted as IEEE conf, with the strategy for the design of your robot. It maybe in general lines. Of course the code development can go on until the very day ;-)
However, it would be nice to know that by 19th you already have something moving... but we do not require any code by then. Let us know.
Q2: Will the organization supply separate PCs to run the robots isolated from each other? Or else can we use our own equipment? Are there any restrictions?
A2: We cannot, for the time being, assure the provision of separate PCs to run one robot each. We are trying this, so that every team gets equal processing power. However, this is not critical since any modern machine has way over the required processing power. Therefore, if you can, bring your own equipment (e.g. laptop). If you cannot, let us know in advance.
Q3: The communication with the simulator uses UDP sockets, right? Is there any reliable delivery mechanism?
A3: Yes, the communication is carried out through UDP sockets, and no, there is no special reliable delivery mechanism. However, these can be easily built at the robot control software level. Notice the following:
1- The simulator executes a simulation loop every 25ms (see Q4) and sends all robots a message every such loop with robots sensor readings (with some latencies as specified in the rules).
2- Every message sent by the simulator has the current simulation time in it, which allows robots to detect loss of messages by detecting "jumps" in the interarrival intervals (that should be close to 25ms). In that case, the robot may repeat the previous command, if desired.
3- In some cases, some state variables sent by the simulator allow verifying whether previous commands were properly carried out. For example, after sending a command to light up the LED that signals the end of a run, the robot can check in the following message received from the simulator whether the LED is ON and repeat the command if otherwise.
4- Notice that, when repeating the previous command, as in observation 2 above, the simulation state keeps advancing, anyway. Thus, the previous command may no longer be useful! This is a real-time dilemma (!) that robots must sort out, what to do in case of error? to repeat (based on the previous state), or to advance (wait for the following cycle), this is the question ;-) !!
Q4: What exactly means 25ms simulation cycle?
A4: This means that the simulator executes one simulation cycle every 25ms, i.e.:
1- it reads the latest commands available from the robots,
2- updates their position in the maze,
3- updates and their sensor readings
4- sends the robots a message with such readings

Q5: If my robot sends a message at time=0, "thinks" for 40ms and sends a command at time t=40ms, when will it receive the answer to that command? at time t=50ms or t=65ms?, i.e., the simulator runs a fixed cyclic schedule at 25ms period or does it respond to the robot 25ms after the robot command?
A5: The simulator process is completely independent from the robot processes and uses non-blocking communication. Retentive buffers are used to hold the latest robot commands. In each cycle, the simulator just uses what is available in those buffers (can be read many time!). Commands received from the robots overwrite such buffers.
In the particular situation referred in the question, While the robot is "thinking" the simulator updates the robot position and sensor readings at t=25ms. The command sent at t=40ms will only be considered by the simulator in the cycle that starts at t=50ms.
Q6: The general description refers that the simulator sends the sensor readings and then the robot answers with a command message. Is there a fixed delay? Are these synchronous or asynchronous processes?
A6: As referred in Q5, the simulator and the robots are all independent communicating processes. The most reactive that a robot can be is to send a command every cycle, but it is the same whether the command is sent in the beginning or later in the cycle.
However, for higher efficiency, it may be interesting to synchronize the robot cycle with the simulator cycle. That can be easily achieved using the ReadSensors() C function (see robsample.c) that blocks until a new message is received from the simulator.
Thus, a typical robot control cycle would start with ReadSensors(), follow with its own control strategy, and actuate on the robot using DriveMotors(), etc..
Q7: What does "latency" mean? For example, consider that the robot is at time t=0 is in position (x,y) within the beacon area, but moving with speed w m/s, and then sends a command. Is this command processed while the robot is in position (x,y) or in position (x+dx,y+dy) after the displacement caused by its speed?
In other words, will the simulator say "yes, you are in the beacon area", or will it say "no, you passed the area"?! The first case is not true because the robot actually moved to (x+dx,y+dy). But in the second case, the robot must antecipate when it will arrive at (x0,y0), stop and ask...
A7: The GroundSensor has zero latency, i.e., it refer to the actual simulation cycle. If a request is sent in cycle n, then the answer will be received in cycle n+1, referring to the robot position in cycle n+1. Thus the answer is "no, you passed the area" :( !
For the beacon sensor and compass, whose latency is 9 cycles, the situation is different. A request for the compass reading in cycle n will be answered by the simulator in cycle n+1 but the effective reading is the one captured in cycle (n+1)-9. This means that the reading of these sensors are delayed.
Q8: I have a problem about the GPS of CiberMouse@RTSS2007. When I enable GPS and use the respective functions, they don't return the correct values. What can be wrong?
A8: The GPS is available at debug time, only (not during competition), to allow checking the accuracy of the robot's own localization perception (developed by the robot software). The GPS returns the effective robot position in the maze in each cycle.
When enabling the GPS in the simulator File menu, with the default maze, and connecting your agent, the values returned by the GetX(), GetY() and GetDir() functions should be 4, 9 and 0, respectively.
Probably, you forgot calling ReadSensors() before calling GetX() or any other sensor reading function.
Notice that the robot libraries also use retentive buffers for the sensor readings received from the simulator. The ReadSensors() function is the one that updates these buffers with the latest values received from the simulator. The other specific sensor functions, GetX(), etc., will use the current buffer contents.

Anyway, when you have problems of this kind, please, provide us with the following information:

- Which is your development environment (Linux distribution, gcc version, kernel version)

- Which version of the CiberMouse@RTSS2007 are you using (source code, shared, static)

- Which library interface (C, C++ or Java) is giving you trouble