From: Mahdi <zig...@gm...> - 2009-04-16 08:50:19
|
Hi Actually, I am working on a new simulator<->monitor protocol. A real time one. First of all, I made a list of problems that the current protocol has, and I tried to investigate, whether this protocol can be updated to not have the list of problems, or a new one shall be created. I want everyone comment on the points I mention, so that the new protocol would be a refreshing one. The problems arise in 3 different aspects 1 - Simulator aspect * The simulator sends cycle data every 10 cycles, not every cycle. This means that if the perfect information are sent to trainer, only each 10 cycles there will be such information, and only within that cycles the information are correct. * The simulator sends all the physical data in scene node form. This means that if the position of a player is going to be analyzed, The position and orientation of all the nodes that the player is in, shall be taken in account and at last the players position is calculated. * The simulator sends information only about the nodes that have been changed in the past cycles. Although this is very useful for the current state of simulator which the network traffic is very high, But it also makes very difficult to cycle through simulation cycles, since to get to next or previous cycles, the properties of all objects shall be calculated and evaluated. 2 - Trainer aspect * Current set of trainer commands are very limited, and even lack some functionality. 3 - Log aspect * The logfile of the simulator is actually the whole data that are sent to the monitor, nothing more or less. This makes the logfile very huge. The data are raw, and and even worse, they are in string representation, which consumes even more space. In iranopen games, around 1Gb space were used in the internet server to hold the gzipped packages of the logfiles. * The problem makes another negative point: The WHOLE data is in string form. Take in account the qualification process for teams. They should send logfiles of their teams in play with eg. the third ranking team of the previous tournament. Someone can easily throw a game between two teams, and only change one of the names in the logfile and send it! Considering these points, I thought of updating the current protocol to satisfy a solution to the specified problems. But there was another problem: If the new protocol shall use binary form of communication, then no more the current logfiles can be viewed at later times. This means the history of the 3d soccer simulation, and mainly the start point at which all of it started, will be lost and history won't remember it! Cause the newly updated protocol won't support the features of the previous version of itself. The solution is to create a selectable protocol framework for the simulator. When a monitor/logplayer/trainer connects to the simulator, it shall request a protocol version when connecting. If the monitor does not provide such a version, then the simulator assumes it's the legacy protocol that the monitor can read. This version numbered protocol selection also has another benefit. A typical monitor only needs some part of a cycle's data, but a trainer will need all of the data possible to examine and train the agent's behaviour and skills. With providing this solution, the bandwidth and network latency of connections to the simulator can be drastically reduced. Please everyone provide the MC with other problems that are in your mind, or suggestions to make the protocol better. If anyone can help, surely is appreciated. On Thu, Apr 16, 2009 at 10:50 AM, Hedayat Vatankhah <hed...@gm...>wrote: > Hi Hugo, > > *Hugo Picado <hug...@gm...> <hug...@gm...>* wrote on ۰۹/۰۴/۱۵ > 12:14:03: > > Hi, > > Here is the patch for sensing the ball global position. It works similarly > to the setSenseMyPos. > To apply the patch just run *patch -p0 -i ballsensepos.diff* in top level > directory of your SVN > branch of the simulator. > > To receive the ball global position add the predicate setSenseBallPos to > the file naoneckhead.rsg like: > > (nd RestrictedVisionPerceptor > (setViewCones 120 120) > (setSenseMyPos false) > *(setSenseBallPos true)* > (setStaticSenseAxis false) > (addNoise true) > (setInterval 3) > ) > > Hope it works :) > Hedayat, if you don't mind give me some feedback please. > > Thanks a lot for the patch. I'm a little busy now and I didn't really ran > it, but the patch seems to be OK. :) > But it currently only sends the exact position of the ball, and it is > possible to make it more generic to report the exact position of everything. > > But I'm wondering if we can add debugging facilities a little more > organized (separate from the main protocol for example) and make it more > extendable for future additions. > > I will (hopefully!) start a discussion about this among MC and include you. > BTW, please don't wait for it and let me know about your opinions. :) > > Thanks, > Hedayat > > > > Regards, > Hugo. > > On Tue, Apr 14, 2009 at 5:56 PM, Hedayat Vatankhah <hed...@gm...>wrote: > >> Hi! :) >> >> *Hugo Picado <hug...@gm...> <hug...@gm...>* wrote on ۰۹/۰۴/۱۴ >> 09:19:56: >> >> Hi, thanks for the reply. >> >> Actually, I would like to receive both instead of one of them. >> >> You can't do this currently. I think it is a useful feature too, and it >> is easy to implement. It would be nice if you send us the patch, or I will >> (if I don't forget it!) add it to the next version of rcssserver3d. >> >> Thanks, >> Hedayat >> >> >> For example, I can compute my own position and I can set the predicate >> setSenseMyPos to receive the >> correct global position of the agent. Then I check the error between the >> position computed and the >> correct global position. >> >> I would like to do the same thing for the ball and other players to check >> how far is the agent knowledge from >> the correct information. >> >> Regards, >> Hugo. >> >> On Tue, Apr 14, 2009 at 5:36 PM, Hedayat Vatankhah <hed...@gm...>wrote: >> >>> Hi, >>> >>> *Hugo Picado <hug...@gm...> <hug...@gm...>* wrote on >>> ۰۹/۰۴/۱۴ 07:36:06: >>> >>> Hi, >>> >>> Is there any way to get the perfect ball / opponents position from the >>> message as we can do >>> with the agent's own position (setSenseMyPos predicate) ? >>> >>> Yes, you can change addNoise to false in naoneckhead.rsg. >>> >>> Good luck, >>> Hedayat >>> >>> >>> This could be useful for debugging. >>> >>> Thanks in advance, >>> Hugo. >>> >>> ------------------------------ >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> High Quality Requirements in a Collaborative Environment. >>> Download a free trial of Rational Requirements Composer Now!http://p.sf.net/sfu/www-ibm-com >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> Sserver-three-d mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sserver-three-d >>> >>> > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Sserver-three-d mailing list > Sse...@li... > https://lists.sourceforge.net/lists/listinfo/sserver-three-d > > |