COLLECTING USER-CONTRIBUTED DATA RELATING TO A NAVIGABLE NETWORK

Abstract

Disclosed herein is a technique for obtaining information relating to a navigable network from devices (12) that are associated with users travelling within the navigable network. For example, a central server can issue requests to the devices (12) for automatically obtaining sensor data, with a request including a set of instructions for obtaining sensor data from one or more sensor(s) (13) accessible by the device (12). The request also includes a location-specific trigger. Thus, when it is determined that the device (12) has reached the location associated with the trigger, the device is able to automatically action the instructions in order to obtain the requested sensor data, which can then be reported back to the server.

Claims

1. A method for obtaining information relating to a navigable network from a device associated with a user travelling within the navigable network, the method comprising: receiving at the device a request for obtaining sensor data, wherein the request includes a set of one or more instructions for obtaining sensor data from one or more sensors accessible by the device, and a location-specific trigger, wherein the trigger is associated with a location within the navigable network; when it is determined that the device has reached the location associated with the trigger, automatically actioning the one or more instructions in order to obtain the requested sensor data; and processing the obtained sensor data at the device to determine or extract information relating to one or more attributes of the navigable network.

2. The method of claim 1, comprising providing data indicative of the obtained sensor data for output.

3. The method of claim 2, wherein the data indicative of the obtained sensor data is provided for output in the form of a sensor data report including data indicative of the obtained sensor data as well other information including one or more of: a time at which the sensor data was obtained; the location at which the sensor data was obtained; a device and/or sensor identifier; and a request identifier indicating the request that generated the sensor data report.

4. (canceled)

5. The method of claim 1, wherein the sensor data comprises image and/or video data captured by a camera associated with the device.

6. The method of claim 1, wherein the sensor data comprises acceleration data obtained from one or more accelerometers associated with the device.

7. The method of claim 1, wherein the device is capable of determining its own position relative to an electronic map representing the navigable network, and wherein the device is determined to have reached the location associated with the trigger when it is determined that the position of the device relative to the electronic map is within a predetermined threshold distance of the location.

8. The method of claim 1, wherein the trigger includes a direction indication such that sensor data is only obtained when it is determined that the device is approaching the location associated with the trigger from a selected direction.

9. A method for obtaining information relating to a navigable network from one or more devices each associated with a user travelling within the navigable network, the method comprising: issuing from a server to one or more devices travelling within the navigable network a request for obtaining sensor data, wherein the request includes a set of one or more instructions for obtaining sensor data from one or more sensors accessible by the one or more devices, and a location-specific trigger, wherein the trigger is associated with a location within the navigable network, wherein the trigger is arranged to cause the device to automatically action the one or more instructions to obtain the sensor data when it is determined that the device has reached the location associated with the trigger; and receiving at the server data that is indicative of the sensor data obtained from one or more of the one or more devices in response to the request for sensor data.

10. The method of claim 9, further comprising processing the data that is received at the server, wherein the processing includes a step of validating the obtained sensor data, wherein validating the obtained sensor data comprises combining and/or comparing sensor data that has been obtained from a plurality of different devices.

11. The method of claim 9, comprising updating an electronic map representing the navigable network using the received data.

12. The method of claim 9, wherein the trigger is issued in response to a request from the device for triggers within the vicinity of the device and/or of a predetermined route along which the device is being navigated.

13. The method of claim 9, wherein the trigger is issued in response to detecting that there is a potential error in an electronic map representing the navigable network, the location associated with the trigger being a location at which the potential error has been detected.

14. (canceled)

15. A device that is operable to obtain information relating to a navigable network within which the device is travelling, wherein the device has access to one or more associated sensors, and wherein the device comprises one or more processors arranged to: receive a request for obtaining sensor data, wherein the request includes a set of one or more instructions for obtaining sensor data from one or more sensors accessible by the device, and a location-specific trigger, wherein the trigger is associated with a location within the navigable network; determine when the device has reached the location associated with the trigger, and in response to such determination automatically actioning the one or more instructions in order to obtain the requested sensor data; and process the obtained sensor data at the device to determine or extract information relating to one or more attributes of the navigable network.

16. A server arranged for obtaining information relating to a navigable network from one or more devices each associated with a user travelling within the navigable network, the server comprising one or more processors arranged to: issue to one or more devices travelling within the navigable network a request for obtaining sensor data, wherein the request includes a set of one or more instructions for obtaining sensor data from one or more sensors associated with or accessible by the one or more devices, wherein the trigger is arranged to cause the device to automatically action the one or more instructions to obtain the sensor data when it is determined that the device has reached the location associated with the trigger; and receive data that is indicative of the sensor data obtained from one or more of the one or more devices in response to the request for sensor data.

17. A system, comprising: one or more devices that obtain information relating to a navigable network within which each of the one or more devices are travelling, each device having access to one or more sensors for that device, each device being associated with a respective user, and each device comprising one or more processors arranged to: receive a request for obtaining sensor data, wherein the request includes a set of one or more instructions for obtaining sensor data from the one or more sensors accessible to that device, and a location-specific trigger, wherein the trigger is associated with a specified location within the navigable network; determine when that device has reached the location associated with the trigger, and in response to such determination automatically actioning the one or more instructions in order to obtain the requested sensor data; and process the obtained sensor data at the device to determine or extract information relating to one or more attributes of the navigable network a server that obtains information relating to a navigable network from some or all of the one or more devices, the server comprising one or more processors arranged to: issue, to the some or all of the one or more devices, respective requests for obtaining sensor data; and receive, from the some or all of the one or more devices, data that is indicative of the sensor data obtained in response to the respective requests for sensor data.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0106] Various aspects of the teachings of the present invention, and arrangements embodying those teachings, will hereafter be described by way of illustrative example with reference to the accompanying drawings, in which:

[0107] FIG. 1 shows schematically a system within which embodiments of the technology presented herein may be implemented;

[0108] FIG. 2 shows the processing steps performed by a device when receiving a location trigger in accordance with an embodiment;

[0109] FIG. 3 is a high-level architecture diagram of a map information update system according to an embodiment;

[0110] FIG. 4 represents how location triggers may be incorporated onto an electronic map representation of a road network;

[0111] FIG. 5 shows how it may be detected from observations of probe data within a road network that a speed limit has changed;

[0112] FIG. 6 shows how a location trigger may be used to confirm whether a speed limit has changed according to an embodiment;

[0113] FIG. 7 shows an example of speed recordings as a function of time at a certain location within a road network; and

[0114] FIG. 8 shows the distribution of speed recordings for the location in the example at FIG. 7 at two different times.

DETAILED DESCRIPTION

[0115] Embodiments of the present invention relate to methods of collecting information about a navigable network (e.g. map information) from user devices currently travelling within the network. In other words, embodiments relate to techniques for ‘crowd sourcing’ such information. Preferably the navigable network is a road network and the information is collected from devices that are associated with vehicles travelling within the network. For example, information may be collected from user devices such as smartphones that are carried, or mounted, within a vehicle and/or from in-vehicle systems.

[0116] FIG. 1 illustrates an example of a system within which embodiments of the present invention may be performed. As shown, a vehicle 10 includes an interconnected set of devices 12 that are able to communicate with each other through an in-vehicle network 14. Some of the devices 12 are also connected to a long-haul wireless network 16 (such as a cellular phone network, GSM G1-G4, G5, Narrowband-IoT, LoRa, etc.) which provides access to one or more internet service(s), e.g. via a server 18.

[0117] FIG. 1 shows several devices 12 attached to the in-vehicle network. Each device 12 typically contains a processor, some memory and a network interface. At least some of the devices 12 are also equipped with one or more sensors 13, e.g. a microphone, a camera, an accelerometer, a positioning sensor, a proximity sensor, a radar, a laser range finder, an ambient light detector, and so on. Some of the devices 12 may be embedded into the vehicle, such that their sensor(s) 13 have a fixed orientation. However, some of the devices 12 may belong to a user, such as a user's smartphone, and may thus need to be mounted in place before they can be reliably used.

[0118] Any devices 12 connected to the in-vehicle network 14 may be configured to share their resources (e.g. sensors 13) with other devices 12 in the network 14. For example, a mobile device may be enabled to access video sensors embedded in devices embedded into the vehicle. Similarly, an application running in an embedded device may be enabled to access to the long-haul wireless network of a mobile device. The devices 12 may thus communicate within an Internet of things' type infrastructure that allows them to share resources.

[0119] At least one of the devices 12 may be running a navigation application. In a manner that is generally known, the navigation application may assist the user in navigating to a new destination, or it may merely provide relevant information for navigating to a commonly used destination (home, work, etc.). In both modes, the navigation application may use locally stored map information and receive map information from a map content provider using the long-haul wireless network 16.

[0120] The map content provider provides a wide range of map information. It will be appreciated that the map information related to road network is relatively static and map updates can be scheduled well in advance as roadworks may take months to years to complete. However, other map information such as traffic densities, accidents, road closures, updated road signs, points of interest, and so on, may be more dynamic. The map content provider can observe location data points from navigation applications to detect differences between historic navigation data and recent navigation data. Such differences may point to a change in map information. This and other types of reports are handled by a map update system.

Location Trigger Processing

[0121] Embodiments enable a map update system to rapidly obtain local information supporting a map update decision. It involves a navigation application within the in-vehicle network 14 to be able to support processing of a location trigger as shown in FIG. 2.

[0122] FIG. 2 shows the processing steps of a navigation application starting with receiving a location trigger (step 20) comprising a location point and an action request. A location point is the specification of a point on a map for example expressed using a longitude and latitude value pair. The location point usually is located on a road segment or on a new road segment. The location point also may contain a direction indication. The action request describes a data collection request for map making purposes at the associated location point. The action request may prescribe taking one or more images by an accessible camera or record a short video sequence. The action request also may prescribe recording accelerometer readouts over a time segment. Hence any sensor accessible to the navigation application may be included in the action request. After receiving the action request, the navigation application waits for the vehicle location data to indicate that is within a certain margin of the location point provided in the location trigger (step 21).

[0123] At the location trigger point, the navigation application collects the sensor data (step 22) either from a local sensor or from an accessible sensor of another device in the in-vehicle network as indicated in the action request. Optionally, the navigation application may process the collected sensor data (step 23). The processing may use code (a script, a set of byte codes, binary code) contained in the location trigger message or use predetermined sensor data processing functions supported by the navigation application.

[0124] An example of the sensor data processing is a search for features in an image or a data compression operation. The processing may reduce the size of the sensor data by detecting and removing redundant or irrelevant information. The processing step also may combine the collected sensor data with other sensor information such as time, date, location, device identification, sensor identification and so on into a sensor data report. The sensor data report preferably uses authentication and confidentiality techniques. The sensor data report is sent as a response to the received location trigger (step 24).

[0125] On the other hand, if the vehicle location data do not reach the location point within the predetermined margin the navigation application returns an error message after expiry of a time-out window.

Map Update System

[0126] The features embodied in the navigation application as described above may beneficially be used in a map information update system. FIG. 3 contains a high-level architecture diagram of a map information update system according to an embodiment.

[0127] FIG. 3 thus shows a map information update system with a map information controller 35 for generating location trigger messages. If the location point of a location trigger is within a certain range of a road segment, a reference or a location trigger identifier is added to the road segment associating the road segment with the location trigger. It will be appreciated that such an association may therefore resemble a Point of Interest (POI), or a road segment attribute, within the electronic map. The location triggers are then issued to a navigation application 31 associated with a vehicle travelling within the network via a scheduler 30. Optionally, the scheduler 30 may also collect positional data from the navigation application 31 and then determine based on the probe data which navigation application(s) 31 to issue the location trigger to. For example, the scheduler 30 may selectively issue location triggers only to navigation applications 31 that are in the vicinity of the associated location. Alternatively, the scheduler 30 may issue location triggers to all navigation applications 31 that are currently operating within the road network.

[0128] For instance, the navigation application 31 may receive the association information as part of the map data. This is illustrated in FIG. 4 which shows two location triggers 40 superimposed onto an electronic map representation of a road network. Alternatively, the navigation application 31 may request any such associations near a present location, near a planned route, or near a frequently travelled route. For example, the navigation application 31 may use the association information (a reference, an identifier) to request the transmission of the location trigger.

[0129] Each of the implementations described above results in the transmission of the location trigger via the long-haul communication network 16. The navigation application 31 receiving the location trigger may then collect the requested sensor data from an associated sensor 32 within the in-vehicle network 14 and then process the location trigger using suitable sensor data processing software 33 as described in the previous section to generate and return a sensor data report.

[0130] The map information controller 35 may then use the sensor data report to update the map information 36 appropriately. At this stage, the update process may generally be comparable to known map update mechanisms or map creation mechanisms.

[0131] As the sensor data report can be regarded as untrusted user data, the map information update system may adopt a message validation module 34 to verify the trust level of the sensor data report before using it in the map information controller. The validation operation may check the authentication and confidentiality techniques used in the sensor data report. It also may compare the sensor data with historical sensor data from other sources. Another validation technique would be to compare and combine sensor data reports generated by different navigation applications for the same location trigger into a more reliable sensor data report.

Use Case—Speed Change Updates

[0132] The crowd sourced map updates can be used to keep the speed limit information always up-to-date in a map product that tries to report speed limit changes in a live manner.

[0133] In this case, there are four systems that work together to update the electronic map: [0134] a change detector that monitors the relevant road network and detects changes from e.g. GPS data (runs on servers in the cloud). [0135] an app running on a mobile platform e.g. behind the windshield [0136] an AI-based object detection algorithm that is running on the mobile platform [0137] a map service

[0138] The whole road network is being monitored for changes of e.g. speeds. This can be done by measuring the speed (or other attributes) of cars when passing a road segment (illustrated in FIG. 7). Then the speed distribution of the road segment is computed over a certain duration in time (e.g. one week or one day (illustrated in FIG. 8). Then the similarity of the speed distribution is measured by e.g. using the Kullback-Leibler divergence

[00001]$D_{\mathrm{KL}}\left(P.Math.Q\right)={.Math.}_{x\in X}P\left(x\right)\log \left(\frac{P\left(x\right)}{Q\left(x\right)}\right)$

or any other suitable distribution similarity measure. If the similarity is below a certain threshold the segment attribute likely underwent a change and this segment is sent to the mobile platform for verification.

[0139] For instance, FIG. 5 shows an example where there is a change in speed distribution between two set intervals. The change in the distribution forms the basis for issuing a request to collect data at the road segment.

[0140] The mobile app may run on a smartphone with the smartphone being suitable mounted such that its camera points towards the road. However, it is also contemplated that the app may run on a dedicated navigation apparatus or a navigation system in-built into the vehicle, which is provided with access to a camera of the vehicle, or indeed the smartphone camera, as part of the in-vehicle network of devices. As shown in FIG. 6, the navigation application displays road attributes such as the speed limit to engage the user based on static map content as provided by a map server. Thus, the display shows the current location 41 of the user relative to the electronic map 42, but also provides a panel display (at the bottom of the screen in FIG. 6) showing the local speed limit.

[0141] In the example shown in FIG. 6, the speed limit is shown as being 120 km/h. However, the distribution of FIG. 5 indicates that the speed limit may have changed (to 80 km/h). In this case, the mobile app receives a request to confirm the potential attribute change on a road segment. In response to this request, the mobile application automatically turns on the camera to capture an image of the speed limit sign (as indicated in the panel 73 shown in FIG. 6). Preferably, the camera is used to obtain a sequence of images (i.e. a video stream) along the road. For instance, the precise location of the speed limit sign may not be known. The camera can then be used to obtain images for the whole segment of road, knowing that the speed limit sign will be captured in at least some of these images.

[0142] The mobile app then runs a suitable object detection algorithm to process the image 73 and extract the speed limit value. This value can then be sent to the map service for updating the map and the corrected speed limit value 60 can then be displayed to the user. It will be appreciated that processing the image data on the device helps save significant bandwidth. By contrast, in some previous approaches, the whole image sequence would have been passed to a cloud server for analysis. Thus, typically, this was only done at a later time, e.g. after the end of the trip when the user is back at home and connected to their home internet connection (to avoid using too much data bandwidth). The described embodiments thus also allow the data to be reported back, and used, more regularly and/or with a lower bandwidth cost.

Other use Case Examples

[0143] Although an example has been presented above regarding obtaining speed limit information, it will be appreciated that such location triggers may be used to obtain any desired information about a road network. For instance, some other example location triggers are listed below: [0144] Location trigger with a request to take a series of images at location intervals along a road segment and/or at time intervals (e.g. at a rate of one image per few seconds intervals of traffic in a road segment to estimate traffic density) [0145] Location trigger with a request to take images of a road junction in response to changes in junction delays [0146] Location trigger with a request to record accelerometer data and/or ambient noise conditions along a road segment to determine road surface conditions (e.g. for pot hole detection). [0147] Location trigger with a request to make a series of images at location intervals along a road segment

[0148] It will also be understood that the obtained information need not be provided to a map service provider, and may find utility in a range of other applications (not limited to updating electronic maps). For example, the information may be used for traffic management, town planning, or even provided to automotive manufacturers, or other users of the road network.

[0149] Thus, it will be appreciated that whilst various aspects and embodiments of the present invention have heretofore been described, the scope of the present invention is not limited to the particular arrangements set out herein and instead extends to encompass all arrangements, and modifications and alterations thereto, which fall within the scope of the appended claims.

[0150] Embodiments of the invention can be implemented as a computer program product for use with a computer system, the computer program product being, for example, a series of computer instructions stored on a tangible data recording medium, or embodied in a computer data signal,. The series of computer instructions can constitute all or part of the functionality described above, and can also be stored in any memory device, volatile or non-volatile, such as semiconductor, magnetic, optical or other memory device.

[0151] It will also be well understood by persons of ordinary skill in the art that whilst the preferred embodiment implements certain functionality by means of software, that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or indeed by a mix of hardware and software. As such, the scope of the present invention should not be interpreted as being limited only to being implemented in software.

[0152] Lastly, it should also be noted that whilst the accompanying claims set out particular combinations of features described herein, the scope of the present invention is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features or embodiments herein disclosed irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.