File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/01/w01-1301_metho.xml
Size: 27,276 bytes
Last Modified: 2025-10-06 14:07:43
<?xml version="1.0" standalone="yes"?> <Paper uid="W01-1301"> <Title>Generating a 3D Simulation of a Car Accident from a Written Description in Natural Language: the CarSim System</Title> <Section position="3" start_page="0" end_page="0" type="metho"> <SectionTitle> 2 Formal Representation in CarSim </SectionTitle> <Paragraph position="0"> \VPehicule B venant de ma gauche, je me trouve dans le carrefour, a faible vitesse environ 40 km/h, quand le vPehicule B, percute mon vPehicule, et me refuse la prioritPe a droite. Le premier choc atteint mon aile arri ere gauche, sous le choc, et a cause de la chaussPee glissante, mon vPehicule dPerape, et percute la protection mPetallique d'un arbre, d'o u un second choc frontal.&quot; Text A4, MAIF corpus.</Paragraph> <Paragraph position="1"> \I was driving on a crossroads with a slow speed, approximately 40 km/h. Vehicle B arrived from my left, ignored the priority from the right and collided with my vehicle.</Paragraph> <Paragraph position="2"> On the flrst impact, my rear fender on the left side was hit and because of the slippery road, I lost control of my vehicle and hit the metallic protection of a tree, hence a second frontal collision.&quot; Text A4, MAIF corpus, our translation.</Paragraph> <Paragraph position="3"> The text above is an accident report from the MAIF1 corpus, which contains 87 texts in French. It is a good example of the possible contents of an accident description: a rather complex interaction between a set of difierent objects (two cars and a tree). This section describes the formal representation used in the CarSim system. The example of Text A4 will be explained with more details in Section 2.5.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.1 The General Accident Model </SectionTitle> <Paragraph position="0"> In CarSim, the general accident model consists of three lists of objects: motionless objects (STATIC), moving objects (DYNAMIC), and flnally collisions (ACCIDENT).</Paragraph> <Paragraph position="1"> STATIC and DYNAMIC lists describe the general environment in which the accident takes place. Knowing them, the accident itself is the only remaining item to determine. Using manual simulation, we realized that most accidents in the corpus could be framed using an ordered list of collisions2. Each collision is represented by a relation between two objects either in DYNAMIC</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> and/or STATIC lists 2.2 Static Objects </SectionTitle> <Paragraph position="0"> In general, a static object can be deflned with two parameters: one deflning the nature of the object and another one that deflnes its location. In Car-Sim, a static object can be either a road type or an object that can participate in a collision (e.g.</Paragraph> <Paragraph position="1"> a tree). In the formal description, a reference to the latter kind of object can occur in a collision speciflcation. This is why these static objects are deflned with an identity parameter (ID).</Paragraph> <Paragraph position="2"> Concerning ROAD objects, their nature is specifled in the KIND parameter. The possible KIND values in the present prototype are: crossroads, straightroad, turn left, and turn right.</Paragraph> <Paragraph position="3"> TREEs, LIGHTs (tra-c lights), STOPSIGNs, and CROSSINGs (pedestrian crossings) are the other possible static objects. Their location is given by the COORD parameter. Since trees and tra-c lights can participate in collisions, they also have an ID, that allows further references. Finally, tra-c lights contain a COLOR parameter to indicate the color of the light (red, orange, green or inactive).</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.3 Dynamic Objects </SectionTitle> <Paragraph position="0"> Dynamic objects cannot be deflned by giving only their nature and position. Rather than the position, the movement of the object must be deflned.</Paragraph> <Paragraph position="1"> In the CarSim formal representation, each dynamic object is represented by a VEHICLE, with a KIND parameter indicating its nature, (car or truck) and a unique identifler ID. The movement of a dynamic object is deflned by two parameters. The INITIAL DIRECTION deflnes the direction to which the object is headed before it starts driving (north, south, east, or west). The second parameter is an ordered list of atomic movements that are described by EVENTs. This list is called the event chain and corresponds to the CHAIN parameter. KIND specifles the nature of each event. At present, CarSim recognizes the following events: driving forward, stop, turn left, turn right, change lane left, change lane right, overtake.</Paragraph> <Paragraph position="2"> Figure 2 shows the motion of a dynamic object with KIND = car, INITIAL DIRECTION = East and CHAIN =<driving forward, turn left, driving forward>.</Paragraph> <Paragraph position="4"> ward, turning left and driving forward with an initial direction to the East.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.4 Collisions </SectionTitle> <Paragraph position="0"> As we said before, the accident is described by an ordered list of collisions. The order of the collisions in the list corresponds to the order in which they take place in the accident simulation.</Paragraph> <Paragraph position="1"> A collision is deflned by giving the two objects that participate in the collision and some additional attributes. At present, these attributes are the collision coordinates and the parts of the vehicles that are involved in the collision (participating parts).</Paragraph> <Paragraph position="2"> There is a slight distinction between the vehicle that collides (in other words: the actor) and the vehicle that is hit (the victim). For planning reasons (and also for linguistic grounds) it is useful to maintain this distinction in the formalism.</Paragraph> <Paragraph position="3"> To summarize, a collision occurs between an actor and a victim. The victim can be either a static or a dynamic object, the actor clearly has to be a dynamic object. The notions of actor and victim are not related with the responsibility of one particular vehicle within the accident. This kind of relationships must be deduced from a complex responsibilities analysis, that could be based on the tra-c rules.</Paragraph> <Paragraph position="4"> Next to the location (coordinates) of the collision, something has to be said about the conflguration of the objects while colliding. The participating parts are sometimes given in the text, see for example Text A4 at the beginning of this section. The CarSim system uses a simplifled model of these vehicle parts. They are divided in four categories: front, rear, leftside, and rightside, plus one unknown category.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 2.5 An Example </SectionTitle> <Paragraph position="0"> In order to give an example of a formal accident description and also to introduce the linguistic part, we will give now more details about the manually written FD of Text A4.</Paragraph> <Paragraph position="1"> In a written text, information can be given either explicitly or implicitly. Besides, the contents of implicit information difiers in each text. In Text A4, what information can we directly gather from the text? Text A4 describes an accident with two collisions, involving two vehicles and a tree. It takes place at a crossroads. The flrst collision involves two vehicles. One of them is referred to as the \vehicle B&quot;, the other is the narrator's vehicle (\my vehicle&quot;). From now on, vehicles will be called vehicleB and vehicleA respectively. The second collision involves vehicleA and the tree. In the FD, the tree is identifled in a unique way as tree1. From this information, we already know how many objects will be needed to describe the accident: two static objects (a crossroads and a tree tree1), two dynamic objects (vehicleB and vehicleA) and flnally two collisions.</Paragraph> <Paragraph position="2"> The text does not mention any special behavior of the two vehicles. They are both driving when the accident occurs. Hence, the event chain is the same for both vehicles, a single driving forward event.</Paragraph> <Paragraph position="3"> The roles played by the vehicles in each collision are also given. As human beings, we deduce them from the grammatical functions of the noun groups or pronouns referring to the vehicles in the sentences where collisions are described. In the flrst collision, the actor is vehicleB and the victim vehicleA (respectively, subject and object of the verb \percuter&quot;, \to collide with&quot; in the translation). In the second one, the actor is vehicleA and the victim tree1.</Paragraph> <Paragraph position="4"> The parts of the vehicles that participate in a collision are sometimes explicitly given in the report, as for example for vehicleA in Text A4.</Paragraph> <Paragraph position="5"> In the flrst collision, the impact occurs at the rear left-hand side of the vehicle (\On the flrst impact, my rear fender on the left side was hit&quot;) and in the second one, vehicleA hits the tree with the front of the car (\hence a second frontal collision&quot;).</Paragraph> <Paragraph position="6"> Actually, we don't know whether the vehicles in the text are cars, trucks or something else. As no precise information is explicitly given in the text, we simply assume that these vehicles are cars3. The type of vehicles is not the only implicit piece of information in the text. The initial directions of the vehicles are only known relatively to each other. We know that vehicleB is coming from the left-hand side of vehicleA (\Vehicle B arrived from my left&quot;) and if we arbitrary decide that vehicleA starts heading to the North, then vehicleB has to start heading to the East. The same fragment of the text gives us the participating part of vehicleB. Since the participating part of vehicleA in the flrst collision is leftside, we can conclude that vehicleB's part is front. The tree has no particular participating part. Thus, it will be deflned as unknown but we can assume that the impact occurs with the trunk because all the scene takes place in a two-dimensional plane.</Paragraph> <Paragraph position="7"> Below is the formal description of Text A4 that can be given to the simulation module of CarSim:</Paragraph> <Paragraph position="9"> The only information we did not discuss yet are the coordinates of static objects and impacts. Co-ordinates are numbers. They are never explicitly given in the text and obviously, even if some numbers appeared in the text, the semantic of these numbers would be implicit too. CarSim assumes that coordinates (0,0) are the center of the scene.</Paragraph> <Paragraph position="10"> In Text A4, the origin is the center of the crossroads. The flrst collision occurs in the crossroads, hence the coordinates will be close to the origin.</Paragraph> <Paragraph position="11"> The coordinates of the tree are chosen so that they match the idea of the scene as a reader could imagine it. They also depend on the size of the graphical objects that are used in the 3D scene (e.g. the size of the roads).</Paragraph> </Section> </Section> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 3 The Information Extraction Task </SectionTitle> <Paragraph position="0"> The flrst stage of the CarSim processing chain is an information extraction (IE) task that consists in fllling a template corresponding to the formal accident description (FD) described in Section 2.</Paragraph> <Paragraph position="1"> Such systems have been already implemented, as FASTUS (Hobbs et al., 1996), and proved their robustness. Our information retrieval subsystem is restricted to car accident reports and is goaldriven. The main idea is to start from a default description, a pre-formatted FD, that the IE task alters or reflnes using inference rules. Hence, the default output will be a well-formatted FD, describing a collision between two cars, even if the given text is a poem.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.1 Parsing </SectionTitle> <Paragraph position="0"> The flrst step of the information extraction process is a lexical analysis and a partial parsing. The parser generates tokenized sentences, where noun groups, verb groups, and prepositional groups are extracted. The parser uses DCG rules (Pereira and Shieber, 1987) and a dictionary containing all the words that occur in the corpus.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.2 Extracting Static Objects </SectionTitle> <Paragraph position="0"> The formalism describes two types of static objects: the type of road (the road conflguration) and some other static objects (stop signs, trafflc lights, pedestrian crossings and trees). The method used to extract these objects consists in looking up for keywords in the tokenized text.</Paragraph> <Paragraph position="1"> The extraction of static objects is done at the beginning of the information extraction task. We realized that the road conflguration is the most relevant piece of information in the description of an accident, since it conditions all the following steps (see Section 3.4 for further explanations).</Paragraph> <Paragraph position="2"> The formalism considers four difierent conflgurations: straightroad, crossroads, turn left, and turn right. In the present system, we restricted it to three types of road: + crossroads, indicated by cue words such as \carrefour&quot;, \intersection&quot;, \croisement&quot; (crossroads, intersection, junction).</Paragraph> <Paragraph position="3"> + turn left, with cues such as \virage&quot;, \courbe&quot;, \tournant&quot; (bend, curb, turn).</Paragraph> <Paragraph position="4"> We assume that turn left and turn right are equivalent.</Paragraph> <Paragraph position="5"> + straightroad, that corresponds to the situation when none of the previous words have been found.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.3 Extracting Collisions </SectionTitle> <Paragraph position="0"> A collision consists of a verb, an actor, a victim and of the participating parts of the two vehicles. We select verbs describing a collision such as \heurter&quot; (\to hit&quot;), \taper&quot; (\to bang&quot;), \percuter&quot; (\to crash into&quot;), \toucher&quot; (\to touch&quot;),...</Paragraph> <Paragraph position="1"> For each extracted verb, the system checks whether the verb group is in passive or active form, then identify the related grammatical relations: subject-verb and verb-object or verb-agent. Extraction techniques of such dependencies have already been implemented, as in (A~++t-Mokhtar and Chanod, 1997). Our system uses three predicates in order to flnd the subject (flnd subject) and either the object (flnd object) or the agent (flnd agent) of the verb. If the verb is in an active form, it makes the assumption that the subject and the object of the verb will be respectively the actor and the victim of the collision. In the case of a passive form, the subject will be the victim and the agent, the actor.</Paragraph> <Paragraph position="2"> Below is the sketch of the algorithm of these three predicates: + flnd subject looks for the last noun group before the verb that describes a valid actor, that is a vehicle or a personal pronoun like \je&quot; (\I&quot;), \il&quot; (\he&quot;), or \nous&quot; (\we&quot;) . + flnd object starts looking for the flrst noun group after the verb that describes a valid victim, that is both vehicles and static objects. If no valid victim is found, it searches for a re exive or personal pronoun inside the verb group. In case of failure, the flrst noun group after the verb is chosen.</Paragraph> <Paragraph position="3"> + flnd agent looks for a valid actor in a prepositional group introduced by \par&quot; (\by&quot;).</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.4 Generating Collisions and Dynamic Objects </SectionTitle> <Paragraph position="0"> For each collision, the system tries to extract the participating parts of the vehicles in the noun groups that refer to the actor and the victim. To do this, it looks for cues like \avant&quot;, \arri ere&quot;, \droite&quot;, or \gauche&quot; (\front&quot;, \rear&quot;, \right&quot;, or \left&quot;).</Paragraph> <Paragraph position="1"> Then, the system creates two dynamic objects (see Section 3.5) and a collision between them.</Paragraph> <Paragraph position="2"> The generated properties of the collision depend on the road conflguration: + Straight road: the flrst vehicle heads to the East, the other one starts from the opposite end of the road, heading to the West. The collision is a head-on impact.</Paragraph> <Paragraph position="3"> + Turn: The flrst vehicle starts heading to the East, then turns to the Left. The second one starts heading to the South, then turns to the Right. The collision is frontal and happens at the center of the turn.</Paragraph> <Paragraph position="4"> + Crossroads: We choose to represent here the most frequent tra-c ofience (in France). The flrst vehicle drives straight to the East, the second one drives to the North. The front of the actor's vehicle collides with the left-hand side of the victim.</Paragraph> <Paragraph position="5"> As we do not extract the initial directions of the vehicles, these three cases are the only possible ones. When the system cannot flnd the actor or the victim of a collision, default objects are created matching the road conflguration.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.5 Deleting Useless Objects </SectionTitle> <Paragraph position="0"> When creating collision objects, two new vehicles are instantiated for each collision, even if the victim is a static object. Moreover, one vehicle can obviously participate in several collisions. All the unnecessary vehicles should then be thrown away.</Paragraph> <Paragraph position="1"> A vehicle that represents a static object can be removed easily, since the real static object still exists. All we have to do is to modify the reference given in the victim parameter of the collision in the template, then delete the redundant vehicle.</Paragraph> <Paragraph position="2"> Deleting the duplicates is more di-cult and involves a coreference resolution. An identiflcation mechanism of the narrator has been added to the system. All the personal pronouns in the flrst per-son or some expressions like \the vehicle A&quot; will be designated with the id enunciator. In the other cases, coreference occurs only when the two ids are strictly the same (in the sense of string comparison). Then, the system keeps only the flrst created object between the duplicates and delete the others.</Paragraph> </Section> <Section position="6" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.6 Extracting Event Chains </SectionTitle> <Paragraph position="0"> The vehicles generally do not drive straight forward. They carry out two or more successive actions. In the formal description, these possible actions correspond to the events of dynamic objects and are in limited number: driving forward, turn left, turn right, change lane right, change lane left, overtake, and stop.</Paragraph> <Paragraph position="1"> In written reports, these actions are mostly indicated by verbs. The system has to identify them and to link the corresponding event(s) to the appropriate vehicle. When the subject is identifled as the narrator, the link is obvious. In the other cases, if there are only two vehicles, the narrator and another one, a new event is added to the event chain of the second vehicle. Otherwise, the system checks whether the subject of the verb is strictly identical (string comparison) to one vehicle's id. In this case, a new event is also created and added to the event chain. Some verbs imply multiple events, e.g. \redPemarrer&quot; (\to get driving again&quot;) that indicates that the driver stopped beforehand. Consequently, a stop event then a driving forward event are added.</Paragraph> <Paragraph position="2"> With this simple extraction mechanism, the order of the events in the event chain does not necessarily respect the chronology but rather the order of the text. We assume that the story is linear, which is the case in most accident reports.</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.7 Writing the Formal Description </SectionTitle> <Paragraph position="0"> The flnal step of the linguistic part consists in formatting a template corresponding to the accident description. Because the inferred facts have exactly the same attributes as the formalism's elements, a very simple transcription algorithm is used to convert the facts in a text flle that can be processed afterwards by the simulator.</Paragraph> </Section> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 4 Planning </SectionTitle> <Paragraph position="0"> Planning complex events like collisions requires a well-deflned and exible planning architecture.</Paragraph> <Paragraph position="1"> General planning algorithms which apply methods incorporating artiflcial intelligence, are discussed in (Nilsson, 1998). The CarSim planner is much more straightforward, because the planning process is not as complex as a lot of traditional AI planning problems, see also (Norvig and Russell, 1995). The total planning process is performed by using flve difierent subplanners, which all perform a small part of the total planning task.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 The Preplanner </SectionTitle> <Paragraph position="0"> The preplanner is a planner that ensures the consistency of the formal description. If some values are not given (e.g. coordinates of a static object or initial directions of dynamic objects) or some values imply a contradiction (a vehicle turning left on a straight road), this planner tries to flnd (default) values and to solve the con icts. This planner is a simple knowledge base, as discussed in (Norvig and Russell, 1995).</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 The Position Planner </SectionTitle> <Paragraph position="0"> The position planner estimates the start and end positions of the vehicles in the simulation. By default, a vehicle is placed 20 meters away from the center of the (cross)road. If two or more vehicles are moving in the same direction, they can't all be placed at this distance because they would overlap. Therefore, if there is more than one vehicle facing a particular direction, the second vehicle is placed at a distance of 26 meters from the center and if there is a third vehicle, it is placed at 32 meters from the center4. Regarding the end points of the vehicles, the vehicle that is placed closest to the center, will have its end point placed farther away from the center. The vehicle initially having a start point far away from the center will have an end point close to the center, so that every vehicle traverses approximately the same distance.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.3 The Trajectory Planner </SectionTitle> <Paragraph position="0"> Based on the (very global) description of the movement of every vehicle in the formal model, this planner constructs a trajectory, represented by a set of points in the Euclidian space. Every event in the event chain is converted to a list of trajectory points. A turn is approximated by a number of points lying on a circle arc. Overtaking is modelled by using a goniometrical function.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.4 The Accident Planner </SectionTitle> <Paragraph position="0"> The accident planner uses the trajectory that is created by the trajectory planner. Since event chains only include atomic movements and not collisions, this trajectory is planned as if there was no collision at all. The task of the accident planner is to change this trajectory in such a way that it incorporates the collision. Some part of it has to be thrown away and an alternative part (which ultimately leads to the point of collision) has to be added to the trajectory. For every vehicle, actor or victim, the trajectory is thus changed in two steps: 1. Remove a part of the trajectory.</Paragraph> <Paragraph position="1"> 2. Add a part to the trajectory so that the fl- null nal result will be a trajectory that leads the vehicle to the point of collision.</Paragraph> <Paragraph position="2"> The part of the trajectory that has to be removed depends on the coordinates where the collision occurs. We designed an algorithm that draws a circle around the collision point and removes the trajectory part that lies within the circle region. Also, the segment that comes after the removed trajectory part is thrown away, because a trajectory does not allow gaps. The radius of the circle is thus a parameter that deflnes the precision of the algorithm. If a large radius is chosen, a large part of the trajectory will be removed. An application of the algorithm using a small radius only removes the trajectory part closest to the collision point.</Paragraph> <Paragraph position="3"> 4In the CarSim system, the maximum number of vehicles that can have the same initial direction is three.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.5 The Temporal Planner </SectionTitle> <Paragraph position="0"> The temporal planner of the CarSim system is not a planner in the sense of the planners described in (Nilsson, 1998) The temporal planner of the CarSim system plans the temporal values of the trajectory in two steps. Generally, a trajectory consists of a number of 'normal' trajectory points, followed by a number of trajectory points that represent a collision. First the segment that is not part of any collision is planned. After that, the system plans the remaining segment. In the CarSim system, every trajectory point has a time value. This is a value between 0 and 1, with 0 representing the beginning of the simulation and 1 being the end of it. The temporal planner tries to flnd time values for the trajectory points so that the collisions happen in a natural way.</Paragraph> </Section> </Section> class="xml-element"></Paper>