VUEMS - A virtual Urban Environment Modeling System_1997_

VUEMS : A Virtual Urban Environment Modeling System StCphane Donikian IRISNCNRS F-35042 RENNES, France donikian @ irisa.fr Abstract The Praxitele project is responsible for the design of a new kind of transportation in an urban environment, which consists o a fleet o electric public cars. These public cars f f are capable of autonomous motion on given journeys between stations. The realization o such a project requires f experimentations with the behaviour o autonomous vehif cles in the urban environment. Because of the danger connected with these kinds o experiments in a real site, it was f necessary to design a virtual urban environment in which sinziilations could be done. Animations or simulations in Virtual Urban Environments can be pegormed in various ways, but one common element of such systems is that they require a model of the environment. Reproducing the real trafic of a cig, as completely as possible, implies the simulation o autonomous f entities like living beings. Such entities are able to perceive their environment, to communicate with other creatures and to execute some actions either on themselves or on their environment. Interactions between an object and its environment are, most of the time, v e y simple: sensors and actuators are reduced to minimal capabilities which permit only to avoid obstacles in a 2 0 or 3 0 world. This is due to the fact that databases f o r virtual environments are often confined to the geometric level, when they must also contain physical, topological arid semantic irlformation. Accordingly, in this paper we propose a model which is designed to connect direrent levels of representation, b? assembling geometric, topological and semantic data in thejield of trafjic simulation, and its implementation in VUEMS, a Modelling System of Urban Road Network. From real world data (when available), we construct a Model of the Virtual Urban Environment, integrating all the iilforniation needed to describe the realistic behaviour of car drivers andpedestrians. 1 Introduction 1.1 Praxitele The Praxitele project is being undertaken by two large government research institutes, one in transportation technologies (INRETS), the other in computer science and automation (INRIA) (http://www-rocq.inria.fr/Praxitele), in cooperation with large industrial companies: a car manufacturer (RENAULT), the French national electricity utility (EDF) and a public transport operator (CGEA). The aim of the project is to design a novel transportation system based on a fleet of small electric public cars under supervision from a central computer [ 161. These public cars are driven by their users but their operation can be automated in specific instances. Prior to beginning experiments on automated cars in real life structure, we have to use a simulation platform which permits to simulate platoons of electrical vehicles evolving in a virtual urban environment and to test control algorithms of the automated cars. In this paper, we focus on the modelling of such virtual urban environment. 1.2 Organization of the paper In this paper, we present a modelling system which is able to produce multilevel data-base of virtual urban environments, devoted to driving simulation. Information of different kinds and of different abstraction levels are structured and unified in a single model. In the following section, we present our objective which consists in the simulation of virtually driven dynamic vehicles. Sections three, four and five present how are described the geometric, topological and semantic levels of the urban environment. In section six we discuss about the implementation of this model in a modelling system and an example of a real complex crossroads is presented to illustrate our purpose. Finally, we conclude and present future work and possible extensions of this model. Keywords: Virtual Environments, Geometric Modelling, Driving Simulation, Behavioural Animation, Synthetic Worlds. 84 0-8186-7825-9/97 $10.00 0 1997 IEEE 2 The Simulation Context 2.1 The Simulation Platform The main objectives of the Simulation Platform developped by the SIAMES team are: modularity, heterogeneity and time manageinria.fr/Equipes/SIAMES-eng. html). For ment (http://www. instance, to perform an authentic simulation of a real environment composed of a large set of vehicles, we need to implement different models : modelling of the environment, mechanical simulation of the vehicles, motion control models, human driver models as well as algorithms for automated control, sensor models to manage the interactions between objects, and visualization tools. This simulation platform takes into account real time synchronization and data communication between cooperative processes distributed on an heterogeneous network of workstations and parallel machines. In order to implement these different models into a unique system, we have designed an object oriented programming methodology 191. For each animation module, its designer has to describe its interface (inputs, outputs and control parameters) by using specific data types. Then, the kernel of the platform is able to manage data dependencies between modules as well as their global synchronization. level motion control of dynamic objects [2, 191, which offers the ability to simulate autonomous entities like organisms and living beings [5, 61. Such entities are able to perceive their environment, to communicate with other creatures and to execute some actions either on themselves or on their environment. This requires to make a deliberative choice of the behaviour. For that, we need to design a reactive system continuously in communication with the environment 19, 8, 11. Each creature must construct a mental model of its environment, even for the simplest behaviour. It is necessary to reconstruct the new state of the world, at each simulation step, before using it in the decisional part of the agent [lo]. Since it is not possible to construct in real time a complete mental model only from vision and image processing, we have to add higher levels of information than the geometrical one in the Model of the Virtual Environment. 2.2 How introduce Artificial life in Virtual Urban Environments Usually, interactions with Virtual Environments are reserved for humans in the loop via different kinds of interface [20, 17, 131, including different spatial locations (Distributed Virtual Environments [ 181). A lot of work has been performed both to maximize the visual quality of the virtual environment and to minimize the number of polygons. This visual simulation technology which was originally limited (in view of its expensive cost) to some specific applications (military and aerospace for instance), has now become now more accessible. Existing Computer Aided Design and 3D Modelling Systems allow the generation of realistic models of Virtual Environments, including texture and level of details [ 121 and the Silicon Graphics Onyx workstation allows extensive use of real-time texture mapping. Nevertheless, Virtual Environments are still not very realistics because of their lack of life. In order to simulate the behaviour of platoons of praxicars, it is not reasonable to make them interact with dozens of vehicles driven by human operators reproducing the normal traffic of a city. Our goal is to simulate dynamic autonomous entities evolving in a virtual environment, and capable of interactions both with their environment and with operators. This requires to simulate the behaviour of virtual creatures [ 141. Behavioural animation consists of a high Figure 1. The platoon of Praxicars is stopped behind a virtually driven vehicle, because traffic light is red on this way. Some cooperative driving simulations of the Praxitele vehicles in a simple multi-level hand constructed virtual urban environment (cf figure l), including virtually driven cars and bicycles, have already been performed [3]. In order to be able to perform more realistic simulations, we have decided to realize a Virtual Urban Environment Modelling System, with the intention of offering different kinds of information to virtual dynamic entities. 2.3 Virtual Urban Environment Requirements Information needed to describe the behavlour of an entity, depends on the nature of this entity, but globally we can decompose this behaviour into different tasks or activity lines. The simplest behaviour consists in avoiding static 85 and dynamic obstacles, and this requires only geometrical information on objects in the scene. We can now decide that the behaviour of the entity can depend on the nature of objects in its environment. For example, a tree possesses some foods and must not repulse the entity, but attract it. This can be performed by adding a parameter to each object giving its degree of avoidance or attractivity [21]. More generally, we have to construct a semantic level of the scene, which consists in classifying objects at different abstraction levels. Another important aspect is the tactical one: what is the best motion to go from an initial location to a final one, depending on the nature of the motion and on characteristics of the environment ? This can be performed by the use of topological information on the scene. For the driving simulation context, we are particularly interested by reproducing the life in the streets but not by what is happening inside buildings. The information required for the simulation is of different kinds: the road network, with its geometry (road-shape), its rules (road-signs) and its environment (buildings, parks, ...) [ 11, 41. This is sufficient for driving simulation in which vehicles are all driven by a user in the loop. When autonomous vehicles are added in the simulation, other kinds of information become necessary [ 15,7]. Considering that we cannot perform the human vision simulation in real time, and from that process the extraction of topological and semantic information, that information must be represented in the database to be used during human vision emulation. For example, we need qualitative information on the road, city information (name of streets, neighbourhoods, particular buildings, squares) and topological information on the road network. The first work has been to study constituent element of the thoroughfares. There is not to our knowledge any normalization for the design of elements such as round-abouts or crossings. Each element of the thoroughfare in a urban environment is unique, but it is possible to classify them in a small number of categories. The entire organization of knowledge managed by the Modelling System has been defined from this assertion. one for two hundredth) on the topography of the public domain of the city of Rennes'. This information is used by the technical services for urban planning and project management. It concerns, for example, the topography of service networks like gas, electricity and water, but also the location of lampstands or trees. The database is structured in a set of different classes, which are themselves decomposed into subfamilies. Each element of the database is an object, representing a specific subfamily. For applications such as driving simulation, only superficial information is interesting. Some classes of objects are directly used to generate tridimensional objects, such as trees and lampstands, when other classes generate only bidimensional graphic information visualized in specific layers of the viewing manager. Scanned map of roadways: since the above mentioned database does not contains information such as horizontal and vertical roadsigns, maps of roadways, on a scale of one for five hundredth, including this information, are scanned into GIF files. Traffic lights: we need the description of traffic lights, including their organization in different sequences and their synchronization locally at the crossroads and globally with other crossroads (depending on the time of day). 3 The Virtual Urban Environment Modelling System 3.1 Introduction The main aim of VUEMS (Virtual Urban Environment Modelling System) is to enable a virtual copy of real cities to be built as realistically as possible and in the initial project in the city of Rennes (France), for driving simulation. The Modelling System uses, as inputs, different kinds of information supplied by the Technical Services of the city of Rennes: Figure 2. The VUEMS Structure. That information lays the foundations of the virtual copy of urban environments. Functionalities of the Modelling System are: Ascodes and Gif files opening, VUEMS files opening and saving, zoom and un-zoom functionalities, scale definition, multi-layers display, axial line creation, modification and deletion. We can create, modify and delete buildings, link them to road sections and give their height (because Ascodes format gives only ground surface information). We can also modify the type of elementary sections, and manage two kinds of markers: one to separate lAscodes is also used by other cities in France in competition with Cartographic data-base: this database (Ascodes file format) contains very precise information (on a scale of ArcInfo. 86 an elementary section into two others (to describe widening and shrinking sections) and the other to locate vertical road-signs. Specific popup windows provide an interactive description of the coding associated to an In/Out Point, a choice of vertical road-signs, and all the necessary information concerning the management of traffic lights sequences. Figure 3 which represents an existing crossroads of the city center, combines a bitmap (GIF file of a scanned map) and data extracted from an Ascodes file. The bitmap has been rotated and scaled to correctly overlap thoroughfares extracted from the Ascodes file. Then, by using annotated parametric curves, we can construct geometric and topological levels. Intersections of axial lines are automatically detected. Then, crossing and connection sections are generated. In this example, there is eight lines of traffic lights (including pedestrian traffic lines). Following sections give a detailed view of VUEMS capabilities in representing geometric, topological and semantic information of the public thoroughfares. ended by two In/Out points, visualized in VUEMS by circular markers. Two directions are attached to each parametric curve, according to its building: the building direction and the opposite one. To visualize the building direction, arrows are attached to each In/Out point. Elementary road sections are decomposed in three families: ordinary road sections, connection sections and crossing sections. Figure 4. An axiale line. Ordinary Road Sections. These road sections correspond to normal roadways and possess one directed axial line (cf figure 5). The traffic can be either in one way or two ways. 0 basic section: it possesses the same characteristics on its all length: the number of lanes and their width are constant. shrinking and widening sections: they permit to manage any modification in the number of lanes or in their width, by reducing the number of lane (shrinking section), increasing it (widening section), or by changing the width of each lane. 0 Figure 3. A VUEMS view of an existing crossroads. 3.2 Basic elements: the geometric level Introduction. We have tried to find the most accurate representation of the road network with the minimal number of constituent elements, and we have decided to use a set of eleven different classes, each specimen possessing its own geometry, defined by axial lines, and their associated coding. Objects described below are the lowest level of the road network description, and must not been confounded with global objects such as streets or crossroads which are defined further. An axial line is a parametric curve which gives the outline of a bituminous band (cf figure 4). Each axial line is UUm-thl- + 00000 +== cT3 0 0 1 0 0 1 nunnununnu + -3 Widening Section -3 Shrinking Section Figure 5. Ordinary sections. In the figure 5, the axial line (green straight line) separates ways in direct and opposite direction, but there is not any obligation in it. On a two way section, a driver can go back: if there is any unsurmountable obstacles on the way, safety barriers or terraces for example, two axial lines must be used to define separately two one way road sections. 87 Connection Sections. These sections (cf figure 6) are devoted to interconnect three other sections: parting section: it permits to deal with terrace and to separate a double-way road into two one-way roads. regrouping section: it is the same operation but in an opposite direction: grouping of two one-way roads in a double way road. fork section: separation of a one-way road in two other one-way roads. junction section: grouping of two one-way roads in another one. Section coding. Each elementary section is defined by one to four axial lines. Some other characteristics are requested to obtain a complete description of the roadway: the number of lanes, the inter-lane marking and for each lane the usual direction of circulation and its width. The coding associated to an axial line extremity permits to define the characteristics of the roadway at this location, and these characteristics are all expressed by the following grammar: c 1 =[LI]*L‘!’[IL]* ‘!’[LI]*L I =[‘;’I ‘I ’ I ‘-’I L =[‘N’)‘R’]*T width* T =[ ‘D’I‘0’1 ‘DO’I‘DL‘I‘DR’ I ‘OL‘I‘OR’I ‘B’I‘P’l‘A’I ‘E’] in which: Crossing Sections. These sections represent intersections between roadways (cf figure 6). T-shaped crossroads: a secondary road joining a main one. 0 T defines the different kinds of lanes (for example ‘DL‘ is for a turn left lane which has the same direction than the axial line). I defines the inter-lane marking (continuous line discontinuous line ‘:’ and no mark ‘-’). e ‘1’) Y-shaped crossroads: intersection of three roads. X-shaped crossroads: intersection of four roads. tunnel, bridge: superposition of two roads. e L associates to the lane definition its width (when it is omitted, the default value is four meter) and an opor tional mark indicating if the lane is a new one (‘N’) is being removed (‘R’). C defines the coding of the roadway. Fork . *-\ j sumontable obstacle , - building direction Junction Regrouping T-shaped X-shaped Bridge Y-shaped Figure 7. The coding editor. The coding editor (cf figure 7) permits to describe the coding associated to an In/Out point. This editor uses the preceding grammar and systematically rejects impossible Figure 6. Connection and crossing sections. 88 codings. In this example, a shrinking section is passing from two lanes to one small lane (3.05 meters width) in the building direction. Vertical roadsigns. Vertical roadsigns can be positionned by using specific markers (triangles) on axial lines, and by giving their position relatively to the roadshape (left or side side, direct or opposite direction). Figure 9. The line of traffic lights working editor. for example, to give a path to go from the current location to a wished one. This implies managing topological information at two different abstraction levels. The lowest level is used to manage the local trajectory when the highest one influences its global aspect. Figure 8. The vertical roadsigns editor. Traffic lights are specific vertical roadsigns. Because, several roadsigns can be located at the same place, we use specific markers (lozenges) on both sides of the roadshape to visualize traffic lights. Then, the user can select all traffic lights, part of the same line, and define their working by using a specific editor (cf figure 9). Specific information is given for each half an hour and concerns durations of red and green phases, and the time lag in comparison with the reference crossroads. Other information concerns local synchronization with other lines of traffic lights (initial state and local time lag). Figure 10. A Road configurationexample and its associated lowest topological level. 3.3 The Topological Level Introduction. Topological information is used to ensure local and global guiding of drivers. Locally, for example, it allows to indicate which lane must be followed and what action must be performed when arriving at a crossing or at a round-about; and globally topological information is used, The Lowest Level: link with the Geometry. The lowest topological level is represented by a graph which interconnects all the sections of the road network, or more precisely all In/Out Points. Each elementary section is a node of this graph, and this topological level is represented by a graph which interconnects all the sections of the road network, or more precisely all In/Out points. A node possesses as many connexions as its number of In/Out points. Arrows of the graph are non-directed because traffic is physically always 89 possible in both ways, meanwhile they are marked to indicate authorized traffic directions. In the figure 10 direction of arrows indicates the authorized traffic. In VUEMS, the intersection of axiale lines is automatically calculated, and the lowest graph is also automatically modified. For the building of Y-shaped crossroads, which connects three different roads, we must use an intermediate state connecting only two axiale lines, as shown in the figure 11. Se! of elementarysections * Habnations and rodsigns are relsrenced in elementary &wns Figure 12. The hierarchical structure describing urban concepts. Figure 11. The building of a Y-shaped crossroads. The Highest Level: link with the Semantic. Information requested at this level are a list of outstanding road elements forming the path to be used to go from the actual location to the wished one. This implies that all outstanding sections of the road network must be materialized by specific objects. These objects are, for example, streets, street segments, crossings, parkings and round-about and belong to the semantic level. The graph associated to this level is automatically computed by using the lowest one and the hierarchical structure presented below. It is important to distinguish a crossing in its globality from the intersections of axial lines. Another conceptual object is a round-about. It is composed of a succession of elementary sections (cf figure 13). A round-about with more than one lane implies for a good traffic simulation to know the relative positioning of roads. If the angle between the input and output roads is more than 180 degrees, then the driver must take the internal lane and must change for the external one just after passing in front of the output preceding the wished one. 104 3 4 The Semantic Level . Elementary sections corresponds to basic elements of the road network but in the reality, objects named by urban citizens are at a highest abstraction level. We have defined a hierarchical structure above the geometric level, which permits to describe conceptual objects like a street or a square, as illustrated in figure 12. A street is for example described as a sequence of street section interconnected by some intersections. The object streetsection has the following attributes: a label, a link to the street (father in the tree) and a list of links to elementary sections. Two integers ininnumbel; inaxnumber represent respectively the less and more important values of the street code number of the section. A crossing like a street does not have any proper geometrical representation: it is a concept of a global object which connects different street sections. Figure 13. A two-lane round-aboutconnecting four roads. In VUEMS, a set of rules has been used for the naming of street segments. The Modelling System ask the user in a postprocessing task to give the name of unnamed street 90 segments. In the example of the figure 14, the user is asked to give the name of a street segment starting after a T-shaped crossroads and ending at the end of the road. The street section is not ended at the other connection section because it is not a crossroads but a fork. Figure 14. Naming of a street segment. 4 Actual State A first version of VUEMS is now available on Sun Microsystem and Silicon Graphics workstations and is being tested on two areas of the city of Rennes (two square kilometers each): one in the historical center and the other one in a new neighbourhood. Currently, the tridimentional output of the Modelling System (Open Inventor files, including some textured objects like road-signs, trees, roadways) is used by the school of fine arts of Rennes to build a realistic tridimensional virtual environment (by reconstructing 3D habitations from 2D ground-print and by applying photographic textures to the simple 3-D forms) for the visualization process (cf figure 15). Only facades visible from roadways are built to increase visualization capacities. We are currently working on an automatic texturing process, using a small set of patterns, which will substantially reduce both the duration of the design process and the size of the texture memory. Figure 15. A textured tridimensional representation of the crossroads. 6 Acknowledgment We would like to thank St6phane EspiC from INRETS (French National Research Institute on Transportation and Security) for fruitful discussions at the beginning of this work, and Richard Kulpa without whom this Modelling System would not exist. References 0.Ahmad, J. Cremer, S. Hansen, J. Kearney, and P. Willemsen. Hierarchical, concurrent state machines for behavior modeling and scenario control. In Conference on AI, Planning, and Simulation in High Autonomy Systems, Gainesville, Florida, USA, 1994. B. Arnaldi, R. Cozot, and S. Donikian. Simulating automated cars in a virtual urban environment. In M. Goebel, editor, Virtual Environments’9.5, Eurographics Collection, pages 171-184, Wien New York, 1995. Springer. B. Amaldi, R. Cozot, S. Donikian, and M. Parent. Simulation models for the french praxitele project. In Transportation Research Board Annual Meeting, Washington DC, USA, Jan. 1996. B. Artz. An analytical road segment terrain database for driving simulation. In DSC’95, pages 274-284, Sophia Antipolis, France, Sept. 1995. N.I. Badler, C. B. Phillips, and B. L. Webber. Simulating Humans : Computer Graphics Animation and Control. Oxford University Press, 1993. N.I. Badler, B. L. Webber, J. Kalita, and J. Esakov, editors. Making them move: mechanics, control, and animation of arricularedjgures. Morgan Kaufmann, 1991. S. Bayarri, M. Fernandez, M. Perez, and R. Rodriguez. Virtual reality for driving simulation. Communications of the ACM, 39(5):72-76, May 1996. 5 Conclusion Our main objective is to describe the behaviour of dynamic entities evolving in virtual environments. This task requires a mental model of its environment to be built for each entity. Different kinds and levels of information are required to describe such virtual environments. In this paper, we have proposed a model of virtual environments which enables the connection of different levels of representation, by assembling geometric, topological and semantic data, and its implementation in a Modelling System named VUEMS. The modelling of urban road networks for traffic simulation was then presented in details. This is the first step of the introduction of simulated life in virtual urban environments. Our intention is to extend this model for the future integration of humanoids, which will, in particular, require a similar multilevel description of building interiors. 91 181 B. Blumberg and T. Galyean. Multi-level direction of autonomous creatures for real-time virtual environments. In Siggraph, pages 47-54, Los Angeles, California, U.S.A., Aug. 1995. ACM. [9] S. Donikian and R. Cozot. General animation and simulation platform. In D. Terzopoulos and D. Thalmann, editors, Computer Animation and Simulation’95, pages 197209. Springer-Verlag, 1995. [lo] S. Donikian and E. Rutten. Reactivity, concurrency, dataflow and hierarchical preemption for behavioural animation. In E. B. R.C. Veltkamp, editor, Programming Paradigms in Graphics’9.5, Eurographics Collection. Springer-Verlag, 1995. [ 111 D. Evans. Ground vehicle database modeling. In Real Time Systems’94, Paris, France, 1994. [I21 W. Jepson, R. Liggett, and S. Friedman. Virtual modeling of urban environments. Presence Teleoperators and Virtual Environments, 5( 1):72-86, 1996. [ 131 A. Kemeny, editor. Driving Simulation Conference, Sophia Antipolis, France, Sept. 1995. Teknea. [14] B. B. P. Maes, T. Darrell and A. Pentland. The alive system: Full-body interaction with autonomous agents. In Computer Animatiort’95, pages 11-1 8, Geneva, Switzerland, Apr. 1995. IEEE. [15] Y. Papelis and S. Bahauddin. Logical modeling of roadway environment to support real-time simulation of autonomous traffic. In SIVE95: the First Workshop on Simulation and Interaction in Virtual Environments, pages 62-7 1, University of Iowa, Iowa City, U.S.A., July 1995. [ 161 M. Parent and P. Daviet. Automatic driving for small public urban vehicles. In Intelligent Vehicle Symposium, Tokyo, Japon, July 1993. 1171 D. B. R. Pausch, T. Burnette and M. Weiblen. Navigation and locomotion in virtual worlds via flight into hand-held miniatures. In Siggraph, pages 399-400, Los Angeles, California, U.S.A., Aug. 1995. ACM. 1181 M. R. Stytz. Distributed virtual environments. IEEE Computer Graphics arid Applications, pages 19-31, May 1996. [I91 X. Tu and D. Terzopoulos. Artificial fishes: Physics, locomotion, perception, behavior. In Computer Graphics (SIGGRAPH’94 Proceedings), pages 43-50, Orlando, Florida, July 1994. 1201 S. F. W. Jepson, R. Liggett. An environment for real-time urban simulation. In Symposium on Interactive 3 0 Graphics, Monterey CA USA, 1995. ACM. [21] J. Wilhelms and R. Skinner. A “notion” for interactive behavioral animation control. IEEE Computer Graphics and Applications, lO(3): 14-22, May 1990. 92