Introducing Cartographer

We are happy to announce the open source release of Cartographer, a real-time simultaneous localization and mapping (SLAM) library in 2D and 3D with ROS support.

SLAM algorithms combine data from various sensors (e.g. LIDAR, IMU and cameras) to simultaneously compute the position of the sensor and a map of the sensor’s surroundings. For example, consider this approach to drawing a floor plan of your living room:

• Grab a laser rangefinder, stand in the middle of the room, and draw an X on a piece of paper.
• Measure the distance from where you’re standing to any wall.
• Draw a line on the paper where the wall is and write down the distance between the X (your position) and the wall.
• Measure the distance from where you’re standing to another wall and add it to the drawing as well.
• Now, move to another part of the room.
• Since the walls (hopefully) haven’t moved, you can measure your distance to the same two walls to determine your new position.

SLAM is an essential component of autonomous platforms such as self driving cars, automated forklifts in warehouses, robotic vacuum cleaners, and UAVs.

Cartographer builds globally consistent maps in real-time across a broad range of sensor configurations common in academia and industry. The following video is a demonstration of Cartographer’s real-time loop closure:


A detailed description of Cartographer’s 2D algorithms can be found in our ICRA 2016 paper.

Thanks to ROS integration and support from external contributors, Cartographer is ready to use on several robot platforms with ROS support:

• Toyota HSR
• TurtleBots
• PR2
• Revo LDS

At Google, Cartographer has enabled a range of applications from mapping museums and transit hubs to enabling new visualizations of famous buildings.

We recognize the value of high quality datasets to the research community. That’s why, thanks to cooperation with the Deutsches Museum (the largest tech museum in the world), we are also releasing three years of LIDAR and IMU data collected using our 2D and 3D mapping backpack platforms during the development and testing of Cartographer.


Our focus is on advancing and democratizing SLAM as a technology. Currently, Cartographer is heavily focused on LIDAR SLAM. Through continued development and community contributions, we hope to add both support for more sensors and platforms as well as new features, such as lifelong mapping and localizing in a pre-existing map.

By Damon Kohler, Wolfgang Hess, and Holger Rapp, Google Engineering

Open Location Code: Addresses for everything, everywhere

Accurate street addresses are taken for granted in much of the world. But in many areas, formal street names and addresses don't exist and the only real alternative is to use addresses of the form "behind the old bus stop". Without a street address, it's difficult to organise deliveries, to receive visitors or to find businesses. And street addresses only work where there are named and numbered streets - without these, there's no easy way to provide someone with a location.

Area with unknown street names in Indonesia. (Google Maps)

Latitude and longitude coordinates can specify any location, but they’re long and cumbersome. What if they were more human-friendly, like a very accurate postcode that refers to just your home? We’re happy to share Open Location Code, a stand-alone open source library for this purpose.

The Open Location Code system allows people to derive plus codes from latitude and longitude coordinates that already exist everywhere. Plus codes are similar in length to a telephone number -- 849VCWC8+R9, for example -- but can often be shortened to only four or six digits when combined with a locality (CWC8+R9, Mountain View).  Locations close to each other have similar codes. They can be encoded or decoded offline, and the character set was chosen to avoid spelling words in more than 30 different languages. We removed similar looking characters to reduce confusion and errors, and because they aren't case-sensitive, they can be easily exchanged over the phone.

World's largest carrot, H3+XG Ohakune, New Zealand.	The big gumboot. GV+8J Taihape, New Zealand.

Developers of websites that need location from users (such as delivery or taxi firms in locations where street addresses are poorly defined) could use plus codes to get accurate locations from their users. Other services which map locations that don't have street addresses (such as water sources, mountain refuges, or nesting sites) could use plus codes since they don't rely on street information.

The big trout. 2W+GW Gore, New Zealand.	Kime Hut, in New Zealand's Tararua Ranges.

We have a sample implementation to find and use codes at plus.codes. You can download the latest release of the library from our GitHub page and join our discussion list to learn more.

by Doug Rinckes, Travel team

Open Monitor: Building a World Wide Internet Connectivity Monitor through Google Summer of Code 2011

Despite all the magnificent improvements to both technology and the internet these days, we lack a free and open source real time internet connectivity monitor from which anyone can tell what the connectivity conditions are in any part of the world. Solving this problem is a huge undertaking, but at Umit Project, we saw a chance to start developing such a solution through the Google Summer of Code when we were chosen as a mentoring organization for the 2011 program.
   
We chose a hybrid P2P approach that would consist of hybrid peers and a centralized server that we call the aggregator. The hybrid peers would be able to communicate with each other and pass along reports even if direct connection to the aggregator is blocked, acting as both a server and client and promoting themselves to super peers as needed. The aggregator would be responsible for gathering all the connectivity reports from the peers and showing them in real time in a Google App Engine based site using the Google Maps API.

We also thought of having three different kinds of peers: desktop peer, desktop super peer and mobile peer. The desktop peer runs on top of the same code base but promotion to super peer status is based on the peer's availability. The desktop version is very portable (runs on Mac, Linux and Windows) and is written in Python, while the mobile peer is Android based, can not turn into a super peer and is focused on getting us a view from inside mobile ISPs.

We were given three talented students for the three month long Google Summer of Code, and each of them tackled the different pieces of the system. Despite the overwhelming amount of work and the short time frame they were working with, the students managed to get these systems to form a network, communicate, run connectivity tests and share reports.

The Umit Project team has been working very hard since Google Summer of Code ended in August to deliver our first version of Open Monitor and we're very close to releasing an alpha in the next few weeks for selected trusted testers.

If you're interested in knowing more about the project, its motivation, and more technical details about it, we have released a video on YouTube of a presentation given about the project at the Creativity World Forum 2011 and another talk given at the Chicago Python User Group Meeting. Slides of the CWF11 presentation are also available to view.

Special thanks to Google for their amazing Google Summer of Code program!

By Adriano Marques, Director of Umit Project and Google Summer of Code mentor

Gulliver powers Lonely Planet’s Trippy travel planning apps

Gulliver is an open source platform from Google that helps users plan trips in real time with their friends. Using Gulliver, you can create applications for mobile, iGoogle, and mobile web platforms that make it easy to build and share itineraries using Google Maps resources and Lonely Planet recommended itinerary items.

You can use Gulliver to:

• Create, share, and sync trips between the AppEngine web application, iGoogle, and the Android application
• Create scheduled and unscheduled trips
• See Lonely Planet recommendations for hotels, activities, sights, restaurants, and more for top destinations
• Seamlessly show parallel Google results when there are no Lonely Planet results
• Rate and comment on items
• Create custom items
• On iGoogle, drag and drop items from the map into the itinerary list
• On Android phones, take photos from within the app

A fully functional consumer app has been built on the Gulliver code base: Lonely Planet’s Trippy. Trippy combines the travel expertise of Lonely Planet with the power of Google web search and Google Maps.

Trippy for iGoogle (click image to enlarge)

Trippy for mobile web (click image to enlarge)

Guilliver was created as a 20% time project, a well-known part of our philosophy and company culture which enables engineers to spend one day a week working on projects that aren't necessarily in our job descriptions. We can use the time to develop something new, or if we see something that's broken, we can use the time to fix it. And now you can take these open source apps and run with them! We’re making that possible by rolling them out to the open source community under the Apache license.

Want to get involved with Gulliver and help us make it an even better application? Join the Gulliver team! To get started, just visit our project page, join the community, and download the code.

By David Yu Chen and Alex Cuthbert, Google Gulliver 20% time team

Greetings from Santa Kurara, Kariforunia

Hello from the Unicode Conference in Santa Clara, California, where the Maps Transliteration team is giving a talk about ICU-based transliteration. Transliterating this originally Spanish city name to Japanese, we get サンタ・クララ, which (when morphed back to the Latin writing system) becomes “Santa Kurara.”

Machine Transliteration is an active area of research (slides), which means it can be rather challenging in general. Typically, transliteration emulates the pronunciation, but sometimes it also preserves some aspects of the original written spelling. We created transliteration modules with the open-source ICU library for languages that have highly regular spelling; if you’re using Google Maps in Japanese, Russian or Chinese, you can see how we use it to display labels in both the local language and your own:




Today, we’re announcing the contribution of our ICU transliteration rules for Czech, Italian, Japanese, Korean, Mandarin, Polish, Romanian, Russian, Slovak and Spanish to the Unicode Common Locale Data Repository. (For languages with very irregular spelling, like English, we supplement ICU with some more advanced techniques.) If you would like to try writing rules for your own language, have a look at the instructions in the ICU user guide.

アスタ・ラ・ビスタ — “Asuta ra bisuta,” from sunny “Kariforunia!”

By Sascha Brawer, Martin Jansche, Hiroshi Takenaka, and Yui Terashima, Maps Transliteration Team

OpenStreetMap's New API Database Server

By Ellen Ko, Open Source Team

A few weeks ago Mano Marks, a Geo Developer Advocate here at Google, informed the Open Source Programs Office of OpenStreetMap's server upgrade fundraiser. Recognizing the good work that OpenStreetMap does by providing free geographic data of the world, we were happy to respond. We donated 5,000 GBP to the cause, and along with contributions from around the world, OpenStreetMap exceeded their goal in a single week! Congratulations to OpenStreetMap for building such an active and devoted community.

If you are interested in a collaborative project to create a free editable map of the world, we encourage you to check out their site and see what all the excitement is about.

GeoWebCache 1.0 and Google Summer of Code

By Arne Kepp, OpenGeo

OpenGeo and the GeoWebCache team are pleased to announce the release of version 1.0 (download). GeoWebCache is a tile cache for web mapping servers designed to significantly improve the performance of your service and provide easy integration with software such as OpenLayers, Google Maps, Microsoft Virtual Earth and Google Earth. The response time for cached tiles is measured in milliseconds, making it possible to serve hundreds of simultaneous clients using modest hardware.

GeoWebCache has benefited greatly from contributions resulting from the Google Summer of Code™ program. In 2007, Chris Whitney developed jTileCache, the starting point from which GeoWebCache has gradually evolved. This year, Marius Suta, primarily focused on a REST API for configuration, spent the summer on GeoWebCache, and the resulting functionality is available in our 1.0 release. GeoWebCache also underwent improvements to cache KML with support from Google's Open Source Programs Office as part of a project to enable GeoServer to make placemarks and vector data available through Super Overlays. The new Google Earth functionality in GeoServer can be seen in version 1.7.1, which ships with an integrated GeoWebCache.

GeoWebCache will continue to evolve at a rapid pace with a continually growing open source community. Planned features include the ability to let users specify what WMS parameters can be varied by the clients, so that each layer can forward filters and support multiple sets of tiles. Also, steps are being taken to enable GeoWebCache to automatically expire tiles as the data changes on the backend or styles are modified. To facilitate these features, storage of tiles and meta information will be improved. A nice, AJAX based frontend for tasks such as configuration, seeding and testing the layers is also in the works.

Accelerate Your Maps with GeoWebCache

By Chris Holmes, OpenGeo

As far as web browsers are concerned, our maps don't change all that often, and rendering map images can be very time-consuming. Serving images, on the other hand, requires no computation and is trivial to implement. Google Maps is a good example of this, as all of the maps are pre-rendered and divided into smaller images (tiles). In 2006, a group of Open Source Geo developers met at the annual FOSS4G conference to figure out how to turn the Web Map Service (WMS) standard that all projects implemented in to a tile based service, hatching the WMS-C recommendation. OpenLayers had a quick client side implementation, and soon TileCache provided a Python implementation to cache any WMS Server. Many GeoServer users started using TileCache, but a pure Java solution was desired to ease deployment.

Enter Google's Summer of Code. Through OSGeo, Chris Whitney was mentored by GeoServer developers to build JTileCache, a standalone web application for caching WMS tiles that works in any Java servlet container. Not bad for one summer, right? After the project's completion it was picked up by OpenGeo, the geospatial division of The Open Planning Project, for integration with GeoServer. Arne Kepp took over as lead developer, evolving it to become GeoWebCache, using the same framework and libraries as GeoServer. This means installation with GeoServer is as easy as downloading (.zip) a plug-in and dropping it in. It is completely standards based, so the standalone download can be run in its own server against any compliant WMS.

GeoWebCache not only turns any dynamic mapping server in to a high performance cache for the WMS-C recommendation, but the tiles are also is instantly available for direct use in Google Maps, Virtual Earth and as Super-Overlays in Google Earth. Other features include pluggable caching backends, like JCS and a pure disk cache, and support for 'MetaTiling' for better labels across tiles.

With the 0.8 release (download) GeoWebCache is quickly approaching maturity, and already an outside contributor has contributed a patch - for Mobile Google Maps compatibility - a great sign for a young open source project. Google's Open Source Programs Office is also currently funding investigation to have GeoServer make placemarks and vector data available through Super Overlays, potentially with GeoWebCache integrated for accelerating the responses.