Keywords

1 Introduction

According to World Health Organization about 15% of the world’s population has some form of disability and traveling through cities is one of the main concerns for people with mobility impairments [12]. Some help could come from an adaptive navigating system capable of considering their needs and taking into account the (mapped) accessibility of urban routes. Nevertheless, mapping accessible paths in a sustainable way is still an open challenge. The most cumbersome activity in providing an enriched map with accessibility information is gathering such information through field surveys, which is typically done manually by users or volunteers.

Maps for Easy Paths (MEP) is an ongoing project [8] aiming to overcome the limitations of current collaborative approaches in mapping accessible routes by easing the surveying effort through the collection of motion data from sensors commonly available in mobile devices. The accessibility of city routes, e.g., sidewalks, walkways, etc., is defined through the active contribution and participation of the target users, which include people with permanent or temporary motor disabilities and, possibly, also active citizens.

To ease target users and volunteers in data collection, we developed a mobile application called MEP Traces to automatically store mobile sensors data (e.g., positions estimated from GNSS satellites, motion sensors data, etc.) when users travel through the city: they just need to start the app at the beginning of their journey and stop it when they arrive. The underlying idea is that the route travelled by a person with disability, i.e., the target user of the MEP project, can be considered accessible also for other persons having the same (or a lower) type of disability. More in general, we assume that a path taken mostly by people with disabilities can be perceived as a friendlier route; this allows us to automatically identify accessible paths without the need of an ad-hoc field survey simply because the traveler who captures the data has been register to have some specific sort of disability.

After reporting related works in Sect. 2, in Sect. 3 we describe the MEP project and in particular MEP Traces and the overall process to extract the accessible paths. In Sect. 4 experimental results of a survey done in Cernobbio (Como, Italy) are reported, while in Sect. 5 conclusions are drawn and future works are described.

2 Related Works

Several collaborative projects proposed in the literature aim to improve city accessibility, through the Web or, more recently, through smartphones/tablets applications, as surveyed in [3]. Different types of barriers, but also of facilitators, have been identified and classified in several studies: such classifications are at the basis of our analysis for the collection of data about accessibility of city pedestrian pathways.

Considering the status of Web/Android/iOS applications available to the public, almost all of them focus on accessibility of points of interest (e.g., museums, restaurants, etc.). Only some of available apps include also information about condition of sidewalks and pedestrian crosswalks, or about the presence of cobblestones, curb ramps, and street lighting, such as RotaAccesivel [10], Comuni per tutti [4] and Mapability [7]. These proposals are very general and try to address all the disabilities. However, the collection of data is quite heavy, being mainly manual.

In the literature, solutions for the identification of accessible paths and sidewalk conditions have been considered only by few approaches, like, e.g., [2, 6, 9, 11]. Cardonha et al. [2] adopted an approach, in part, similar to MEP: the Breadcrumb application was developed to periodically capture a sequence of measurements based on the device geo-location (i.e., longitude and latitude) without any need for user intervention. To enhance the quality of the collected data, Breadcrumb applies a simple moving average of the last 10 estimates of the velocity of the device to identify slowdowns as obstacles. Compared to Breadcrumb, in our approach we try to extract as much as information as possible from the available sensors fusing the GNSS with the inertial data in order to reconstruct the exact path of the user, supposed to be accessible, besides trying to infer the presence of obstacles from motion data, as explained in Sect. 3.3.

Karimi et al. [6] propose a routing module which tracks the shuttles available in the main campus of the University of Pittsburgh and, given an accessibility map built manually, they provide turn-by-turn directions distinguishing among sidewalks along a street, along a building, and crosswalks along a building. Also [9] collects GPS data to determine the users’ trajectories and provides an algorithm to determine an accessible path between two locations for users with a certain disability: however, to the best of our knowledge, only a prototype has been produced. Finally, also [11] consider sidewalks, by providing a mobile application to capture pictures and upload data about some observable aspects of sidewalk conditions such as holes, presence of steps, etc.

3 MEP Traces and Path Reconstruction

In the MEP project we adopted a user-centered design approach involving target users from the early phases of the project being them the main actors of the data collection besides being the beneficiaries of the collected data.

3.1 Requirements of the Application

Users’ requirements were collected with focus groups involving both manual and electric wheelchair users, as well as elderly people with mobility issues. The main requirements that emerged from the focus groups include: easiness in using the app, interactive interfaces, easy to click and to understand icons and interactive buttons. With respect to this last point some of the wheelchair users of the focus group had finger movement limitations, for example when performing zoom in and out or in typing with digital keyboards: simple single click commands are therefore required.

Regarding the information to be collected along the pathways, and therefore to show on the map, they highlighted that they would prefer an app telling them the accessible paths to follow, and that they would not like to hear about obstacles. Among possible accessible elements they are interested in accessible toilets, transportation stops, and parking lots, as well as any building or point of interest of the city. In this project we have mainly focused on the paths and on the algorithms for their reconstruction.

In case of obstacles, it should be possible to signal them together with pictures that may give a better idea of the obstacle for the specific disability; simple and not-long-to-fill obstacles’ evaluation forms should be offered by the application. Finally, personalized maps according to typical disabilities (e.g., manual vs. electric wheelchair) should be provided: the collected data should therefore take into account also the users’ characteristics, so that, for example, a path travelled by a user requiring step-free accessibility can be considered accessible also for users able to climb low curbs.

The whole mapping process should take into account the different kinds of users: not only the interface should be suitable for users with motor impairments, but also processing algorithms should take into account mobility problems: in particular, when using sensor fusion techniques, they should be suitable for data collected on wheelchairs and cannot exploit step detection or similar techniques to improve the reconstruction of the path.

3.2 Data Collection and Processing Overview

Figure 1 describes the process for the collection of paths data and for their reconstruction: when a user starts a route, s/he activates an app called MEP-Traces to collect along the whole path data needed to its reconstruction. Such data include GNSS positions estimates (at present, GPS and GLONASS), motion sensors data (e.g., accelerometer, gyroscope, etc.) and, possibly, images; all the data are stored on the device SD-card and then uploaded on the server in a PostGIS database for further processing. On the server, since the accuracy in positioning of GNSS data is quite low for mobile device GNSS receivers, we fuse GNSS positions with motion data to provide a better estimate of the path, especially in those parts of the route where GNSS satellites are not visible; the output is an accessible path, which is then positioned in a geographical map.

Fig. 1.
figure 1

Overview of the (accessible) path computation process

Full size image

3.3 MEP-Traces Application

MEP-Traces is the Android application for the collection of data from common hardware sensors like GNSS, accelerometer, magnetometer, gyroscope, and barometer, embedded in the current generation of smartphones and tablets. Data are collected simultaneously, at the highest possible frequency, and locally stored in the mobile device SD-card.

Figure 2 shows some snapshots of our Android prototype: after registration, it provides a simple menu to start the recording of the route, manage user’s profile, send collected data, and exit the application. The main task of MEP-Traces is to track the user with motor impairments while s/he is travelling with the idea of mapping only accessible paths. Nevertheless, while the application runs and records all the sensors data, it is possible to signal obstacles (e.g., stairs, slopes, etc.) that can be then used for further analysis or refinements of the collected traces; moreover, it is possible to enrich maps also with accessible elements (e.g., parking lots for disabled people, accessible transport, etc.).

Fig. 2.
figure 2

Some snapshots of the MEP Traces app; from left to right (a) main menu, (b) sensor recording, (c) obstacle type selection, (d) obstacle description and notification.

Full size image

Some information, like available memory, and battery level can also be checked. This is used to warn the user when critical levels are reached, and to promptly save the acquisitions not to miss important data for processing. Obstacles can be notified with a simple click among predefined obstacle types: then, some characteristics, like the type (temporary or permanent) and the criticality level (low, medium, high), can be specified. Optionally, some pictures and a description can be included.

The application has been developed to dynamically recognize all the motion sensors in the device (e.g., step detector, orientation, proximity, rotation vector, etc.), but only accelerometer, gyroscope and magnetic field sensors are acquired by default. To retrieve the device position, the GPS sensor is used. The application automatically starts the sensor monitoring as soon as the GPS geo-location is obtained. For each acquisition phase, a specific folder is created, to store the files containing all the information of the sensors changes during the movement. Collected data need to be explicitly sent by the user to the server for further processing and sharing. Before sending them, we minimize the upload effort compressing each acquisition folder. The upload operation is forced with a connection between the device and our server over WiFi using the SFTP (SSH File Transfer Protocol), as in Fig. 3. During this task, the acquisition uploaded correctly to the server (after a client/server check) is automatically deleted from the mobile device while the upload proceeds.

Fig. 3.
figure 3

MEP-Traces upload interface example: from left to right (a) automatic selection of all the acquisitions, (b) data compression, (c) connection and uploading task

Full size image

3.4 Path Reconstruction

Data collected with the MEP-Traces application are used by the MEP-Fusion engine to reconstruct the path followed by MEP-Traces users. The approach used in the reconstruction is based on the fusion of information coming from multiple sensors to overcome issues related to the poor quality of the mobile sensors: indeed, the GPS and the internal Inertial Measurement Unit of the mobile device could single-handedly provide an absolute position and orientation for the device, but measurement noise produces inaccurate results.

Being the application targeted to users with disabilities, including those with motor impairments, methods often used to track pedestrian movements using mobile devices, which are based on step detection, are ineffective. For this reason, our solution is based on (and extends) the ROAMFREE sensor fusion library [5]. ROAMFREE, which stands for Robust Odometry Applying Multisensor Fusion to Reduce Estimation Errors, is a framework developed at the Artificial Intelligence and Robotics lab of Politecnico di Milano originally designed to fuse measurements coming from an arbitrary number of sensors, including images, in order to determinate the position and orientation of a mobile robot. Details of the approach can be found in [1]. Since the ROAMFREE library is able to reconstruct the trajectory using the absolute reference frame of the GNSS and the orientation provided by the Earth magnetic field recorded by the magnetometer, the device during the route can be held freely by the user. However, a swinging device, produces less accurate results.

4 Experimental Results

The experimental activity done in Cernobbio (Como, Italy) consisted in two days of acquisition, with MEP-Traces installed on different Android smartphones and tablets (used devices are listed in Table 1). The collected GPS data are graphically shown in Fig. 4. In the left-hand side picture, data are represented over a cartographic map using different colors, one for each device; only a portion of the city is included in the picture. In the right-hand side picture, the whole amount of collected GPS sensor data made in Cernobbio (Como, Italy) with all devices is shown.

Table 1. Average battery consumption for each device in using MEP-Traces during the experiments in Cernobbio (Como, Italy) with total acquisition time and the total length (in meters).
Full size table
Fig. 4.
figure 4

GPS data collected in Cernobbio (Como, Italy) with MEP Traces, two different views

Full size image

To evaluate the quality of the acquisitions of mobile devices, the collected GPS data have been compared with the data of a high-cost geodetic device – in our case a Leica GPS 1200 receiver. Figure 5 shows the acquisitions for the same path of the geodetic device (in black) and the low cost GNSS receiver of a Google Nexus 6P GPS sensor (in purple); you can notice how it is affected by a lot of noise. To provide a better estimation of the correct path, we have already fused our GPS data with the motion sensors data.

Fig. 5.
figure 5

Details of two different acquisitions with a geodetic device – Leica GPS 1200 receiver (black route) and a low cost GNSS receiver - Nexus 6P (purple route). (Color figure online)

Full size image

During the acquisition along the routes, some obstacles have been notified with the application. Figure 6 shows some details of obstacle visualizations.

Fig. 6.
figure 6

Barriers signaled in Cernobbio (Como, Italy) with MEP Traces

Full size image

The average battery consumption of MEP-Traces has also been computed for each device. The application is designed to run in background trying to use the minimal Android system resources, allowing the user to do any other task (e.g., calls, receiving sms and emails, using the internet, etc.). Table 1 shows the total acquisition time and the total length of the walked path (expressed in meters).

A total acquisition time of 16 h 38′ 02″ was done, reaching about 43 km as the total length of the walked path. The battery consumption of MEP-Traces has also been computed considering one hour of acquisition: the battery consumption of the application is about 5–6% in one hour. For some devices (omitted from our computation) we used power banks: in such cases the battery consumption was 0%.

All the acquisitions were taken with the application running in background. In order to consider a common user in a daily device usage, mobile data connection was enabled. Most of the used devices were personal devices, therefore the consumption may be affected also by other applications running on them. Several factors may affect the results of the battery consumption and for personal devices it is difficult to have homogeneous conditions. Indeed, results may depend also by the Android OS version installed on the device, the Linux Kernel version and its optimization, the hardware device composition like CPU and RAM, the read/write SD-card speed, etc. However, since the applications are thought to be used by any user with any Android device, these data can be considered as approximations of possible behaviors.

5 Conclusions and Future Work

In this paper we have described the results of data acquisitions done in Cernobbio (Como, Italy) for the MEP (Maps for Easy Path) project. The tools developed for the project have been illustrated and in particular the app MEP-Traces has been described in more detail: it retrieves raw GNSS data from low cost GPS sensor installed on commercial mobile devices, together with other sensor data like accelerometer, magnetometer etc. Then the entire path is reconstructed. Each reconstructed path is associated with the user’s profile (e.g., wheelchair type, requirements like “no-step”, etc.), to build accessible paths for different users’ types. Consistency and reliability of the collected data can be increased if more users trace the same routes. At this aim, we are improving the path reconstruction using clustering techniques on a set of paths.

Experiments have shown that the MEP-Traces application performance running in background on different devices is good, with a battery consumption of about 5–6% for an hour of acquisition. Future works of the project include the improvement of the visualization of the collected data, which is the focus of a second application called MEP APP; the extension of sensor fusion techniques to obstacle detection; and the refinement of the reconstructed data based on the cartography data (e.g., considering the presence of buildings) and on the analysis of the collected data.