<******************* index ***********************> No | From | Subject | topics ---+----------------------------------------------------------------- 1 | nue@nue.org (Ikuo Takeuchi) | Proposals for RoboCupRescue 2002 regulations (First draft) | simulators (traffic, blockade, fire, miscellaneous, civilian, kernel 2 | nue@nue.org (Ikuo Takeuchi) | Re: Proposals for RoboCupRescue 2002 regulations (First draft) | announcement of an error in mail 1. 3 | Emmanuel Koch | Proposal : number of messages | message 4 | nue@nue.org (Ikuo Takeuchi) | 2002 League regulation (on messages) | message 5 | Emmanuel Koch | Re: Proposals for RoboCupRescue 2002 regulations (First draft) 6 | NODA Itsuki | Re: 2002 League regulation (on messages) 7 | NODA Itsuki | A proposal of Civilian | civilian, ACL 8 | Fumitoshi Matsuno | A proposal of MAP | GIS 9 | nue@nue.org (Ikuo Takeuchi) | On 2002 proposals <******************* 1 ***********************> Date: Tue, 27 Nov 2001 19:55:36 +0900 (JST) From: nue@nue.org (Ikuo Takeuchi) To: r-resc@ISI.EDU Subject: Proposals for RoboCupRescue 2002 regulations (First draft) Dear RoboCup Rescuers, [The following proposals are a little updated version which we posted in Japanese at this noon.] We propose the following improvement of the RoboCupRescue regulations for the 2002 League. T. Morimoto is now remaking the problematic traffic simulator in Java from scratch. He does take only a couple of days to get the new simulator to start running! We hope the 2002 League will use this new traffic simulator. But we welcome criticisms and discussions. We expect agent developers will not be much affected by this change. But it will be useful to know the internal model of Morimoto traffic simulator. So we describe it in some details. Other than the traffic simulator, we propose improvement of some rules related to the blockade simulator, fire simulator, miscellaneous simulator, civilian agents, and kernel. So far, almost all proposals are proved to be feasible for implementation; it has been clarified where and how program code should be changed. These proposals will resolve almost all problems revealed in the 2001 League, we hope. Note that our proposals are only related to the Version 0 Simulation System, not the Version 1, which will be used from the 2003 League. I. Traffic Simulator Command level compatibility with the current traffic simulator is most significantly regarded on remaking the simulator. However, a few may affect agent developers in conjunction with their movement strategy. So we describe the internal modeling of the traffic simulator in some details. Morimoto is now working to make the modeling more precise and rigorous. It will be soon reported. (1) There are traffic lanes on every road. We wish the viewer can display lanes if required (Morimoto's simple viewer can display them individually discriminating passable or blocked). If one of the lanes, usually outer lane, is blocked, a car on the lane should change the lane at the blockade. A car selects the lane randomly except for its target road. (2) Signal lights and restrictions on left or right turn are not considered. All signal lights are turned off in the disaster. We propose to restrict in the Version 0 that cars in the map are only for polices, ambulances and fire brigades. No civilian agent drives a car. So we need not consider these restrictions. (3) Central strip of a road and width of a side walk are not considered. The current simulator also ignores them. (4) The velocity of a car is calculated on the following model at every second (or at every t seconds, where t is a divider of 60). A car moves at the highest possible speed, keeping a safe distance from an object before it, so that, typically, distance between the successively running cars equals to the moving distance. dx = forward.x - x; /* distance from the forward object */ A = MAX_ACCELERATION; B = MIN_SAFE_DISTANCE(forward.ObjectType); double a = (dx >= B) ? A * (Math.sqrt(1 + 2 * (dx - B) / A) - 1) - v : 0; /* - v for braking distance */ if (a > MAX_ACCELERATION) a = MAX_ACCELERATION; double result = v + a; if (result > MAX_VELOCITY) result = MAX_VELOCITY; return result; A car should stop if it encounters one of the following objects. Stopped moving object such as fire brigade now busy in extinguishing or ambulance now digging buried civilian. Node at which the target building stands. Crosspoint where the road in front of the car is wider than or equal to the road on which the car is now moving and exiting. (If there are more than one car at a crosspoint of roads of same width, which car starts first is randomly selected.) Blockade by debris on the road, which is located at the midpoint of the road. MAX_ACCELERATION is determined so that a car gets to its maximum speed within 5 seconds. (5) A blockade is assumed to be located at the midpoint of a road, so that agents can see it even if the road is longer than 20 meters (double of agent's sight range). (6) An agent can stop at any node or at any point of a road. However, it is assumed that an agent can stop at a node only if it is the target of the agent (otherwise, it can stop on a node only incidentally by the double floating arithmetics). So protocol for agent movement commands is not changed. *** For implementation clarity, additional remark may be proposed in a few days, in conjunction with the case a number of cars want to move to a same target *** (7) Any building can be immediately entered when an agent reaches the associated node, because there is no means to represent an intermediate position between the node and the entrance. (8) A car can stop immediately in a turn. That is, the traffic simulator tries to simulate the traffic smoothly at every second as far as possible, but it cannot cope with a sudden agent decision to stop at a location at the beginning of the next turn, so that a car running at its top speed till 59th second seems to stop at 60th second suddenly. However, from the viewpoint of a minute-level resolution observer, it can be understood that a car which finds something urgent over-accelerates at the last moment and makes full braking in a violent but physically admissible manner. This phenomenon rises from the resolution discrepancy between the traffic simulator and the whole simulation system of Version 0. (9) Civilians do not either use cars or run in the terrible disaster; they walks. There are alternative two plans, but the latter plan 2 is desirable. (plan 1) Civilian's walk is independent of car traffic. (plan 2) Cars for rescue are prioritized in the traffic, so civilians have to stop to cross a road if such cars are passing the road. Civilian can walk at 4km/h, or it stops (i.e., 0km/h). We hope civilians should turn if they encounter a blockade. (10) When an agent finds it cannot move as it desires, it can get the reason by sensing the visual information supplied by the kernel. Currently, an agent cannot know by which reason it cannot enter a long road, traffic jam or blocked. In addition, the new traffic simulator will provide information why it cannot move to its target on a tracing file for agent developers' debugging convenience. (11) The format of positionHistory of an agent will be changed so that it represents the full transport path of the agent in the last turn, or empty if the agent didn't move. (If the viewer depends strongly on the current format, we will not change the format, however.) (12) A building cannot be passed through, at least, by a car. The current GIS does not include a building with more than one entrance (certified by S. Endo). Alternative idea is that a building which can be passed through can have more than one entrance. [GIS matter] (13) The maximum speed of a car is lowered from 57km/h to 30km/h or 40km/h, which is more natural in the disaster environment. (14) If a car wants to turn back when it encounters blockade or something, it has to stop and then turn. If a car wants to change the lane, it has to make sure there is no car moving behind the target lane. If there is one, it has to stop and then change the lane. (15) Currently unused positionOffset is validated in order to locate agents more precisely on a road. This will necessitate a little change in the kernel. We certified no other simulators use positionOffset. II. Blockade Simulator There is one unnatural point in this simulator. We propose to modify it as follows. The modification point is known. (1) Let repairCost be proportional to the road length, that is, blockade on a longer road takes much time to remove. repairCost = (block * roadLength + (CONST - 1)) / COSNT where, for example, CONST = 10000 * 2000 To maintain the compatibility, CONST will be determined so that typical blockade on a 2m wide and 10m long road takes one minute. (It seems still too short but it is a typical value of the current simulator.) III. Fire Simulator In the current fire simulator, water quantity 1000 (= extinguishing power) has drastically different power than 999; that is, 999 water has no effect for extinguishing. This is a known bug. But even if the bug is fixed, it does not yield any interesting AI problem, because there is no limitation of total water supply in the Version 0. A fire brigade can always use maximum amount of water if it wants. However, we propose the following complication in the Version 0 simulator. (1) Multiple Hoses to different directions (proposed by S. Kanazawa) A fire brigade can extinguish two fires simultaneously by splitting its extinguishing power 1000 into two 500's. Extinguishing power 500 is not enough for a big fire, but efficient for an early small fire. So if a fire brigade decides to split its extinguishing power for near two early fires, it can extinguish both fires twice as quick as it cascades the full power to the both. This improvement needs further investigation of the program code, though we already found some of relevant places. IV. Miscellaneous Simulator This simulator governs the destiny of the victims. This is suspected to be a source of the known low repeatability of the total simulation result. Damages of buried victims are fluctuated by using random numbers throughout the simulation. So, if an ambulance helps a victim, this randomness affects other buried people's destiny. We propose to eliminate this kind of random function usage in several places of the miscellaneous simulator to stabilize the result, so that, in principle, initial setting determines all victim's damage history other than that caused by fire. (In our primary experiment, simulation results become more stable.) In addition, we propose the following: (1) An ambulance can AK_RESCUE or LOAD a victim on the same place or near position in a neighbor place (Here, place denotes road or node). Currently it is allowed to do so only for a victim on exactly the same place. (2) A damaged rescue agent cannot immediately restart its activity even if it has run into a refuge or hospital. How long it cannot restart depends on the amount of damage; for example, time for restart = damage when it runs into refuge / CONST where CONST is adjusted so that seriously damaged agent can restart at least after 10, or more plausibly 20 turns. V. Civilian Agents The current civilians are too verbous and stupid to be rescued. We propose a new set of civilians which is now being developed by K. Shinoda, or if it can't be in time, simple civilians developed by T. Koto. VI. Kernel There are a few problems that can be coped with only by changing the kernel. We propose the following. Agent developers who utilized the "hole" of the kernel must be careful. All changes are declared to be feasible by T. Koto, the kernel developer. (1) An early fire cannot be discovered immediately by a distant fire brigade; that is, it takes a couple of turns for a fire brigade to discover a distant early fire. An early fire more than, say, 100m far away takes 2 or 3 turns to be discovered. However, the current kernel structure has little room to realize this change in a full specification. So, we propose that an early fire at clock 0 can be sensed by a fire brigade more than 100m far away, only after clock 3 or 4. (2) Any agent cannot know other agent position at the beginning. (The current regulation is unbelievably unusual!) (3) Any agent cannot know other agent positionHistory. (This is a little controversial, but if we want to allow an agent to know another agent's most recent positionHistory within the sight range of the agent, the kernel has to do a big work to cut off invisible part of the positionHistory.) (4) So called "start dash" is inhibited. That is, no agent can run through the road before it is blocked at clock 0. (This is a sort of bug of the kernel.) Tetsuhiko Koto, Takeshi Morimoto, Sin'ichi Miyazawa, Satoshi Endo, Susumu Kanazawa, Tomoyuki Takai, Prof. Ikuo Takeuchi Takeuchi Lab in the University of Electro-Communications <******************* 2 **********************> Date: Tue, 27 Nov 2001 20:08:18 +0900 (JST) From: nue@nue.org (Ikuo Takeuchi) To: r-resc@ISI.EDU Subject: Re: Proposals for RoboCupRescue 2002 regulations (First draft) There are typos in the previous proposals. > (15) Currently unused positionOffset is validated in order to locate > agents more precisely on a road. This will necessitate a little > change in the kernel. We certified no other simulators use > positionOffset. Here, positionOffset should be positionExtra. Tak (NUE) <******************* 3 *********************> Date: Tue, 27 Nov 2001 16:41:27 -0500 From: Emmanuel Koch Reply-To: ekoch@info.fundp.ac.be To: RoboCup Rescue Subject: Proposal : number of messages I have a proposal about messages... I think that the Center Agents (FireStation, AmbulanceTeam and PoliceOffice) should have more than 4 messages to say for one minute. If it's judicious to keep few messages for other agents, a center who organise the team must have more than one standardist. I think that a restriction of 4 messages is too hard for a center...! For example, (as in the reality), the center have to organise all their teams... So if each agent says its position to the center, the center should be able to cope with the 10 messages because in one center, there are more than one person on the telephone, and others more to give orders. For proposal, team agents can keep 4 messages (4 simple sentences. Need to be defined... ), and centers can handel, or at least hear, between 10 to 20 messages for one minute... What do you think about it? -- ====================== Emmanuel Koch, 3.AŽème maŽîtrise en informatique Labo. Damas,DŽépartement Informatique, Pav. PLT, UniversitŽé Laval, Ste-Foy, QuŽébec (Canada), G1K 7P4 ====================== Namur-LUG : http://www.namurlug.org <******************* 4 ********************> Date: Thu, 29 Nov 2001 20:24:01 +0900 (JST) From: nue@nue.org (Ikuo Takeuchi) To: r-resc@ISI.EDU Subject: 2002 League regulation (on messages) Dear RoboCup Rescuers, After we proposed some rule changes on Nov 27th, we continued the discussion on the 2002 League regulation and have got other proposals on messages. These require very small change of the kernel program, as certified by T. Morimoto, but require some changes of all agent teams. Criticism and discussion are welcome. In the current rule, each agent can tell or say up to four sentences in a cycle (minute), and can hear up to four sentences in a cycle. As Emmanuel pointed out, no center agent can function well under this restriction as expected. A center agent should have the function to organize gathered information and propagate only important (or edited) information to other center agents and its platoon agents. However, it is reasonable to restrict the number of tell/say messages issued by a center agent in a cycle as much as its platoon agents, because its platoon agent can hear only four messages. In addition, the definition of a sentence should be defined more strictly. The following is the detail of our proposals. (1) A center agent can hear up to N sentences in a cycle, where N = 2 * (number of its platoon agents). So the center agent can play more important role. To sum up, | AK_TELL/SAY | AK_HEAR --------------+-------------+--------- Platoon agent | 4 | 4 Center agent | 4 | 20 or 10* (* 20 for fire station and police station, 10 for ambulance center) (2) Each agent must completely discard the messages it decides not to hear. Do not use the information WHO spokes and WHO does not speak. (3) A sentence should conform to the following format: int id int msgSize char* msg which is not different from the current one of the AK_TELL/SAY's message, for the compatibility reason, but the contents of msg is limited. (3-1) The id field must be the ID of the sender. (3-2) The msgSize and msg is ether one of: +---+---+---+ | 2 | k | k | (2kk format) +---+---+---+ or +---+---+---+---+---+---+---+---+---+---+---+---+---+ | 12| k | k | i | i | i | i | i | i | i | i | i | i | (12kkID format) +---+---+---+---+---+---+---+---+---+---+---+---+---+ where k's and i's are digits from 0 to 9 (ASCII codes 0x30 to 0x39). Two digit number kk denotes the kind of sentence, which can be freely defined by the agent developer. So at most 100 kinds of sentences can be uttered in a team (maybe enough for the Version 0). 2 and 12 are integers denoting the message length (msgSize). Ten digits number iiiiiiiiii denotes the ID of an object or an agent existing on the map. The kernel does not check the validity of the denoted ID at run time. However, we hope no one would represent something else by this ten digit number. If a sentence does not include an ID, the former simple 2kk format should be used. (3-3) All agent developers are expected to disclose the coding scheme of the "kk" field with their program, say, as follows: #define MSG_BLOCK_ROAD 01 // The road[id] is blocked #define MSG_INJ_POSITION 02 // A civilian is injured at Place[id] Tak (NUE) with T. Morimoto The University of Electro-Communications <******************* 5 *******************> Date: Thu, 29 Nov 2001 13:25:43 -0500 From: Emmanuel Koch To: RoboCup Rescue Subject: Re: Proposals for RoboCupRescue 2002 regulations (First draft) Ikuo Takeuchi wrote: > Dear RoboCup Rescuers, > > [The following proposals are a little updated version which we posted > in Japanese at this noon.] > A car should stop if it encounters one of the following objects. > > Stopped moving object such as fire brigade now busy in extinguishing > or ambulance now digging buried civilian. Just a remark on this point: Can several fire brigade be on the same road/node with this rule? Same question for ambulance team : does the rule let several ambulances digging together (at the same place)? Because if it's as the current version of simulator, where no agents can go on a blocked road, it will be impossible for many AT to dig at the same place... -- ====================== Emmanuel Koch, 3Žème maŽîtrise en informatique Labo. Damas,DŽépartement Informatique, Pav. PLT, UniversitŽé Laval, Ste-Foy, QuŽébec (Canada), G1K 7P4 ====================== Namur-LUG : http://www.namurlug.org <******************* 6 ******************> Date: Fri, 30 Nov 2001 03:55:32 +0900 From: NODA Itsuki To: rescue@r.cs.kobe-u.ac.jp Cc: r-resc@ISI.EDU, nue@nue.org (Ikuo Takeuchi) Subject: [rescue:4802] Re: 2002 League regulation (on messages) I> After we proposed some rule changes on Nov 27th, we continued the I> discussion on the 2002 League regulation and have got other proposals I> on messages. These require very small change of the kernel program, I> as certified by T. Morimoto, but require some changes of all agent I> teams. Criticism and discussion are welcome. I have a question about the language used in the message. Is this restriction only for rescue agents, or for all agents that include civilian agents? --Itsuki <******************* 7 *****************> Date: Fri, 30 Nov 2001 04:53:09 +0900 From: NODA Itsuki To: r-resc@ISI.EDU Cc: rescue@r.cs.kobe-u.ac.jp Subject: [rescue:4804] A proposal of Civilian Dear RoboCupper, I like propose new civilians for RoboCup-2002. Basically, the behaviors are based on the current civilians (RoboCup-2001). We are trying to re-write the code using a kind of rule-base behavior engine for the future development. Also, it uses new syntax of ACL. Here is a proposal. --Itsuki ---------------------------------------------------------------------- %% -*- Mode: Memo -*- [] A proposal of Behaviors of Civilian Agents Civilian agents are consists of three groups, selfish agents, obedient agents, and volunteer agents. Behaviors of those agents are based on civilian agents used in RoboCup 2001, and re-written using a rule-base behavior engine. The rule-base behavior engine generates behaviors based on multiple scenarios, which is a set of rules and state-transitions. The details of behaviors of each type of agents are as follows: %%---------------------------------------------------------------------- [.] Selfish Agents Selfish agents behaves only based on their own sensing information. So, the agents do not take care about messages from other agents. [..] Building Scenario If the agent is in a building, then it tries to evacuate from the building. After for a while (10 minutes) after the evacuation, if the building looks safe, the agent try to go back into the building to pick-up important things in a certain possibility (20%). [..] Refuge Scenario Do nothing for a while (10 minutes) in a state of shock. If the agent can see a refuge, then move to the refuge. If the agent knows the direction of refuge, then move toward the direction. If the agent does not know the refuge, then try blind-search. When the agent arrives to the refuge, stay there until end of the simulation. [..] Avoiding-Fire Scenario If a fire is near of the agent (within 5m), then try to escape from the fire. [..] Looking-Fire Scenario Do nothing for a while (10 minutes) in a state of shock. If a fire is relatively near of the agent (5m to 20m), then stay there for a while (10 minutes) in a certain possibility (50%). [..] Cry-Help Scenario If the agent is buried, then cry "help!" in a certain interval (once in 3 minutes.) The syntax of the message is as follows. %%---------------------------------------------------------------------- [.] Obedient Agents Obedient agents have a behavior to follow requests by rescue agents in addition to the selfish agents. [..] Obey Scenario Do nothing for a while (10 minutes) in a state of shock. When a rescue agent say a request message to move, then the civilian agent tries to obey the move request. The rescue agent can specify the direction of the move by roads, nodes (crossings), and refuges in sight of the civilian agent. The syntax of the message is as follows. %%---------------------------------------------------------------------- [.] Volunteer Agents Volunteer agents have a behavior to inform a rescue agents about the location where they heard "help" messages. [..] Inform-help Scenario Do nothing for a while (10 minutes) in a state of shock. When the agent hear "help" message, it memories the current location. When the agent meets a rescue agent, then it says the location of the message. The agent stop to inform after informing N times (N = 2) or a certain duration (120 minutes). %%====================================================================== [.] Syntax of Message [..] help (request :sender (agent :id 100) :receiver (agent :tid T1) :content (do :action (help) :object (agent :id 100))) (request :sender (agent :id 100) :content (do :action (help) :object (agent :id 100))) [..] request to move (request :sender (agent :id 100) :receiver (agent :id 200) :content (do :subject (agent :id 200) :action (move) :destination LOC)) where LOC ::= (road :from 150 :to 250) | (node :id 150) | (refuge :id 300) [..] inform the location of help (inform :sender (agent :id 100) :receiver (agent :id 200) :content (do :subject (agent :id 100) :action (hear) :content (help) :location LOC :time 1200)) LOC ::= (road :from 150 :to 250) | (node :id 150) | (building :id 300) ---------------------------------------------------------------------- NODA Itsuki, Dr. Eng. Senior Research Scientist Cyber Assist Reseach Center National Institute of Advanced Industrial Science and Technology 2-41-6 Aomi, Koto-ku, Tokyo 135-0064, JAPAN Tel. +81-3-3599-8296 Fax. +81-3-5530-2067 <******************* 8 ****************> To: r-resc@ISI.EDU Subject: [rescue:4815] A proposal of MAP From: Fumitoshi Matsuno We would like propose new maps for RoboCup-2002. As RoboCup-2002 will be held in Fukuoka, we propose a map of Fukuoka city. We should prepare different maps for each level of matches. So we also propose a map of virtual city. Combining different basic components of it we can make many different maps easily. The database structure and foramt are same as the current map (RoboCup-2001). Best regards, Fumitoshi Matsuno (Tokyo Institute of Technology) Michinori Hatayama (Kyoto University) Hironao Takahashi (National Institute for Land and Infrastructure Management) <******************* 9 ***************> Date: Sat, 1 Dec 2001 13:27:00 +0900 (JST) From: nue@nue.org (Ikuo Takeuchi) To: r-resc@ISI.EDU Subject: On 2002 proposals Hi, Emmanuel wrote: > > Ikuo Takeuchi wrote: > > A car should stop if it encounters one of the following objects. > > > > Stopped moving object such as fire brigade now busy in > > extinguishing or ambulance now digging buried civilian. > > Just a remark on this point: > > Can several fire brigade be on the same road/node with this rule? > Same question for ambulance team : does the rule let several > ambulances digging together (at the same place)? Because if it's as > the current version of simulator, where no agents can go on a > blocked road, it will be impossible for many AT to dig at the same > place... Don't worry. In our new traffic simulator now under development, there are both cases that agents can be on the same point and that they can not. But if they can not be on the same point, it is a case they need not be or it is unrealistic. Note that the new traffic simulator uses the parameter positionExtra explicitly so that exact point of an agent on a road is calculated every second. The number of agents which can be on the same point on a road (or node) is the number of lanes. (We say the points on a road equally distant from a node but on different lanes are the same point, here.) The number of lanes of a crosspoint is the total number of lanes coming out from and in to the crosspoint. On the same lane, agents can be positioned a little apart from each other. However, there is no limitation on the number of agents (mostly ambulance teams) in a building. Therefore, if a road are long and has many lanes, more than one agent can be on the road nearby each other. However, a narrow road or crosspoint would easily cause a traffic jam. A blockade on a road is assumed to be located at the midpoint in our model, so agents can move close to the blockade. Since fire brigades can spray water 30m far, they need not to be exactly on the same point. It is, however, unrealistic that many big fire engines can gather very closely on a narrow road. Since a police agent can clear a blockade on a narrow road in one or two turns, they also need not gather on a narrow road. But they can cooperate to clear a big blockade on a wide road. As was said earlier, there is no limitation on the number of ambulances in a building. Several ambulance teams can gather in the same building, and dig and save wounded people more quickly. Wounded person on a road is not buried, it is easy to load him/her. If there are many wounded people on a narrow road, ambulance teams should cooperate to save them smoothly with causing traffic jam. Noda wrote: > I have a question about the language used in the message. > Is this restriction only for rescue agents, or for all agents > that include civilian agents? It is a good news that new civilian speaks ACL. We don't think civilians are limited by our proposal. Agent developer can freely exploit their messages. However, there is little time to specify an ACL that rescue agents must speak for 2002 League. (We think the ACL proposed by Noda is too informative for rescue agents to speak with telecommunication devices, cosidering the very simple and narrow area of the current simulation field.) We have to start as quickly as possible to make new regulations on the message of rescue agents for 2003 League. Without such a common language, agents developed by different programmers over the world cannot join to work together. In Japan, there are some hot mail discussions on the objective of RoboCupRescue simulation. We also think the RoboCupRescue simulation is not simply a game. It should be useful finally to mitigate the disaster in a more realistic sense. I should have more links to real disaster situation and real human decision. However, our current technology is too low to commit immediately on such matters. So, for example, 2002 League is deemed as our current state of the art. It is, however, still useful in some sense, say, for understanding our current human resue system, for illuminating people who are afraid of coming disasters, and for providing researchers on multi-agent systems with a good research platform. morimoto and Tak (NUE)