Roboat Routing and Itinerary Planning for Tourists

by
Tyler James Wasser
Submitted to the Department of Electrical Engineering and Computer
Science
in partial fulfillment of the requirements for the degree of
Master of Engineering in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 2020
○
c Massachusetts Institute of Technology 2020. All rights reserved.

Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Department of Electrical Engineering and Computer Science
May 12, 2020

Certified by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Daniela Rus
Andrew (1956) and Erna Viterbi Professor, CSAIL Director
Thesis Supervisor

Accepted by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Katrina LaCurts
Chair, Master of Engineering Thesis Committee
2
 Roboat Routing and Itinerary Planning for Tourists
by
Tyler James Wasser

Submitted to the Department of Electrical Engineering and Computer Science

on May 12, 2020, in partial fulfillment of the
requirements for the degree of
Master of Engineering in Electrical Engineering and Computer Science

Abstract
When a tourist visits a new city for a brief trip, they will often ask themselves many
questions. which attractions should I visit? How should I get from one to the next?
Should I stay at this point of interest longer or move on? This makes creating an
itinerary hard for many people. We have developed a solution to this problem for a
tourist in Amsterdam.
This thesis presents work in creating a system to allow tourists to utilize au-
tonomous vessels and an itinerary optimization algorithm to navigate through Am-
sterdam’s canals for sightseeing. The system interfaces with the tourist through a
smartphone application that creates and displays an optimized tour of Amsterdam
that they will follow. Our work also focuses on routing an autonomous boat between
points to allow for self-navigation. The result is an enhanced experience for tourists
when visiting a new city.

Thesis Supervisor: Daniela Rus

Title: Andrew (1956) and Erna Viterbi Professor, CSAIL Director

3
4
Acknowledgments
I would like to start by thanking my family, my parents Jim and Dariene, my brother
Hunter and my sister Halle for everything that they have done for me throughout my
whole life and over these past 5 years at MIT. Your love and support has helped me
so much throughout this process.
Next, I want to thank Daniela Rus who has been an amazing supervisor to me
throughout this process. She has always provided me with incredible direction and
the experience that I have gained researching under her supervision was unparalleled.
I also want to show my appreciation for all of my professors and teachers who have
instructed and coached me throughout my entire education.
I would next like to show my appreciation for the Roboat team and the entire
Senseable City Lab. Thank you to Fabio Duarte for being a great project lead and
Wei Wang for his invaluable instruction throughout the project. Also, I would like to
extend my appreciation for the other collaborators that I worked with, Tixiao Shan,
David Gutierrez, Pietro Leoni, and Niklas Hagemann.
Finally, I want to thank all of the friends I made at MIT who created an incredible
experience. You have all made my college years unbelievable and I would not trade
them for anything.
Support for this research has been given in part by Amsterdam Institute for Ad-
vanced Metropolitan Solutions and we are very grateful for it.

5
6
Contents

1 Introduction 13
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Itinerary Planning Problem . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Roboat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Tourism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Itinerary planning . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.2 Roboat Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Related work 19
2.1 Optimal Tourist Problem . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Roboat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Google Maps API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 System for Itinerary Planning 23

3.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Mobile Application Design . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 App Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Itinerary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7
 3.2.5 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Back End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Tourist Path Optimization Algorithm . . . . . . . . . . . . . . 30
3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Amsterdam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Points of Interest . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.1 Sample Itinerary . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.2 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Roboat Routing 37
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Roboat Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Example Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Overall System Summary . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Conclusion 43
5.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Takeaways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A Software Packages 47
A.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2 App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

B Points of Interest 49

8
List of Figures

1-1 Rendering of a Roboat ferrying passengers in an Amsterdam canal from

the Senseable City Lab . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3-1 The homepage of the mobile application displaying the option for a
tourist to choose a city from the list of cities the app supports . . . . 25

3-2 The preferences form that has been filled out by a tourist with their
time constraints and preferences for Amsterdam . . . . . . . . . . . . 27

3-3 An itinerary displayed to the tourist on a trip to Amsterdam . . . . . 28

3-4 A sample map of a trip through Amsterdam with markers for each stop
on the itinerary and polylines connecting each point of interest to the
next by following waypoints in the canals . . . . . . . . . . . . . . . . 29

3-5 A map of the Amsterdam canals created by using coordinate points

from our dataset consisting of coordinates of the center of the canal at
10m increments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3-6 An example of a route from point A to point B. The route, R(A,B), is

made up of three legs that are color coded. The black dots in the legs
are the waypoints that encode that leg and are coordinate pairs. . . . 33

3-7 Screenshot of an example itinerary generated with a time budget of 4

hours in Amsterdam with preferences for landmarks and museums . . 35

3-8 Screenshot of an example map generated with a time budget of 4 hours

in Amsterdam with preferences for landmarks and museums . . . . . 36

9
4-1 User displays throughout the process of a tourist running our system
from end to end. The top left is the homepage where the tourist
initiates the tour. The top right image is the Preferences page with
their information of their tour entered. After the itinerary has been
created, the tourist is taken to the itinerary page, shown in the bottom
left image. The map of the itinerary can be seen in the bottom right. 41

10
List of Tables

3.1 The types for each parameter in the POST request. Time is in minutes.
The weight from Cultural-Other are all 1.0 if the user checked that
preference or 0.5 if they did not . . . . . . . . . . . . . . . . . . . . . 29
3.2 An example of a distance matrix, D, where the length of a path from
point 1 to point 2 is D[1][2] . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 A line from the database page that stores the points of interest for
Amsterdam. The index field is used as a unique id for each location. . 30
3.4 An example itinerary generated with a time budget of 4 hours in Am-
sterdam with preferences for landmarks and museums . . . . . . . . . 35

B.1 The points of interest identified for Amsterdam with their classification 49

11
12
Chapter 1

Introduction

1.1 Background

Suppose a tourist who is interested in history is visiting Amsterdam for the first time
and has five hours to explore. This task may come across as daunting to this tourist
as there are many attractions that they would wish to incorporate into their trip
and not a lot of time to see them all. It is hard to create an itinerary with such a
short time budget while still seeing the attractions that are most interesting to them.
We propose in this thesis a system that will enable for efficient route planning with
multiple objectives and constraints. This system contains a friendly user interface
where a tourist can provide how long they will be visiting a city and what they are
interested in. This system will find a route through different points of interest that
would intrigue the tourist and provide an itinerary for them, complete with where
they should visit, how they should get from one point to another, and how long they
should spend at each attraction. We also present a use of this system in coordination
with autonomous boats that can be used to transport the tourist throughout their
trip creating an autonomous and pleasant travel experience overall.

13
1.2 Itinerary Planning Problem

Creating an itinerary when traveling is something that I have always found to be

difficult and time consuming. Tripadvisor alone has 881 points of interest listed for
Amsterdam. Sorting through all of these attractions and checking the reviews is very
tedious. This makes an optimized itinerary solution interesting and useful to many
tourists who do not have the time to create their own itinerary. We formulated this
problem as an Optimal Tourist Problem proposed by Yu et al. We want to create an
itinerary for a tourist to visit points of interest with associated rewards for spending
time at each point, and to maximize their reward with a constraining time budget.
We implemented this optimization for points of interest around Amsterdam utilizing
the canals in Amsterdam as an avenue for transportation.

1.3 Roboat

As research and development into autonomous vehicles continues to advance rapidly,

innovative applications of these robots in urban settings are progressing in creative
ways. These new technologies have displayed the ability to accelerate mobility in cities
through automating ride sharing and public transportation. The Roboat project[6] is
a five year research project and collaboration between researchers at various MIT labs,
the Senseable City Lab[8] and the Distributed Robotics Lab[9], and the Amsterdam
Institute for Advanced Metropolitan Solutions[5]. The project aims to design an ASV
to navigate the Amsterdam canals. Roboat is a five year project and is currently in
the fourth year of development. During this time, the project has taken many strides
in constructing a package for autonomous control of the boats, including perception,
dynamic control, and multi-Roboat coordination. Figure 1-1 shows a rendering of a
Roboat in an Amsterdam canal.
The project has identified some use cases that will positively impact Amsterdam,
such as tourism, waste collection, and shapeshifting into structures such as platforms
or bridges[11]. We have developed a system for routing a Roboat between points and

14
Figure 1-1: Rendering of a Roboat ferrying passengers in an Amsterdam canal from
the Senseable City Lab

can be utilized alongside our itinerary planning system in order to allow tourists to
make use of autonomous boats to travel throughout Amsterdam.

1.4 Tourism
This thesis concentrates its work on addressing tourism and presents a system to
both route a tourist to and from the different attractions in Amsterdam along with
an ASV from one point to another. Tourism was a significant use case that we identi-
fied for Roboat to address. A tourist who is visiting Amsterdam will want to navigate
through the city swiftly from one sight to the next while still visiting every attraction
that interests them. Since a tourist would most likely not have transportation in
Amsterdam, they would normally have to resort to public transportation or tempo-
rary means such as a rental car or bike. Autonomous boats for temporary use can
be substituted for these modes of transportation for tourists, providing them with

15
convenient transportation throughout Amsterdam.
One problem that some tourists run into when visiting a city is that they have
trouble deciding which points of interest they want to visit and how to plan their
itinerary though these points. We incorporate past work into solving this problem
and present the tourist with an itinerary to route them through the locations that
they would find most interesting based on their personal preferences. Giving the
tourist a route to take and a means of autonomous transportation through the city
allows them to spend their time sightseeing not planning.

1.5 Contributions

The work presented will build off of past work from both the Roboat project and
the Optimal Tourist project from the Distributed Robotiscs Lab. We present a sys-
tem to create an itinerary and route a tourist through different points of interest in
Amsterdam with the ability to route a Roboat from one location to another

1.5.1 Itinerary planning

First, we present a system that creates an itinerary for a user based on their time
constraint and preferences that they can access via a mobile application on their
smartphone. We will implement an itinerary optimization algorithm that will plan
the trip for the user with their given parameters. Next, we will extend past work
on an application for trip planning in other cities to allow a user to route a tour
through Amsterdam and to make use of the canals. Finally, we will present an API
for displaying a map to the user of their trip with their paths highlighted along the
canal routes, creating a better user experience for a tourist in an unfamiliar city.

1.5.2 Roboat Routing

Additionally, we propose a system for routing the Roboat from one location to an-
other. The system will give the Roboat waypoints along the route to follow, and the

16
boat will navigate from one to the next using its planning and perception to avoid
obstacles.

1.6 Problem Description

Our work aims to create a full system for a tourist visiting Amsterdam that provides
them with an itinerary and a means for getting from one point to another. We split
this problem into two main stages: tourist trip planning and Roboat routing. In order
to achieve these goals we decided to incorporate the system into a mobile application
that we have been developing for tourists in city with only land based travel options.
This gives the tourist the freedom to create a travel plan from any location. This
also grants a visitor the option to view their trip while they are exploring the city
and use the capabilities of their smartphone to update their tour. This mobile app
is the main interface for the system, and the tourist will use it follow a travel plan
and route Roboats to move around the city. The application has the functionality
to communicate with a Roboat and begin routing the vessel to the next stop on the
trip.

For example, a tourist can open the app and input that they will be touring
Amsterdam from 9:00 AM until 1:00 PM, and they are interested in museums and
landmarks. The system will compute an itinerary that gives the tourist a four hour
tour of Amsterdam. This itinerary will be comprised of many different steps, where
it will explain how they should travel from one point to the next and how long they
should stay at each location. The user can view this itinerary as a list or a map, and
can use the app to tell the Roboat which step they are currenly on so that it can
autonomously ferry them to the next location.

Overall, this solution creates a great experience for a tourist to become familiar
with Amsterdam using Roboat.

17
1.7 Outline
In chapter 2, we discuss prior research and how it relates to this work. In chapter 3,
we detail the work done to the itinerary planning system and detail the pieces that
make up this process. We also show an example of the output returned by the system
given a sample input. In chapter 4, we describe the system we designed for routing
the Roboat and how this is accommodated into the application. Finally, in chapter
6 we discuss the conclusions of this work and give suggestions for future extensions.

18
Chapter 2

Related work

In this chapter we discuss related work, including Tourist Path Optimization, the
Roboat project, and Google Maps API, and how they relate to this research.

2.1 Optimal Tourist Problem

The Traveling Salesman Problem is an interesting one to researchers who attempt to

plan a route for a tourist through a city. This thesis uses work on a variant of the
Prize Collecting Travelling Salesman Problem where a reward is dependant on the
time spent at each node along the path [13]. This problem is inherently similar to the
Orienteering Problem (OP)[1][12] where a fixed reward is received when a point of
interest is visited. In [4] there are time dependent rewards for visiting each point, but
the solution is only applicable to limited reward function classes. We can read about
work into creating an optimal itinerary from [3] through a recursive greedy algorithm
[2], however this and other work [14] do not provide close enough to optimal solutions
for practice and focus on how the different points of interest’s attributes can be used
to optimize a path.
In [15], the authors create a graph of the problem and solves a single Multiple
Integer Program(MIP) with an optimal solution while using time dependent rewards
at each point. Our system will use this algorithm to autonomously create an itinerary
for a tourist.

19
 This work also extends an earlier iteration of a mobile application from the Op-
timal Tourist project that employs this problem solution for finding a route through
cities like Boston or New York. This thesis takes this app and extends it to include
Amsterdam and also account for water travel. In addition, it uses a Breadth First
Search (BFS) in order to find the shortest path between different points of interest
in the city via the canals.

2.2 Roboat

This thesis presents a system for routing an ASV and it is aimed to work with Roboat.
The Roboat project[6] is our motivation for designing this system, so it is constructed
to communicate and interface with the Roboat software. The Roboat is run by a PC
that is located on the boat and can communicate through WiFi or 4G connection.
It also utilizes datasets describing the coordinates of the center of each canal in
Amsterdam created by Roboat project. Roboat also has done extensive research into
planning and perception for autonomous travel through the canals which will be taken
advantage of by the routing system.

2.3 Google Maps API

Google Maps is the most popular mapping application in the world by a considerable
margin. It provides accurate and complete maps of every region of the planet along
with optimal routing for driving, walking, or taking public transportation wherever
viable. Google made their API accessible for developers to use in their own websites
or applications and provide great support for their features. The mobile application
we developed for tourists employs this API for creating a map for the user to view
their trip and display their paths when using these modes of transportation.
Google Maps has many features in their API that allow a developer to customize
a map, such as custom labelled waypoints, polylines to connect two points, and the
ability to create a path between two points that "snaps" to roads or walkways. Google

20
Maps, however, does not support paths that follow the canal systems of Amsterdam.
This is something that would greatly enhance the user experience of the application,
and we present an API that can augment the maps we can display with Google
Maps. We looked into much of the documentation for Google Maps’ built in API
functionality and used it as a guideline for how to build our application to created
paths that snap to the canals.

21
22
Chapter 3

System for Itinerary Planning

In this chapter we will detail our itinerary planning system and explain how it works
for each step along the way to create and display an itinerary for a tourist.

3.1 System Overview

Our system is designed to provide a tourist with everything that they will need when
they are planning a trip through Amsterdam. The user will first provide how long
they expect to be sightseeing and what their interests are and the system will generate
the optimal itinerary and give details on how to travel between the different stops
and how long to stay at each. We split this system up into two major processes, user
interface and itinerary optimization, that work together to allow users to interface
with the system.
This itinerary planning process is initiated by the tourist in a smartphone appli-
cation. The user will enter their time constraints and preferences in the app, which
will send a query to our server containing these parameters. The server creates an
optimal route that consists of an ordered list of the attractions to see, how long to
spend at each, and information on traveling between the points. This itinerary is
returned to the app which displays the itinerary split into the different steps. The
user can then view their trip in this itinerary view or through a map interface that
allows them to see the points of interest that they will be visiting and the route that

23
they will be taking. In the following sections we will give more detailed descriptions
of each piece that comprises our system.

3.2 Mobile Application Design

This section addresses in detail the design and implementation of each section of the
application.

3.2.1 App Overview

The app that we have developed is extended from previous work researched for tourist
route planning in cities that rely on land travel such as driving, walking, and public
transit. Adapting this app, first we added an option to choose Amsterdam as the city
to tour. Once the user chooses their city, are then given the option to input their
beginning and end time of the tour that they would like to plan and choose which
categories of attractions they are interested in visiting. Their response is sent to an
external server that takes the time and preferences values and finds a solution for
a tour to maximize their reward using the Tourist Path Optimization algorithm[13].
When an optimal route is found, the response is sent to the app which displays the
itinerary created for the tourist. They can then view each leg of the trip and see
how long the algorithm suggests they spend at each sight. The traveller then has the
option to view their trip on a map, where a marker is added for each stop and the
route following the canals can be viewed. They can switch between these two screens
easily, and if they want to can even return to the homepage and restart their tour if
they want to adjust their overall response and get a new tour.

3.2.2 Homepage

The homepage features a continuously scrolling bar of the cities that are available
to be used in this app to optimize a trip. The work for this thesis is concentrated
when Amsterdam is selected, but there are also options for Boston, New York, and

24
Singapore. These cities are displayed in a manner where the user can scroll through
the options and when they reach the bottom, the list is recycled and the first option
appears below the last one. Each button also also has an image in the background
of the city described by that choice. The image chosen for Amsterdam showcases the
canals of Amsterdam and the vibrant lights of the city to entice a user to plan a trip
in Amsterdam. There is also an option to create an itinerary on the homepage which
takes the user to the preferences input form without choosing a city at this step. The
city can always be chosen or adjusted on the following form. The homepage can be
viewed in Figure 3-1.

Figure 3-1: The homepage of the mobile application displaying the option for a tourist
to choose a city from the list of cities the app supports

25
3.2.3 Preferences

The user is routed to an input form from the homepage. If a city is chosen from the
homepage then this is imported into the form automatically. If the user wants to
update their city selection, there is a drop down box with the list of possible cities to
choose from. Next, they are given the option to choose the start and end time for the
trip they are planning. These create the time constraints that the Tourist Path Opti-
mization algorithm will use and can be adjusted from a clock interface or typed into
the text box. Below, there is a form for the user’s preferences. The tourist can choose
to check as many as they like of the following options for their preferred points of in-
terest: cultural, landmarks, museums, outdoors, theaters/stadiums, zoos/aquariums,
and other. There is a final choice that differentiates Amsterdam from other cities
in the app by choosing to use boats for travel. A user can only interact with this
checkbox when they have chosen Amsterdam as the city. The user submits this form
when they have accurately filled it out and wait for an itinerary that is optimized for
their specific constraints. An example of the preferences input form can be seen in
Figure 3-2.

3.2.4 Itinerary

After the user submits their responses, a request is sent to the server to optimize a
trip for that tourist. Once the application has received the itinerary for a specific
tourist, it returns this in a list for the tourist to view their trip overview. Each entry
in this list gives a step in the travel plan which consists of the location, travel means,
and a recommendation for how long to stay at that point. Each itinerary list entry
is also a button that can be clicked and interacted with. If the list is too long to
view each item on one screen, it also becomes scrollable so the user can see each leg
of the journey. They have the option to view this itinerary on a map and to share
their trip. Sharing the trip creates the capability of showing friends the tour that
was created and allows a tourist to share their experience with family and friends at

26
Figure 3-2: The preferences form that has been filled out by a tourist with their time
constraints and preferences for Amsterdam

home. This also opens the door for adding a social aspect to the application where
users can either share their itinerary or view another tourist’s trip and meet up with
friends along the way. A sample itinerary for Amsterdam can be seen in Figure 3-3.

3.2.5 Maps

The final page to be described is the Maps interface. This page displays a Google Map
that pans and zooms to center and show the city selected. Overlayed on this map
are markers for each location where there is a stop planned, and polylines connecting
these points that follow the canals by using waypoints along the canal. This map
can be interacted with by the tourist by panning, zooming in or out or clicking on a
marker to see which point of interest it represents. The map displays the route of the

27
 Figure 3-3: An itinerary displayed to the tourist on a trip to Amsterdam

tour from start to finish. This page can be switched back to the itinerary but stays
loaded in the app’s memory in order to decrease render time after it has been created
once. Figure 3-4 shows an example map

3.3 Back End

This section describes the structure for the back end server that the application
communicates with to create and display a trip for a tourist.

3.3.1 Overview

We employ a server that runs a REST framework that utilizes HTTP as its transfer
mechanism. The server is written in java using an Eclipse Jersey[7] implementation.
Once running, this server listens for HTTP POST requests with the following pa-

28
Figure 3-4: A sample map of a trip through Amsterdam with markers for each stop on
the itinerary and polylines connecting each point of interest to the next by following
waypoints in the canals

rameters: city, time, cultural weight, landmarks weight, museums weight, outdoors
weight, theaters/stadiums weight, zoos/aquariums weight, other weight. These pa-
rameters are sent as key-value pairs in the body of the POST request from the app
to the server. The types can be seen in Table 3.1.

Once a valid POST request has been received, the server runs the tourist path
optimization algorithm on the parameters received and determines a solution. The
tourist path optimization algorithm creates a graph to solve by setting the locations

city time cultural landmarks museums outdoors theaters... zoos... other

string int double double double double double double double

Table 3.1: The types for each parameter in the POST request. Time is in minutes.
The weight from Cultural-Other are all 1.0 if the user checked that preference or 0.5
if they did not

29
 1 2 3 ... n
1 0 D[1][2] D[1][3] ... D[1][n]
2 D[2][1] 0 D[2][3] ... D[2][1]
3 D[3][1] D[3][2] 0 ... D[3][n]
... ... ... ... 0 ...
n D[n][1] D[n][2] D[n][3] ... 0

Table 3.2: An example of a distance matrix, D, where the length of a path from point
1 to point 2 is D[1][2]

as nodes and using distance matrices to determine edge lengths of the graph. Our
distance matrix, D, stores the edge lengths, in seconds, of a route between two points
of interest. D[1][2] therefore specifies the length of the route from point 1 to point 2.
A representation of a distance matrix can be seen in Table 3.2.
The server stores the locations, id, and classifications, along with other data that
is not relevant to this work such as secondary classifications, for each point of interest
in a Hyper SQL Database (HSQLDB) that has a page for each city. In Table 3.3 we
show an example of the applicable data of a line in the page for Amsterdam.
Name Index Category
Anne Frank House 0 Museums

Table 3.3: A line from the database page that stores the points of interest for Ams-
terdam. The index field is used as a unique id for each location.

3.3.2 Tourist Path Optimization Algorithm

The tourist path optimization problem formulation is as follows:

Given:

∙ the set of nodes, 𝑉 = {𝑣1 , 𝑣2 , ...𝑣𝑛 }

∙ the set of edges, 𝐸, where edge 𝑒𝑖,𝑗 connects from node 𝑖 to node 𝑗

∙ the set of distances, 𝐷, where 𝑑𝑖,𝑗 is the length of 𝑒𝑖,𝑗

∙ the set of time dependent reward functions, 𝐹 = {𝑓1 (𝑡), 𝑓2 (𝑡), ..., 𝑓𝑛 (𝑡)},
where 𝑓𝑖 (𝑡) is the reward for staying at node 𝑣𝑖 for time 𝑡. These are
each continuous and satisfy 𝑓 ′ (𝑡) > 0 and 𝑓 ′ (0) > 0

30
 ∙ The maximum time, 𝑇

Find: the set of nodes, 𝑉 ′ , the set of edges, 𝐸 ′ that connect from each node in 𝑉 ′
to the next, and the time, 𝑡𝑖 , spent at each node to maximize the following constrained
reward function.

∑︁
max 𝑓𝑖 (𝑡𝑖 )
𝑖∈𝑉 ′

∑︁ ∑︁
subject to 𝑡𝑖 + 𝑑𝑖,𝑗 ≤ 𝑇
𝑖∈𝑉 ′ 𝑖,𝑗∈𝐸 ′

We create a graph of all the possible nodes and edges with their respective lengths.
This graph is formulated into a ILP and is solved using Gurobi as an ILP solver. Our
solution gives us 𝑉 ′ and 𝐸 ′ , along with 𝑡𝑖 for each location 𝑖 in 𝑉 ′ . With this we have
the locations that will be visited, the time to get from each node to the next, and
the time spent at each place. This is the basis for our itinerary and these parameters
need to be sent to the app so that it can display the itinerary created.

3.3.3 Response

After the graph is solved, the solution is sent to the application as a response in a
JSON Object. The response object has five entries: start, steps, end, city, and reward.
Start maps to a point of interest (poi) with an attribute for each piece of data that
was stored in the database for that poi and a duration to stay at that location in
minutes. Steps maps to an array with each step of the path as its elements. Each
entry in this list has the poi information, the duration to stay at that location, the
travel type to that location, and the travel duration in minutes. For Amsterdam the
travel type is always Roboat. End points to a poi for the last location, the travel type,
and the travel duration. The city field corresponds to the city that the itinerary was
created for and reward is the overall reward that the optimization algorithm achieved.

31
Figure 3-5: A map of the Amsterdam canals created by using coordinate points from
our dataset consisting of coordinates of the center of the canal at 10m increments.

3.4 Amsterdam
When Amsterdam is the chosen city, we needed to incorporate our own API in order
to create a correct map of the city and identify the sights that tourists would want
to visit. This section describes how this was accomplished.

3.4.1 Routes

To create our API for displaying the routes overlayed on the map of Amsterdam, we
had to split the canals into the different routes that we would need. We started with
our dataset of 17,973 coordinate points and created a map of the canals. We further
reduced this dataset down to 1,797 points to make the calculations faster and make
it possible to identify different routes. In Figure 3-5 you can see a map of the canals
that we created.
We had to split this map into smaller pieces in order to create the routes from each

32
Figure 3-6: An example of a route from point A to point B. The route, R(A,B),
is made up of three legs that are color coded. The black dots in the legs are the
waypoints that encode that leg and are coordinate pairs.

point of interest to the others. We broke this mapping down into the smaller pieces
that we call legs. The legs split the map at each junction into smaller subroutes that
can be concatenated to represent a route from one point to another. Each leg is stored
on the server with waypoints that can be used to display an accurate representation
of the route. We also save the legs that make up a route from point A to point B,
R(A,B). In Figure 3-6 we can see a visualization of a route between two points.

3.4.2 Points of Interest

We needed to add new points of interest that a tourist would like to see on their trip.
For this we used Tripadvisor[10] to identify the sights that could be accessed via canal
with the highest rating in Amsterdam. Once we had a list, we classified them using
their Tripadvisor category into one of the following: cultural, landmarks, museums,
outdoors, theaters/stadiums, zoos/aquariums, or other. Once these points were clas-
sified and added to the HSQLDB, we needed to identify their location on the route of
the canal where the boat can dock. Finally, we used a BFS to find the fastest route
between each two points by using our dataset of the points of the canal. After finding
the fastest route, we store the legs that are required for each route in the respective
route. The complete set of points of interest that have been identified can be seen in

33
Table B.1 in the Appendix along with their respective category classification.

3.5 Results
In this section we will provide an example and show how this example is processed in
our system and the what the final result is. We will also provide results on how long
this system takes from start to finish through experimentation.

3.5.1 Sample Itinerary

Here we will provide an example itinerary returned from out itinerary planning sys-
tem. If we choose our time budget as four hours (from 9:00 AM to 1:00 PM) and
select our preferred locations as museums and landmarks, we will create the following
query:

Create Itinerary(city=Amsterdam, time_budget=240, cultural=.5, museums=1,

landmarks=1, theaters=.5, zoos=.5, outdoors=.5, other=.5)

The response from the server will specify the following:

start: {location: De Duif, stay_duration: 12.659}

steps: [{location: The Jordaan, stay_duration: 20.05, travel_type: ROBOAT,
travel_duration: 11}, ...for each step in Itinerary 3.4]
end: {location: De Duif, travel_type: ROBOAT, travel_duration: 23}

We can see an entire itinerary created with these parameters in Table 3.4. This
itinerary displayed to the user in the app can be seen in Figure 3-7, along with the
map of the tour in Figure 3-8

3.5.2 Efficiency

We tested our system with a time duration of ten hours and random initializations of
the weight parameters in Amsterdam for 25 trials and recorded how long it took for
the system to create an itinerary and return it. Our experiments yielded an average

34
 Start from De Duif, stay for 13 minutes
Take a Roboat to Rembrandt House (11 minutes), stay for 20 minutes
Take a Roboat to Centraal Station(17 minutes), stay for 27 minutes
Take a Roboat to St. Nicholas Basilica (6 minutes), stay for 20 minutes
Take a Roboat to De Poezenboot (9 minutes), stay for 20 minutes
Take a Roboat to The Jordaan (12 minutes), stay for 12 minutes
Take a Roboat to Anne Frank House (5 minutes), stay for 20 minutes
Take a Roboat to Westerkerk (4 minutes), stay for 20 minutes
Return to De Duif by Roboat (23 minutes)

Table 3.4: An example itinerary generated with a time budget of 4 hours in Amster-
dam with preferences for landmarks and museums

Figure 3-7: Screenshot of an example itinerary generated with a time budget of 4

hours in Amsterdam with preferences for landmarks and museums

35
Figure 3-8: Screenshot of an example map generated with a time budget of 4 hours
in Amsterdam with preferences for landmarks and museums

time of 0.2264026 seconds with the slowest being 0.391086 seconds. We believe that
this is sufficient efficiency for our system.

36
Chapter 4

Roboat Routing

In the last chapter we described our system that creates an itinerary for tourists in
Amsterdam. In order for a tourist to follow this itinerary, they will need transporta-
tion from point to point. We propose using our system in connection with autonomous
boats from the Roboat project to fully automate itinerary planning and touring of
Amsterdam. In this chapter we detail how the system communicates with the Roboat
to route a path from one point of interest to another.

4.1 Overview

We believe that we can create an entirely autonomous tourism experience by integrat-

ing Roboat transportation into our system. Finding transportation in a foreign city
adds more steps to planning a trip, however, incorporating Roboat gives the tourist
a reliable method for transportation in Amsterdam. We have developed a protocol
for communication between the application and the Roboat to route the boat from
one location to the next. The user initiates this process from the itinerary page by
clicking on the step of the trip plan. This sends a POST request to the server that
was described in chapter 3. This request has three parameters: city, origin, and
destination. When the server receives this request, it selects waypoints to route the
Roboat and sends those to a client listening on the Roboat computer.

37
4.2 Server

The Roboat routing system utilizes the same server outlined in an earlier section of
this paper. Originally, the server has nothing saved as the route that is currently
being routed. This is updated when the server determines that it needs to create a
route for the Roboat. This system listens for a different HTTP POST request with
parameters for the city, origin, and destination for the route requested. The origin and
destination are points of interest of the tour that the tourist created in the app. Once
these parameters are processed, the server determines a route consisting of waypoints
defined as latitude/longitude pairs that can route the Roboat from the origin to the
destination. This route of waypoints is saved in JSON format and is returned in this
configuration to the app. When the app receives this response, it establishes that a
route was created for the Roboat to follow and a successful completion message is
displayed to the user so that they know that their request was processed. The route
is saved in the format of a JSON Array labeld "Route." This JSON Array consists of
entries that represent waypoints specified by their key-value pairs with keys, "Lat"
and "Long". The values of these are the latitude and longitude of each waypoint
respectively. This route is saved as the route that the Roboat is currently routing
and this updates the respense to the Roboat client.

4.3 Roboat Client

For the Roboat to be a client of this server, we created a listener to run on the Roboat
computer when it is set up to ferry a tourist. This listener sends HTTP GET requests
to the server every five seconds, and processes the response. When there is no route
specified by the user yet, the server responds with a "waiting" response. This tells
the Roboat that it does not have a route yet and the Roboat does nothing. Once
the user requests a route and the server finds and updates the current route, it will
send this route to the Roboat. The route is sent in the JSON format described in the
previous section. Once the listener obtains a route, it stops sending GET requests

38
and processes the response. The Roboat saves a list of the waypoints to guide its
route and begins to chauffeur the rider. The coordinates of the waypoints are meant
to be a guideline for the Roboat and are set at the junctions and curves of the canal.
This allows the Roboat to take advantage of its planning and perception algorithms
to autonomously navigate the canals. The final waypoint in the list corresponds to
the destination and once this point is reached the routing is complete for this step of
the trip. The Roboat then sends a POST request to the server to reset the current
route and the current route is re-initialized on the server.

4.4 Example Route

Here we will provide an example route returned by our routing system. For this
example we will make the origin point the Anne Frank House and the destination
point The Jordaan. We will make the following query:

Route(city=Amsterdam, origin=Anne Frank House, destination=The Jordaan)

The response returned by the server will be the following:

route: [{"lat": 52.37515, "long": 4.8835},

{"lat": 52.37518, "long": 4.88336},
{"lat": 52.37466, "long": 4.88061}]

4.5 Overall System Summary

In summary, we have presented a system to autonomously plan and execute a tour of

Amsterdam. Our system for itinerary planning can be accessed by a tourist through a
mobile application and creates an itinerary tailored to their specific interests. We then
created a protocol for communicating a route to a Roboat in order to autonomously
navigate from one site in the itinerary to the next. We have developed a client that can
be run on the Roboat computer in order to receive waypoints to follow that comprise

39
the route, and can be used by the planner in Roboat to autonomously navigate the
route.
We will now demonstrate an example of this system from end to end. The user
displays for this example can be followed in Figure 4-1. First the user from Amsterdam
opens the app and chooses Amsterdam from their city options. Our tourist is then
routed to the preferences page where they enter their start time of 9:00 and end
time of 1:00 PM. They choose their favorite categories for sites as Landmarks and
Museums. When they hit submit, the request with these parameters is sent to the
server which determines the optimal route and returns this to the app. Once the
itinerary is returned, the app displays the itinerary to the tourist on the itinerary
page. On this page, the user can click on any of the steps to route the Roboat from
the origin to the destination of that route. When the tourist clicks on step 2, the
request will be sent to the server to route the Roboat from De Duif to Rembrandt
House, and the app will display a pop up that says, "Request Accepted." Finally,
wen they click on "View On Maps," the map opens up displaying the route. The user
can then return to the itinerary by pressing the back button, and this allows them to
move between these two pages.

40
Figure 4-1: User displays throughout the process of a tourist running our system from
end to end. The top left is the homepage where the tourist initiates the tour. The
top right image is the Preferences page with their information of their tour entered.
After the itinerary has been created, the tourist is taken to the itinerary page, shown
in the bottom left image. The map of the itinerary can be seen in the bottom right.

41
42
Chapter 5

Conclusion

This thesis presented our work in building a system for planning and routing a tourist
through Amsterdam with an autonomous Roboat. Our motivation stems from the
breakthroughs of the Roboat project and the opportunities that it provides to aug-
ment the experience of a tourist.
In chapters 1 and 2 we gave background on the project, discussed prior work in the
field, and considered the problem that we set out to solve with our system. We also
examined the different steps that needed to be taken and reviewed the intention for
each step. Both the routing aspect and interface with a user are integral in allowing
a tourist to take full advantage of Roboat when touring Amsterdam.
In the third chapter we detailed a novel contribution of the work, the system for
creating itineraries for tourists to travel throughout Amsterdam. We describe the
system structure and show how the front end application functions for a user as well
as outline what is done behind the scenes by the back end server. We also address one
of the key contributions, the map API to show the different routes along the canals
of Amsterdam in order to display our system.
In chapter 4, we discussed how the system routes a Roboat by sending interme-
diate waypoint coordinates that correspond to targets for the Roboat to reach. We
illustrated how these waypoints are selected and sent to the Roboat so that it can
determine a collision free route from one site to another for the tourist.
Therefore the work for this thesis system to create an itinerary for a tourist and

43
utilize the Roboat project to strengthen the experience of a tourist in Amsterdam.
We believe that this work will be realized by Roboat in Amsterdam once the project
has been completed.

5.1 Future Work

While this thesis address a problem for tourists and describes a solution in Amsterdam
with Roboat, there are still further steps that can be taken to expand the work. More
points of interest for the path planning optimization algorithm to consider would
create a more diverse experience for a tourist, and could be implemented following
the roadmap of this work. More options to customize the itinerary may also enhance
the process overall.
Due to time and travel constraints, the routing has not been tested on a Roboat
in the canals of Amsterdam. Once this is possible it is an important step that must
be completed before this project is applied to Roboat in practice. Once this is tested
it can be applied to other use cases of Roboat that require the routing capabilities of
navigating the canals.
As the Roboat project and the widespread use of ASVs in general continues to
grow, this work can also be extended to other cities that have canals, such as Venice.
The API for displaying paths along a waterway can be replicated for many other
applications of displaying water travel. This work can also be adapted to allow for
ride-sharing and taxiing users around Amsterdam or other cities with canals. In order
to allow for ride-sharing and widespread use a scheduling system must be examined
that determines a schedule for pickups and drop offs. We considered a naive scheduling
system that considers multiple users requesting a single Roboat with the capacity to
hold one rider at a time . This needs to be updated to account for more Roboats and
allow each to pick up multiple passengers to minimize the time spent waiting.
Finally, incorporating driving and walking routes into the optimized tour route
could show promise in shortening the overall time spent traveling for a tourist, however
it creates new problems such as needing to use other temporary transportation like a

44
taxi.

5.2 Takeaways
This project created many challenges that helped me develop both my technical and
professional skills. I learned a lot about the nuances of network systems such as how
to set up a server from the ground up and how the communication protocol works. On
top of this I learned a lot about the structure and lifecycle of the different activities
and pages created in the app. This was a long project that required many different
parts to complete, so I had to plan ahead well in order to finish and I practiced making
smaller goals each week that I strived to reach. Setting intermediate goals made the
process more organized and kept me on track throughout the semester while I worked
on this research and finished my classes.
Throughout the process, I had the privilege of working with many very smart and
resourceful researchers who I met with often to learn about the work that they were
completing. This helped me always see the bigger picture of my work, extending
past the research questions that I focused on. I kept up to date with the overall
progression and goals of the project which lead me seeing my problem in terms of the
entire Roboat project and not just the smaller questions I attempted to solve. On
top of learning from the other researchers on the Roboat team at MIT, I was able
to connect with researches in Amsterdam. This led to me developing my skills in
working remotely with others. Due to COVID-19, the whole team ended up going
remote and this further helped me improve skills in remote communication.

45
46
Appendix A

Software Packages

The following are the software packages and dependencies used for this work.

A.1 Server
asm - Java bytecode manipulation and analysis framework
gson - library used to serialize or deserialize Java Objects to JSON
jersey - REST framework for Java
gurobi - Optimizer
hsqldb - relational database engine and server with memory and disk tables
jettison - A StAX implementation for JSON.
opencsv - CSV parser library for Java

A.2 App
Apache HTTPCore - Core HTTP component APIs and primitives
Maps SDK - Google Maps API for android
JSON - JSON API for android
The code base can be found at:
https://www.dropbox.com/sh/z8etz6frwdnrlao/AAD3cXTNdH3Aif1OozIIr5XWa?dl=0

47
48
Appendix B

Points of Interest

POI Category
Anne Frank House Museums
The Jordaan Other
Centraal Station Cultural
De Duif Outdoors
De Poezenboot Landmarks
Brouwersgracht Outdoors
Rembrandt House Museums
ARTIS Amsterdam Royal Zoo Zoos/Aquariums
Westerkerk Landmarks
The Amstel Outdoors
St. Nicholas Basilica Landmarks
Begijnhof Outdoors
Rembrandtplein Cultural
Museum Van Loon Museums
Portuguese Synagogue of Amsterdam Cultural

Table B.1: The points of interest identified for Amsterdam with their classification

49
50
Bibliography

[1] I. Chao, B. Golden, and E. Wasil. Theory and methodology - the team orienteer-
ing problem. European Journal of Operational Research, vol. 88, page 464–474,
1996.
[2] C. Chekuri and M. Pal. A recursive greedy algorithm for walks in directed
graphs. Proceedings 46th Annual IEEE Symposium on Foundations of Computer
Science (FOCS), page 245–253, 2005.
[3] M. De Choudhury, M. Feldman, S. Amer-Yahia, N. Golbandi, R. Lempel, and
C. Yu. Automatic construction of travel itineraries using social breadcrumbs.
Proceedings of the 21st ACM conference on Hypertext and hypermedia, page
35–44, 2010.
[4] G. Erdogan and G. Laporte. The orienteering problem with variable profits.
Networks, vol. 61, no. 2, page 104–116, 2013.
[5] Amsterdam Institute for Advanced Metropolitan Solutions. https://www.ams-
institute.org/. Last Accessed: 21th Apr 2020.
[6] Roboat. http://roboat.org. Last Accessed: 21th Apr 2020.
[7] Eclipse Jersey. https://eclipse-ee4j.github.io/jersey/. Last Accessed: 25th
Apr 2020.
[8] Senseable City Lab. http://senseable.mit.edu. Last Accessed: 21th Apr 2020.
[9] Distributed Robotics Lab. https://www.csail.mit.edu/research/distributed-
robotics-laboratory. Last Accessed: 21th Apr 2020.
[10] Tripadvisor. https://www.tripadvisor.com/. Last Accessed: 25th Apr 2020.
[11] Ryan Kelly. Algorithms for planning and executing multi-roboat shapeshifting.
Master’s thesis, MIT, 2019.
[12] P. Vansteenwegen, W. Souffriau, and D. V. Oudheusden. The orienteering prob-
lem: A survey,” european journal of operational research. European Journal of
Operational Research, vol. 209, page 1–10, 2011.
[13] Brian Wheatman, Sertac Karaman, and Daniela Rus. Tourist path optimization
problem. 2017.

51
[14] H. Yoon, Y. Zheng, X. Xie, and W. Woo. Social itinerary recommendation from
user-generated digital trails. Personal and Ubiquitous Computing, vol. 16, no.
5, page 469–484, 2012.

[15] J. Yu, J. Aslam, S. Karaman, and D. Rus. Anytime planning of optimal sched-
ules for a mobile sensing robot. 2015 IEEE/RSJ International Conference on
Intelligent Robots and Systems (IROS), pages 5279–5286, 2015.

52