A Gademer
email: gademer@esiea.fr@www.esiea-recherche.eu

F Mainfroy

L Beaudoin

L Avanthey

V Germain

C Chéron

S Monat

J P Rudant

Solutions for near real time cartography from a mini-quadrotor UAV

Keywords: UAV, high resolution imagery, flight-plan, intuitive database navigation, image mosaicing

In this article, we present another way to acquire centimetric data using a quad-rotor UAV and the specific tools developed to perform near real time cartography. After setting the context of the UAVs, we will present the design and the realization of our quad-rotor Vertical Take Off and Landing solution and it's capacity for Very High Resolution imagery. Then we will describe the tools we developed to improve its ability for operational mapping : how to perform flight in immersion with a customizable HUD that takes the video broadcast from the UAV and adds vector information in real-time on virtual reality goggles, how to combine satellite and vector data with path optimization algorithm to design relevant flight plans and update them in real time to ensure data completeness, how to generate relevant geolocalization meta-data to be able to navigate in the produced image database few minutes after the landing and finally, how to employ home-made open-source mosaicer to take advantage of the three simultaneous on-board digital camera.

INTRODUCTION

In 2005, the launch of Google Earth TM and Virtual Earth TM mark a turn for the remote sensing and GIS communities, [START_REF]Google earth, worldwind, windows live local... la révolution en marche[END_REF] as they have seen their work spread from the scientific world to the public. Conscious to the new major disasters, everybody around the planet wanted to see the Earth from above. One can say that four years later aerial and satellite images are part of the "fundamental human rights" along side Internet and the mobile phones. More and more users tend to use theses photography in their work to save time and reduce financial cost of their field study, city planning or even their holiday trips around the world. Therefore, one can see growing need from the economic and institutional actors for very high resolution imagery in various fields such as crisis management (risk map, unreachable place exploration, damage assessment), biodiversity study (land-cover map, extended ground truth), radar images interpretation (roughness estimate) or even recreative cartography (tourism promotion, virtual reality panorama) and this list is far from being exhaustive.

From this point of view, micro UAVs (Unmanned Aerial Vehicles) are very interesting tools for low altitude imagery; quickly deployable, they can fly when you need them, as often as you need without extra-cost thus allowing rapid acquisition of series of images for an affordable cost.

On the downside, one can says that the area covered by micro UAVs are limited to a few hundred meters, that their trajectory is more sensitive to wind and thus less rectilinear, arising the problem of data completion and finally that, at this resolution, the flow of data can grow huge rapidly. Therefore it is vital to develop a relevant set of tools to optimize the flight of the UAVs and the exploitation of the acquired data.

In the first section we will present the context of the UAVs and our technical choice for designing an micro UAV for image acquisition * .

Then, in the second section we will present some of our new tools we develop to improve our mapping ability.

A MICRO UAV FOR IMAGES ACQUISITION 2.1 Unmanned Aerial Vehicle

Brief history

The history of UAVs began with World War One [START_REF]Drone[END_REF][START_REF] Wikipedia | Unmanned Aerial Vehicule[END_REF][START_REF] Newcome | Unmanned Aviation: A Brief History of Unmanned Aerial Vehicles[END_REF][START_REF] Valavanis | Advances in Unmanned Aerial Vehicles[END_REF] where the military discovered that they needed an unmanned aircraft to be able to self-destruct with their explosive payload on precise targets. The pioneers projects were the United Kingdom Aerial Target project (1916) and American Hewitt-Sperry automatic airplane project (1917), but though promising, these projects were not supported for long by the government due to their technological limitations on the operational field. In the 30's, UAVs reappeared to be used as mobile target for the training of jet pilots. During World War Two, the Germans used this work to build the famous V1 and V2 and from then the development of UAVs continued within the military departments.

In recent years, the progress in aviation technologies, miniaturization, telecommunication, automatics and embedded processing, control system, concurred with the pressure of public opinion to limit the risks for human life to relaunch the interest in relevant unmanned aircraft. Nowadays UAVs begin to be financially accessible for the civilian world and the operational potential is huge and just starting to be discovered.

Diversity of shapes and missions

UAVs come in all shapes and sizes ; one can find a wide diversity in their characteristics. Their range and flying altitude can vary from a few hundred meters to several kilometers, their endurance, thought as the maximum time of flight, can vary from a dozen minutes (micro-uav) to several hours, and their size (from a few centimeters to several meters), weight (from a few grammes to several tons) and aircraft category (lighter or heavier than air, with helix or jet propeller, with Vertical Take Off and Landing ability) are such that you will hardly find two identical UAVs.

It is important to separate military from civilian missions. The main missions of the military UAVs are 6 : flying targets for new weapons, intelligence and surveillance, combat (with on-board weapon or by marking targets for weapon guidance), logistic support with cargo UAVs, scientific tests of technology beyond human resistance (+9g/-3g), mobile network relay.

Civilian missions are also very diversified. [START_REF] Ollero | Multiple Heterogeneous Unmanned Aerial Vehicles[END_REF] We can cite : those related to security, in particular industrial site or sensitive networks (electrical, telecommunication, water, roads) survey 8 or historic buildings diagnosis, [START_REF] Metni | A uav for bridge inspection : Visual servoing control law with orientation limits[END_REF] those attached to aerial survey with rescue operations, 10 humanitarian crisis management [START_REF] Tatham | An investigation into the suitability of the use of unmanned aerial vehicle systems (uavs) to support the initial needs assessment process in rapid onset humanitarian disasters[END_REF] or forest fire fight, [START_REF] De Dios | Multiple Heterogeneous Unmanned Aerial Vehicles ], ch. Multi-UAV Experiments: Application to Forest Fires[END_REF] those attached to perilous in-situ measurements (hurricane 13 or volcano [START_REF] Astuti | Hil tuning of uav for exploration of risky environments[END_REF] ), those related to very high resolution imagery ( 15-17 for mapping and DEM generation, [START_REF] Binenko | Remote sensing of environmen on the base of the microaviation[END_REF] for environmental applications and [START_REF] Bendea | Mapping of archaelogical areas using a low-cost uav the augusta bagiennorum test site[END_REF][START_REF] Nebikera | A light-weight multispectral sensor for micro uav oppportunities for very high resolution airbone remote sensing[END_REF] for archeology).

To conclude with the democratization of civil UAVs, one can say that the last technical hindrances have been recently overcome: higher energetic density of batteries, higher efficiency of motors, increase of calculation power and a global miniaturization of all the electronic components (internal sensors, computing chips, detection sensors, etc.) with the microelectromechanical systems (MEMS) and the surface mounted components (SMC). All of these reduce drastically the weight and cost of the system and thus allow the building of small UAVs, fitted for operational missions, at a reasonable cost.

Our technical choice

In our case we have made the choice of a small scale quadrotor (Less than 70 cm, 1.6 kilogram). The rigid structure of the multi-rotor, with constant pitch propellers for the rotors on a simple frame has a lot of advantages, as it is simple from the mechanical point of view, sturdy and very maneuverable. Its most simple implementation has four rotors at the ends of a cross. (cf. Fig 1) The degrees of freedom of the UAV come from the differential speed of the pairs of rotors, tilting the system and thus producing the movement. Simple from a mechanical point of view, a quad-rotor is intrinsically unstable (compared to planes or helicopters) and thus needs efficient control algorithms and accurate sensors to perform any flight. This method is sufficient as long as you have a remote pilot, but it does not allow semi-automatic flight. Indeed, internal sensors tend to have poor absolute measurement and do not allow to have a good position of the UAV in its environment. To obtain this X,Y,Z information, we use a combination of several external sensors. The problem is not simple as UAVs have more complex trajectories than satellites or planes, they are more sensitive to environment and their positions and heights can rapidly change due to a gust of wind. To make things a little more complex, all these sensors measure physical properties from which they derive the state of the system and thus present noisy and biased results. To make sure to have accurate knowledge of the true trajectory we must use complex filtering and data fusion. [START_REF] Chatfield | Fundamentals of high accuracy inertial navigation[END_REF] The position and altitude is given by the Global Positioning System (GPS) which can be accurate enough on flying systems : horizontal accuracy is around 3 meters and vertical accuracy is around 5 meters. The height above the ground, a very important item of information is obtained by the data fusion of ultrasonic, barometric and accelerometer systems. The ultrasonic range finder gives a very good accuracy of one centimeter to the ground, where the height information is critical, but gives false positives when the UAV reaches a few meters. On the other hand, the barometric measurement allows us to derive a relative height above the take-off point (rough estimate of the ground) but has a vertical accuracy of around 5 meters. With the data fusion process we have a good overall information of the height above ground and we can implement a vertical control which improves the flight of the UAV and allows it to do automatic take-off and landing in no-wind condition.

We are currently working on a XY-control algorithm with the GPS position which is the last step to semi-automatic flight based on a previously set flight-plan. Some tools for defining and managing the fligh-plan will be presented in section 3.2.

Payload

The payload corresponds to the weight of material the UAV can lift besides itself without limiting its maneuverability. It is often a critical parameter of the UAV as the payload is generally the material dedicated to the UAV's mission. This parameter can change drastically from one model to another given its size and aircraft category but is generally around 20% of the weight of the UAV. [START_REF] Defense | Unmanned Aircraft Systems Roadmap[END_REF] In our case, recent technology allows us to lift up to 1 kilogram, corresponding to 60% of our weight.

Based on this capacity and depending on the mission we want to accomplish, we can fix on the UAV : one or several photo cameras for aerial imagery and stereoscopic reconstruction, an HD video camera for exploration and monitoring, a thermal camera for thermal leak of buildings or life detection, a laser telemeter or a passive sensor in all the frequency spectra (GSM, Wifi, Bluetooth), it can really be any sensors within reasonable size and weight. [START_REF] Gademer | Réalisation d'un drone pour des missions de télédétection THR environnementales à la demande[END_REF] shows the interest of simultaneous multi-acquisition of high resolution images for environmental applications and for quick cartography in crisis situations. Indeed, operational users need as much information as much as possible for situation assessment ; they want recent, reliable images of their regions of interest from several points of view to help the evaluation.

On the one hand, simultaneous acquisition reduces the number of flights needed to cover an area and thus increases the range of the UAV, it also allow to take a scene from different angles (cf. Fig 2), opening up new data exploitation possibilities (intuitive navigation in the image database, stereoscopy, etc.). On the other hand the weight and size constraints become drastic and more efforts on sensor integration needs to be achieved.

As it can be seen in (cf. Fig 2), we use an on-the-shelf photo camera in our system. Digital cameras have the advantage of an autonomous storage capacity, all the processing of the image being done on board. They also have a big CCD captors, optics of professional quality, a mechanical shutter and an included stabilization system. However, these cameras are bigger and heavier than industrial CCD cameras and are made for human manipulation and thus are not easy to integrate into on-board systems.

Fortunately, after a slimming process and the development of an electronic interface board, [START_REF] Gademer | A low cost spying quadrotor for global security applications using hacked commercial digital camera[END_REF] we are now able to control perfectly our three cameras and acquire simultaneous images from the sky.

Ground station

A civil UAV is not to be thought of as a fully autonomous system like a missile. It should be viewed in a global perspective including the aerial vehicle, the payload and all Figure 2. The simultaneous multi-acquisition payload Figure 3. The UAV a multiple data link to the ground station the computers and antennas known as the Ground Station. The whole system has been called by the US Navy as Unmanned Aircraft System (UAS) and is more and more taken into account by the designers and the operational users. [START_REF] Wikipedia | Unmanned Aerial Vehicule[END_REF][START_REF] Defense | Unmanned Aircraft Systems Roadmap[END_REF] The ground station is a vital part of the UAS, as important as the on-board flight assistant. It is indeed the critical link between the aerial vehicle and the operators (cf. Fig. 3). One must imagine that flying is always a stressful operation, even with a semi-automatic systems and that everything that improves the operational environment should be used. The goals of the ground station are to facilitate the security checklists, to have a real-time check of the internal status of the on-board system, of the data communication signal power and of the remaining flight time. It is also used to locate the UAV's orientation and position, to set any control parameters and to give high level orders (camera control).

The ground station is also dedicated to on-board video reception, HUD immersion flight and data exploitation (storing the images and trajectory data between two flights). The next section will present the tools we developed on the ground station to improve the operational conditions.

DEDICATED TOOLS

Flight in immersion

In flight in immersion, we are virtually putting the pilot back into the UAV, as though he was in a cockpit of a classic aerial vehicle. In operation, this method allow to fly higher and farer that the normal reach of the R/C pilot.

In order to do this, we need a video broadcast from the UAV and a HUD.

HUD

The first use of HUD (Head-Up-Display) was military. They were designed for easing the work of aircraft pilots especially in difficult weather conditions.

Most of the time, it is a transparent display positioned directly over the usual view of the pilot in order to prevent him from looking down at his instruments, then forward, then at the instruments again and so on. With this display, the important navigation data are displayed on the collimated transparent screen. Therefore the pilot can easily can remain concentrated on the external events and constraints of navigation. The screen of the display is a collimated screen, that signifies it is focused at infinity, because otherwise the pilot will have to change his focus all the times.

There are two main uses of the HUD technologies. The first is on windscreen like in commercial aircraft, automobile and other such sectors. The second is in the virtual world like in flight simulators or in video games where they can compensate for the lack of physical sensation resulting of not being in the aircraft. Developer have imagined as many shapes of HUD as there are games, but most of the time it gives you pieces of information about your status in vector shapes (small maps, physical status indicator as color bars, direction arrows, ...).

In this last case, simulators and video games, there is no need to add a kind of screen between the screen and the user ; it reflects a virtual world and the HUD is directly integrated into the artificial view that is displayed.

Implementation in a micro UAV context

The UAV HUD is just between the windscreen and the simulator HUD. It must superimpose on the real world but, as there is obviously no windscreen it must been displayed on a screen on the ground. The real world images comes from an on-board camera we want to orientate to follow the moves of the head of the pilot, so we choose to use virtual reality glasses as a medium between the view and the user. Those glasses will provide the pilot the broad-casted real-time video from the camera. This video will take the place of the usual view and we will display on it important navigation vector data like.

The HUD implementation is also as critical as on real planes, because we are evolving in the real world. It should allow a secure flight without stress for the pilot. With only the video information, it would be very difficult and dangerous because the pilot does not have the physical sensation of gravity and orientation, the sound of the rotors, nor a very large angle of view. As he can't look from and at the Figure 4. The HUD superimpose vital vector information on the broadcasted video from the UAV UAV at the same time, the pilot has no more the information about its position as well. The HUD must efficiently help the pilot in that situation.

Augmented Reality

To draw the vector information we use Augmented Reality technologies. We chose to use the OpenCV library among other sources, because it was the one that corresponded the best to our needs. As we receive the video on the ground station we analyze it image per image and process it to overlay the pieces of information, called reticules, we need. At the same time we gather the video and real-time orientation and position data from the UAV and thus we can use them to create the reticules on the video (cf. Fig. 4). Some of these reticules are called "artificial" because they are not directly linked to the view. They are mostly numerical and we can put them wherever we want in whatever form we want given they are easy to use and to understand and that they don't hide the pilot's view. One can cite the time of flight left, the ping (signal that say if all is well on the on-board card), the range, the sight, the altitude, the yaw, the warning messages and lots of other ones.

The other reticules are "connected to the real world". It implies they are linked to the image and thus their implementation is critical. We can cite the artificial skyline, the roll and the pitch or for example the hardest of them : the way-points.

From real word to image

The way-points represents the points we want the UAV to reach. We represent them by a cross on the screen. If a way-point stand for a house for example, we want that it to stay on this particular house whatever the video camera movements are. This is were Augmented Reality came in. We have to maintain the data added to the video as if they were in the real world. In order to do that, we have to precisely know the video camera position in the real world.

There are two methods to achieve this goal. The first is to use the internal coherence of the image with special markers known as MIRs (black and white geometrical shapes). By their aspect in the image we are able to follow them and to calculate their orientation in relation to the camera. The second method is to assess with sensors the outer positions of objects and the camera orientation and position. In our case we dispose of the data from the Inertial Measurement Unit and the GPS transmitted from the UAV to the ground station.

We want to convert a real word 3D point into a projected 2D point in the image. To do this we make several coordinate system changes : from geographic 3D coordinate(latitude, longitude, altitude) to cartesian Earthcentered Earth-fixed 3D coordinate, then to 2D ideal undistorted image coordinate and finally to 2D real image coordinate. To ensure this we use the Pinhole model [START_REF] Hartley | Multiple View Geometry in Computer Vision[END_REF] that take in account the external position and the intrinsic properties of the camera.

We explained earlier how we get the external parameters of the video camera, but before using the Pinhole model, we also need the intrinsic parameters of this video camera. To calculate these intrinsic parameters (the distortions, both radial and tangential) of the video camera we need a MIR, a black and white chessboard, to take several images of it with the video camera we want to calibrate. In our case we chose to focus at infinity, because we are observing a whole scene. We developed a tool to assist the user during the calibration. We can choose the chessboard's size and the minimum of photos needed to process the calibration. You just have to press a key to take a photo, and another one to stop the calibration. Then we use OpenCV to calculate the translation and evaluate the distortions. The calibration result consists in an XML file, so we can export it onto the computer to try other calibrations. Therefore it is possible to use different video cameras.

Constraints

One of the most difficult things when developing a HUD is to preserve the real-time constraint.

The frame-rate of the video depends on the video camera and the computer, but actually it's around 15-20 frames per second. These performances can still be improved. Theoretically, the number of reticules you could overlay is not limited, barring the visibility on the screen and the framerate that decrease in consequence. We have worked to optimize the program so each reticule takes as little time as possible. For example we calculated that a circle takes far more time to be displayed than lines or a polygon so we try to avoid drawing our reticules with circles or curved lines. For now, the process that takes the most time is to retrieve the video image per image.

We chose to design our HUD with the goal to be accurate and pleasant to look at. At the same time we toke care about the fact that each user and each mission would have not the same needs. Therefore we leave the possibility to customize the HUD before the mission. We can choose the reticules we want to use, their size, color and text fonts. These parameters can be saved into an XML file for later use. Then there can be several configurations for several pilots or different sorts of missions. Moreover, we thought it was important be able to disable some reticules during

Mission programmer

The mission programmer is a second important tool of the ground station which allow to plan the mission of UAVs. Among other things it offers, before flight, to register all the information we need in order to perform the mission in good conditions. A flight-plan is composed of a sequence of geographic coordinates. These describe the different points the UAV will try to reach or follow during its mission so it can perform what it was designed to do.

Background map

We thought that it would be far easier to set this flightplan knowing approximately the scene we wanted to cover. Therefore we add a functionality to load a geolocalized image as a background map. The image can be loaded from the hard-drive or directly from Internet giving geographical coordinates, a radius and a resolution.

We developed a tool directly integrated into the mission programmer that takes care of downloading the image from Internet. It collects the tiles on the Virtual Earth TM (now Bing Maps TM ) satellite image database given what you have asked for and patches them together in order to display a full map. The coordinate system used is a little bit different from the classical system (latitude, longitude, altitude). Based on a mercator cylindric projection, a quad-tree data structure is used 25 : the Earth is divided into four subregions and each region has is own four children. From a geographic 3D coordinate, a 2D coordinate is calculated depending of the level of precision required by the user and from this a quad-tree sequence corresponding to the path from the root to the leaf we are seeking. With this sequence we can download the tile and his neighbors. The final image is created by ImageMagick by merging all the tiles together (cf. Fig. 5).

Besides, for these maps, you can have the names of the streets and other items on them. It can be useful to help you to get one's bearings. So with this tool, the map is directly downloaded and cached for later use. You want to prepare your mission with Internet at hand and besides you want to use it when you may not have an access to the web.

Once loaded, the map is shown in background and you can move on it or change the zoom factor at any moment, all this without going back to the charging page and downloading the full map once more. So it allows you to enlarge your field of view during the preparation of the mission if the need arises.

Georeferenced vector drawing

On this image we can add manually some vector drawings, if we already possess some field information. The possibility to add areas and points of interest on the map can prove very useful during the planning and even during the flight as we will see hereinafter. For example it is important to note any uneven relief or obstacle. It can also be used to mark any change seen between the map and the reality as seen on the field. Every object can be customized with an identifier and a color so it is easy to track it down instantaneously on the map. From the satellite background map we have the correspondence between the image coordinate and the geographic coordinate so every vector information is georeferenced (cf. Fig. 6).

All the raster and vector information can be saved in XML format to be reloaded later and to be used by the other programs, such as the mission completion surveyor. This way it can be very useful if you want to prepare many missions at the same time and use them later, one at a time.

All the data are saved given their geographic coordinates, so you can change whatever you want on the background map, when you upload your mission file, all the vector drawings are precisely in the right place.

In the future, we hope to add the possibility to project the satellite maps on 3D structures of the ground. It would give a better view of the elevation so we can better apprehend the ground and the mission we want to design. These 3D structures could be obtained from various Digital Elevation Model (SRTM, or home-made DEM from a previous flight above the scene where they are scanned using a LI-DAR for example).

Optimal path algorithm

Once aware of the characteristics of the area, the user can plan the flight by adding, deleting and moving way-points. The program will calculate in real-time the optimized path to cover all the way-points in the shortest time. A traveling salesman algorithm has been integrated for optimal calculation. The one that is used basically optimizes the flight using the Graham scan and a geometric heuristic (maximization of the angle). We tried others, but this one gives good results so far (most of the time the best optimized way) and more importantly, it gives them quickly. That is because we don't need lots of way-points to design a flightplan.

In the future we hope to add other algorithms based on multiple criteria (distance, priority, sensor ground-print, speed, etc) and we also hope to take into consideration in an automatic way during the design of the flight-plan the obstacles we have noted on the map.

Data completion

During the flight, the ground station provides in real-time the progress of the UAV on the flight-plan map to check its status and the correlation between the flight and the planned mission. We wanted to do more. As cartographic UAV users, the most important thing for us is to avoid incomplete data. If we have two or more pictures of the same scene we can choose the best one but if we lack one, we are not able to give a correct assessment and that is not desirable. Most of the systems (satellite, aerial or UAVs) take a security margin : all the images cover a great percentage of the others, just in case. We wanted to optimize our flight and reduce this margin but how can we assure that we will not forget any important image ? So we developed a part of the mission programmer which is active during the flight. It loads the mission file we have saved when planning the mission so we are able to see the tagged map and we can follow more easily the UAV's progress in real time. Thus we can take advantage of all the information about the images we received in near-real time from our UAV.

Firstly, as we have real-time retransmission of the onboard mini video camera, we add the functionality to edit during the flight all the vector information of the flightplan. Therefore, it is possible, as in the planning phase to add areas and points of interest, to tag them, to modify them, and so on. So for example, we may want to indicate what we saw on the video: that an area is flooded, or that there are rock slides and a mass of fallen rocks at this place, that a detail requires one's interest here, that this area is marshy and this one forested, or whatever else you want to be highlighted on your map.

Secondly, we use the trajectory information (geographic coordinates and altitude) paired with the time of acquisition of the pictures to calculate the approximate ground print of the pictures. Similar to the fog-of-war you can see in video games, all the places that have been seen by the UAV's payload are highlighted. All remaining areas are darkened, so the ground station user can see at a glance if there is any lack of data or not and possibly edit the flight plan as a result.

Finally, we made the data structure of these maps simple to be able to share them in near real time with all the operational users on the ground. This map will allow them to get an overall view of all the data gathered and then they can act accordingly. Now we can assure before the landing of the UAV that we have all the images we want, we will need to transfer and process them to be integrated in our image database. It is the role of our next tool, named Drone Eye.

Drone Eye

Generating Pertinent Image Database

As seen in section 2.2, our small quad-rotor UAV can carry up to three compact cameras on a stabilized platform. From the operational point of view, that represents a total of 2800 images at a resolution of 2 to 5 centimeters for each 20 minute flight, which would be completely useless without powerful tools to index and visualize those pictures. We developed an innovative solution to transform these raw images into highly valuable scenes.

The sensor module is composed of three compact cameras, a GPS receiver and an Inertial Measurement Unit (IMU). The three different cameras can be independently tilted to ensure a desired overlap or to acquire a bigger scene using the three of them. The platform is nearly completely isolated from the UAV vibrations with dedicated shock absorbers and does not follow the UAV's roll and pitch variations as it is completely free to rotate along those two axes, so that the cameras always have the same horizontal angle.

The cameras are remotely controlled by a home-made electronic card, interfaced with a tiny embedded computer synchronizing image acquisition along with the GPS and IMU data. The sensor module is entirely independent from the UAV critical electronic circuits, so that a failure in the sensing module can never compromise the UAV's ability to fly. This also makes the sensor module independent from the vector and, with few mechanical adaptations, could be embedded on any other aerial vector.

After landing, we are able to download the pictures files along with three different logs from the GPS, IMU and the camera's control cards, synchronized on the GPS time stamps. These metadata can't be stored in EXIF directly in the images as the EXIF lacks fields related to the orientation of the camera, logged within the mission parameters for the angles of the cameras with the horizontal plane and the log of the IMU. We so chose to create our own metadata files to link our images with their exogenous data. These metadata should allow us to project our images on the ground and thus the GPS and IMU data are sufficient, along with a reference ellipsoid. To ease computations, we chose to keep the GPS reference ellipsoid, WGS84. As the covered area for a single mission is small enough, the projections are computed in a Local Tangent Plane (LTP).

We have developed our own software tool to aggregate the GPS, IMU, pictures and cameras logs to produce XML Figure 7. Calculated footprint of one image. metadata linked to the images and containing all the necessary information to allow the computation of the images projections on a LTP. The choice of the XML format was inspired by its inherent durability, as it is designed to be fully readable even without a dedicated software.

The images footprints can then be computed using these previously mentioned XML files. Taking in account the LTP coordinate and orientation of the camera, we can calculate the direction vector of the camera. The intersection of this vector and the estimated ground plane give the center of the projected footprint. By applying a rotation matrix corresponding to the angular field of view, we can calculate a vector for each of the corner of the foot print and thus a projected point. Once projected in LTP coordinate we can recalculate their position in geographic coordinate to be printed in Google Earth TM (cf. Fig 7). Two other very important parameters are calculated : the azimut, thought as the angle between the camera direction, projected on the XY plane, and the North and the elevation, thought as the angle between the camera direction, projected on the plane defined by the direction vector and the Z axis, and the horizontal. All this parameters are stored as XML files.

These files are designed to be requested individually and with spatial requests, so storing them in a dedicated database can seem to be a natural choice. But conventional databases are not designed to handle XML formatted data. We have reviewed a lot of XML-enabled databases and XML Native Databases. The main difference between these two different types of databases is that the former ones are just conventional databases with a plug-in giving them the possibility to parse and translate XML files into their own internal format, as the second ones, the XML Native Databases (XND), are entirely dedicated to this format. The choice of using an XND was driven by the need of a fast access to metadata, in order to make navigation and visualisation seamless. This database scheme fully brings the benefits of XML trees, and only pertinent data is requested using the XQuery language. Using XND, one can benefit from their ability to be requested with the XQuery language. The XQuery language is a W3C standard specially designed to request XML databases, which has the particularity to em-Figure 8. A poor definition of geographic areas can lead to unreachable zones. bed the answer format in the request. The result from the database can thus be immediately formatted in an XML scheme without the need of any additional operation.

The Sedna XML Native Database has been chosen for its almost perfect respect of the XQuery specifications and is able to produce answers in KML, a variant of XML used by Google Earth.

We have developed Drone Eye to request the Sedna database with spatial inquiries and deliver the results as KML files.

Drone Eye: Visualization & Navigation

As seen in section 3.3, we have designed a way to access our images through geographic requests.

We developed a software solution, Drone Eye, to access our pictures in a natural way, through the use of Google Earth TM . Drone Eye is an interface between the aforementioned Sedna XML Native Database, Google Earth TM and the user.

The end user of Drone Eye is an operational needing quick and precise information on a specific area, with very little knowledge in Geographic Information Systems (GIS). This profile dictated the choice of Google Earth TM for the display, as it is a well known software tool, simple enough for end users to use but powerful enough for our needs.

The requests of the users are formulated with the keyboard, using very intuitive keys like "next image north from this one", "same location but with a 45 degrees point of view", "same location but viewed from the south". Drone Eye hides the complex geographic projections and matrices mathematics from the user point of view to let him ask for pictures in a natural way.

If "North", "South", "East" and "West" can seem to be fairly easy to understand from the user point of view, these notions have to be thoroughly thought out in the development process. Indeed, how can we say that picture X has to be shown as being "next image north from picture Y" ? Figure 9. Eight different zones are too many for the user to remember.

Figure 10. This geographic slicing has only four different zones and is fairly intuitive for the user. Do we have to compare nadir locations ? Or image centers ? Fig. 8 shows a basic definition for the "North", "South", "East" and "West" zones, based on center comparison. We define four zones corresponding to the natural definitions of "North", "South", "East" and "West". There is an important drawback to this definition: we create unreachable areas. Adding new zones like "North-West" or "South-East" could give access to these areas, but users would have to remember an overwhelming number of keys, as shown in Fig. 9.

The geographic slicing used in Drone Eye is described in Fig. 10 and images are requested inside one of the four zones, with a comparison on centers distance.

Our tool listens to the keyboard, contextually interprets the keystrokes (to toggle the elevation of the camera for example), requests the XND and feeds Google Earth TM with the KML resulting file. On its side, Google Earth TM constantly reads the same KML file to be able to display the requested images. database is currently displayed, and the user can navigate through images around the area using the keyboard, as entered keys are intercepted by Drone Eye, which displays requested pictures.

Technically speaking, every adjacent image to the current one is requested, using XQuery language, from the XND. When the user accesses another image, it can be displayed very fast as we don't have to search the entire database.

JIM: Open-source automatic mosaicker

As we acquire multiple images from a very low altitude, we have multiple patches, each covering a very narrow area. This approach gives the desired centimetric resolution, but denies the user the possibility of getting the global picture.

We have developed our open-source solution to automatically generate mosaics from our images based on. [START_REF] Capel | Image Mosaicing and Super-Resolution[END_REF] Mosaics can also be used to produce aerial maps, a very cost effective and quick method to produce this kind of map.

The key point of our software solution is to be entirely automatic, as we are dealing with a large number of images, and to remain completely free from software patents. This automatic way of working is also critical in crisis situation, as human resources and time are both very limited.

Two main methods are known to produce mosaics: direct and indirect methods. Direct methods use images globally, overlay them and move them little by little to minimize the sum of the differences on the overlapping areas. These methods suffer from two main problems: they can get stuck into a local minimum and thus not be able to find the optimal solution, and they are very time consuming, as they require a lot of pixel comparisons. We have chosen to implement an indirect method in our software tool, based on matching identical points between pictures.

Matching

The first and critical step of our algorithm is to find repeatable interest points on acquired scenes. Different point detectors are suitable for this kind of application, but 27 recommends using Harris corner detector [START_REF] Harris | A combined corner and edge detector[END_REF] for its high repeatability. To be more precise, we use an evolution of this detector described by . [START_REF] Shi | Good features to track[END_REF] We use Harris's 28 corner detector to ensure free software compliance.

The next and most time consuming step of the algorithm is the matching of the previously found interest points. As trying to match every picture with the others would take hours even on a modern computer and would not return correct results for most of the image pairs, we choose to match only temporally consecutive images. The point matching can be performed using various algorithms, gathered in two types: CC and SSD, both based on a small neighborhood around the interest points.

The CC family (Cross Correlation) is based on the scalar product of the intensity vectors of the images. The simplest correlator of this family, CC, suffers from a bias related to the intensity of the correlation windows: the brighter the image, the better the correlation will be. ZNCC (Zero-mean Normalized Cross Correlation) is a correlator corrected of this bias. ZNCC is the cosine of the intensity vectors of the correlation window. It is much more reliable than CC, but can still incorrectly match very dark pixels with very bright ones, and this is why we got interested in the SSD family.

The SSD family (Sum of Square Differences) is based on the Euclidian distance between the intensity vectors of the correlation windows. SSD is very sensitive to illumination changes between images, such that could occur because of a cloud, a slight change of the camera orientation or even the camera automatic white-balance. It therefore has to be normalized and ZNSSD is a correlator robust to global and local illumination changes. We use ZNSSD in Jim (Jim is an Image Mosaicker ) to have reliable matches between interest points from consecutive images.

Homography

Now that we have determined corresponding points between images, we are able to find an applicable deformation to overlay one over the other. Different deformation models can be used, depending on their number of freedom degrees. We use a plane homography model for two main reasons: such a model is not liable to distort images such as models with more degrees of freedom could, and we restrain our deformations operation to realistic ones, such as pan, tilt, zoom and shear. Several methods can be used to compute a plan homography from a matched set of points, essentially the 8-point algorithm and the 7-point algorithm. [START_REF] Hartley | Multiple View Geometry in Computer Vision[END_REF] We use the 8-point algorithm along with RANdom SAmple Consensus (RANSAC) [START_REF] Fischler | Random sample consensus: a paradigm for model fitting with applications to image analysis and automated cartography[END_REF] to determine the most likely homography, as a lot of previously computed matches are erroneous ones.

More matches are then found using guided matching based on the homography found previously, which makes the software able to refine the transformation between images. This refinement is performed using the Levenberg-Marquard algorithm. [START_REF] Levenberg | A method for the solution of certain non-linear problems in least squares[END_REF] This step can be performed with Figure 12. A mosaic realized by JIM and Enblend using 6 12Mpx images. a smaller correlation window as a first guess has already been found for the homography. We so choose to run this guided matching operation with two parameters, one giving a new size for the correlation window, the other restricting the searched area for Harris points correspondents.

Mosaic of n images

Overlapping is then computed between every image pair in order to detect non-consecutive images that overlap. This is done by multiplying homography matrices that have been computed using the matches between consecutive pairs of images. If non-consecutive images significantly overlap, Jim tries to follow the matches between the images, using the Nviews graph described by Capel, taking advantage of Dijkstra algorithm [START_REF] Dijkstra | A note on two problems in connexion with graphs[END_REF] to minimize error propagation. If the number of followed matches is reasonable, Jim assumes that the computed homography is not too much influenced by the errors resulting from the matrices multiplications. Otherwise, Jim simply falls back to its normal process, matching these two new images and computing their associated homography.

Reprojection and fusion

Transformed images are then mapped on a plane, using the previously computed homographies. The reprojection plane is one of the images, specified by the user or automatically chosen in the center of the scene to minimize global deformations.

But image mosaicking would only be stitching without radiometric rearrangement. Jim is here helped by Enblend, [START_REF]Enblend project on sourceforge[END_REF] another very efficient and open-source tool, which detects radiometric seams and moves separations between images in high frequencies areas, to make the transitions between images almost invisible.

Jim can be downloaded under GPL v3.0 on Source-Forge.net. [START_REF] Mainfroy | Jim project on sourceforge[END_REF]

CONCLUSION

To conclude we will say that micro UAVs seems promising for civil application such as Very High Resolution mapping and that a relevant set of tools can significantly reduce some of the downside of such a small vehicle. This part is still too much ignored by economic actors and the future of this market will pass by an important dialog between the UAV makers and the operational users around the world.

Our first field test with the Natural History Museum of Paris shows promising result both on the acquisition, with It is now important to determine the accuracy of our geolocalization and the overall quality of the images for a thematic interpretation. This will be the subject for a future publication.

Figure 1 .

 1 Figure 1. The quad-rotor maneuverability is obtained by the differential speed of the rotors.

Figure 5 .

 5 Figure 5. Schematic of the retrieval of the satellite data

Figure 6 .

 6 Figure 6. The Mission programmer use satellite images and vector data.

Figure 11 showsFigure 11 .

 1111 Figure 11 shows Drone Eye usage : an image from the

Figure 13 .

 13 Figure 13. A mosaic realized by JIM on field test data

contest who have greatly supported this work. http://minidrones.fr/