WO2005015829A1

WO2005015829A1 - Method and system for applying sensor information by replacement of a set of sensors.

Info

Publication number: WO2005015829A1
Application number: PCT/SE2004/001167
Authority: WO
Inventors: Stuart Mendelsohn
Original assignee: Stuart Mendelsohn
Priority date: 2003-08-10
Filing date: 2004-08-05
Publication date: 2005-02-17

Abstract

The method is for applying sensor information. A sensor unit (12) has a set (15). The sensor unit is in communication with a sensor application-programming interface (40) that is in communication with an application unit (42). A plurality of sensors (16a, 18a) is associated to the set (15) according to a universal mapping standard wherein the sensors (16a, 18a) are based on a first platform. The interface recognizes and classifies the sensors (16a, 18a). The sensors (16a, 18a) are replaced with sensors (16b, 18b) that are based on a second platform that is different from the first platform. The interface (40) recognizes and classifies the sensors (16b, 18b) without requiring a replacement of the application unit (42).

Description

METHOD AND SYSTEM FOR SENSOR DEVICES

Technical field The invention relates to a method and system for sensor devices. The invention and system relates to a method for the standard classification and management of sensors for sensors connected to any system.

Background of Invention In today' s robotics and complex systems there is an increased need for effective communication and interchangeability between various devices/sensors even if the devices are manufactured by different suppliers and based on different protocols/program platforms. Because a common standard/API does not exist for sensors the standard will allow for greater application interchange. A larger market for sensors and platforms will give reduced costs due to economies of scale. Currently available robotics and other such artificial intelligence devices do not allow for common communication and concepts to evolve. Each robot project is like a species that may become extinct after only one generation. Since if a platform cannot easily support the evolution of applications, no inheritance, the only evolution is in the slow progress made by the engineers who create each new generation of robots. Each robot project varies with the design of motion, sensor and programming and cannot evolve or communicate with other machines if they are incompatible, and without a standard for sensors, most are. Due to the wide variety of different and incompatible protocols and technologies available, the sensors often cannot communicate sensor information to the application devices unless some pre-customization has taken place. They often require complicated adjustments both in the software and the hardware that make communication impossible, cumbersome and expensive. Most systems that include sensors from different sensor manufacturers do not allow for easy interchangeability. Standard sensor API and preference/capability management There is a need for a standardized foundation to enable primitive communication and interchangeability between systems, devices and their sensors. To allow better cooperation between systems and to allow comparison of system capabilities there is also a need for classifying the capabilities and preferences/specialties of systems, devices and their sensors . Summary of Invention The method and system of the present invention provides a solution to the above-outlined problems. The system of the present invention has a common interface bus/specification that may be used to define, sensor use and specification between different devices. The interface permits the interchange and upgrade of replacement sensors without requiring any modification of the application devices. The sensor devices may be replaced by enhanced versions or different sensor versions that provide the same or additional sensor functions. More particularly, the method of the present invention may be used for applying sensor information. A sensor unit has a set of sensors associated therewith. The sensor unit is in communication with a sensor application-programming interface that is in communication with an application unit. A plurality of sensors is associated to the set according to a universal mapping standard wherein the sensors are based on a first platform. The interface recognizes and classifies the sensors. The sensors are replaced with a second set of sensors that are based on a second, platform that is different from the first platform. The interface recognizes and classifies the second set of sensors without requiring a replacement of the application unit. A sensor is any device that can produce data in response to some event it is monitoring. With a sensor API presented to applications; physical sensors and associated data can be consistently mapped and classified. Thus equivalent sensors from different_, manufacturers or different sensor arrays can be consistently processed by an application system because the API translates sensors and arrays to one common standardised layer presented to the application system or systems accessing any standard sensor API. Both sensors and associated data and applications that access sensor data via the API can be distributed and need not be in the same physical location. For example a team of mobile robots could communicate wirelessly and appear to as one virtual array of sensors, like a pack of dogs following a scent presented to them by their handler. Sensors can be of chemical, biological or electronic in nature, once defined the sensor capabilities must remain consistently mapped in the API. If a new sensor is developed it is either mapped as an extension to an existing sensor class, or if a suitable class does not exist it must be created. Once a common API exists for applications and sensors to access each other, a common way of describing sensor preferences can described as well as a common format for the storage of sensor preferences. This would allow applications to "choose" sensor (s) suitable for certain tasks or programs. Complex preference sets could form the basis for primitive personalities or traits of systems equipped with . sensors . Teams of robots could combine their sensors if necessary. If duplicate sensors exist in a group they could be used as replacements in the event of a failure or a sensor could be selected as having the highest specification of equivalent sensors present in the "team". For example, if a team of robots had an individual robot with a digital compass and another with a GPS navigation system, an application could choose the GPS system if location accuracy was required, but if only a heading > as required the compass could be used. A sensor can be accessed by any number of applications, they can be distributed not necessarily on the same platform. With a common API, an application can be upgraded more easily and different applications can access the same platform and use the same platform preferences/capability set. Thus a platform' s capability set could be copied or inherited, so that a sensor combination could matched to suitable applications and subsequent versions of those applications. Standardizing sensor capabilities and preferences under a common standard would allow applications to: • Filter capability associated with the sensor

• Identify sensor type, class sub class

• Sensor service life

• Read the sensor was accessed

• What type of applicatio (s) accessed the sensor • ID of applications accessing the sensor

• Tasks to be allocated to platforms depending on sensor capability. If sensor arrays can be visualized as rows the lens analogy can be used to define, by depth of field which sensors in the row are being accessed, /processed or selected at a a given time or selection range. The rows can be of the same sensor or various types. For example, different sensors accessed at the same time, or physical sensor location. Thus the sensors focussed on in a row would vary with the depth of field in the visualization, this could correspond to a value range for example. If sensor are reading any data the brightness of each sensor could be used to indicate the values being read, the highest value corresponding to the highest luminosity of the sensor being visualized in this way. A change in color could also be used to indicate sensor values. For example, in an array of sensors of the same type or sensor sensor luminosity could be proportional to the sensor signal amplitude. Pseudo sensors are can be any combination of:

• physical sensors (either connected virtually or in the same array or device) to be processed as if they were an actual sensor. These combinations could also allow for easier visualization and processing of larger sensor arrays/combinations. For example, humidity, light, temperature and soil pH values could be processed as one pseudo sensor to monitor plants. • A sensor or sensors combined with non sensor data/devices to be processed by applications in- the same way as other sensors. Thus contextual information (such as data from other applications, or even news or the time of day. For example, if an array includes cameras working in daylight, external data such as times of eclipses could be combined with sensor data, effecting sensor priorities and interpretation.

• A pseudo sensor could also be a software simulation of sensor data for test, experimental or other purpose. Values and combinations not occurring normally could be simulated in this manner. The equivalent of a machine hallucination could also be simulated in this way. When sensor are displayed in an application they can be visualized, for example, as having:

• differing brightness to indicate the relative amplitude of monitored signals.

• flashing to optionally indicate periodicity of readings

• different colors to indicate relative frequency of waveforms

• different shapes to indicate the class of sensor. For each sensor platform the standard allows for applications to discover available sensors, their capabilities and, how they have or might be used for each given platform. If the database holds historical data on the use of sensors, this could be used for preferences for each platform to be expressed in a standard way so that applications could know' the capabilities of sensors and how they have been used for each platform or group of sensor platforms/arrays. For example, a sensor may have registered certain readings at regular time intervals, so an application could use this data to anticipate events based on this data. If an event is anticipated, modulating sensor readings or the selective use of amplification could be used to ^Λheighten the awareness' of a platform, or create bias in selected sensor readings to emphasize the events being monitored. When dealing with complex or large sensor arrays, the standard sensor API will allow applications to prioritise and/or reduce the number of sensors read if processing is time critical or too much data is present for a given application to process effectively. Additionally applications can pass tasks to other applications more suited to process specific sensors and associated data.

Brief Description of the Drawing Fig. 1 is a schematic flow diagram of the method of the present invention; and Fig. 2 is a schematic flow diagram of two devices with sensor API units.

Detailed Description With reference to Fig. 1, the system 10 of the present invention has a sensor unit 12 in communication with a sensor API 40. As outlined in detail below, one important feature of the present invention is that there is a universal standard or mapping for all devices so that all sensor devices are compatible and interchangeable. Another important feature is that the universal mapping or standard also enables a unique way of managing preferences and that the system has a hardware/so tware independent platform for sensors. The method of the present invention provides a hardware and software independent way to map, classify and structure external events that are recorded, detected and associated via sensors. The sensors connected to the sensor unit 12 may be any type of device such as a camera, photocell, biochemical sensor or a receiver/microphone that operates at all wavelengths/frequencies. The sensors are not limited to the human sensor spectrum and they may detect energy and other such events that can or cannot be detected with human senses. The sensors may be physical sensors or pseudo-sensors that could be simulated in software or combinations of sensors and associated events or data such as news, time of day or date. For example, the sensor unit 12 may have a sensor set 15 including sensor units 16, 18, 20, 22, 24, 26, 28, 30. The set 15 may include sensor functionalities such as microphone, X-ray, receiver, camera, infrared camera, gamma ray, vapor, vibration, magnetic or any other sensor functionality, as desired. Any sensor 16-30 that is attached to the sensor unit 12 can be recognized and classified and it is known what the attached sensor can do regardless of the manufacturer due to the standardized software/hardware. It should be understood that it is not necessary for the sensors to be physically plugged into the. set 15. The sensors may also communicate with the set 15 via wireless communication or any other type of communication. The universal communication between the sensors and the set 15 enables the system 10 to prioritize how the sensors, such as the sensor 16, is used and associate the sensor 16 with other devices. The system also enables a group of sensors, such as the sensors 16, 18, 20, to act together as one sensor unit. The sensor unit 12 communicates with a sensor application-programming-interface (API) 40. By providing the interface above the physical sensors, the applications may operate across different platforms since the interface hides the underlying hardware and software differences of the sensors. As discussed below, the platform sensor preferences can be stored in a database that can be accessed by other compatible platforms and any application using the interface 40. These preferences allow for immediate processes associated with the interface layer independent of the applications that access the interface 40. The system 10 can autonomously build up a world-view or perception that is based on data stored in the database associated with a particular combination of sensors and the associated preferences and data associated with these sensor combinations. These preferences or views stored in the database can be shared, processed and modified by compatible systems and applications. As indicated above, the interface 40 may be used to classify the sensors that are plugged into the set 15. The interface 40 may be used to transfer data to program sensors irrespective of the sensor hardware used but all sensor hardware must comply with a classification that defines the function and capabilities of the sensors connected to the sensor unit that is in operative engagement with the interface 40. By separating the interface 40 from the sensor unit 12, the interface 40 does not need to directly deal with the sensor hardware that is plugged into the set 15. The intelligence of the interface 40 may effectively translate the sensor information. The interface 40 may then communicate with an application unit 42. The interface 40 may give different preferences to the sensors connected to the set 15 to save processing power of or to devolve the system 10. Because the interface 40 provides the required translation of the sensor information received by the sensor device 12, the application unit 42 does not need to be directly compatible with the hardware of the sensor itself. In this way, the unit 42 may cooperate with a wider range of sensors and the application unit 42 is hardware/software- independent of the sensor unit 12. . The interface 40 may cooperate with a sensor preferences filter database 44 that is associated with a computer 46 so that the filter database 44 may be used to filter, such as selecting or excluding, information from the interface 40 before the sensor information is displayed on a display 48 of the computer 46. The settings of each sensor 16-30 connected to the sensor unit 12 and the selection of the sensors 16-30 may be saved in the filter database 44. When the same application is carried out again, the settings and selection of the sensors may be retrieved from the database 44 so there is no need to reset or re-select the sensors each time an application is performed. Filters may be used for other wavelength spectra such as sound, radio and so oh. If the interface 40 also contains standardized filter information, devices could learn from other devices and transmit to them how the device filters information from their sensors and information related to the processing of the sensor input. As best shown in Fig. 2, the same units 12, 40, 42 may be used for two different devices 50, 52. In other words, the sensor mapping and functionality are the same for each device 50, 52 but the device 52 does not include sensors for the slots 20b, 30b. In the illustrated example, both devices 50, 52 run identical applications 54a, 54b, respectively although the sensor sets are different. This means the application 54b does not require the sensor 20b, 30b and only one common sensor or a plurality of common sensors 16, 18, 22, 24, 26, 28 are used. The devices may also run different applications 56, 58, as required. The device 50 may be equipped with a high-quality camera while the device 52 is equipped with an electronic smell sensor, a medium-quality camera and with a hearing device. The devices 50, 52 may cooperate thanks to the universal mapping and act as one device with three sensor features. The grouping could also include pseudo-sensors for simulated events. Also, if the high-quality camera of the device 50 malfunctions, the medium-quality camera of the device 52 may be used as a backup and provides a redundancy. When several sensors of a sensor type are plugged into the set 15, the system 10 may select or prioritize the sensor devices, such as the high-quality camera of the device 50 that may have the best or most suitable properties for a particular application. By using a suitable standard protocol such as XML or any other suitable protocol/program, all data may be parsed. A standard such as XML allows not only the mapping of sensors connected to the system 10 but also for the combination of sensors used to record external events or pseudo-events as explained above. Non-sensor information may be combined with sensor data to allow for a more complex construction of events or concepts. For example, data from an information system or the Internet could be related to events recorded via any combination of sensors. In this way, a system could autonomously evolve its own conceptual framework and experience independent of human input and in a way can be parsed and communicated via the standard mapping system of the present invention to other systems or human reading of events. News or calendar events could be used for activation. The XML standard also makes it possible to generate DTDs (document type definitions) , as rules that can be used to define a specific set of sensors and/or capabilities to define the structure and' content of events recorded via any sensor combination and associated data. For example, if a specific set of sensors are required for a task a DTD could be used to parse suitable sensor platforms even if the platforms are of different manufacture. Additionally, simulated or imaginary events may be described in this way, so that the requirements for events or sensors may be defined before they are detected or created. Combinations of sensors and sensor readings can be filtered in a standard way by storing data in, for example, a database. A standardized database could store preferences in a system independent way allowing preferences to be transferred or loaded on to one or more systems or replicated. For example, this could be to select sensors facing a specific direction or only certain frequencies or spectra. If the visualization of the sensors used a photographic metaphor such as the filter placed in front of a camera lens an easy to use system could be created to manage the loading and management of filter data for sensors arrays. Extending the photographic theme would allow the visualization of sensor arrays to be seen through a camera lens, changing focal length would allow narrowing the number of sensors ^Λin view', for example. Visualizing sensors in rows would allow for depth of field to be used to select adjacent sensors in a row, for example. While the present invention has been described in accordance with preferred compositions and embodiments, it is to be understood that certain substitutions and alterations may be made thereto without departing from the spirit and scope of the following claims .

Claims

Claims : 1. A method of applying sensor information: providing a sensor unit (12) having a set (15), the sensor unit being in communication with a sensor application-programming interface (40), the interface being in communication with an application unit (42) ; associating a plurality of sensors (16a, 18a) to the set (15) according to a universal mapping standard, the sensors (16a, 18a) being based on a first platform; the interface recognizing and classifying the sensors (16a, 18a); replacing the sensors (16a, 18a) with sensors (16b, 18b), the sensors (16b, 18b) being based on a second platform that is different from the first platform, the sensors (16b, 18b) being associated with the set (15) according to the universal mapping standard; and the interface (40) recognizing and classifying the sensors (16b, 18b) without requiring a replacement of the application unit (42).

2. The method according to claim 1 wherein the method further comprises the interface (40) selecting the sensors to be used for a first application and the interface setting the selected sensors for the first application.

3. The method according to claim 1 wherein the method further comprises the interface (40) saving the selection and settings of the sensors for the first application in a filter database (44).

4. The method according to claim 1 wherein the method further comprises performing a second application that is identical for the first application, the interface (40) retrieving the selection and settings of sensors from the filter database (44).

5. The method according to claim 4 wherein the method further comprises connecting the filter database (44) to a computer system (48) for displaying information from the selected sensors.

6. The method according to claim 1 wherein the method further comprises the interface (40) converting information from the sensor unit (12) to requirements of the application unit (42) and the requirements of the application unit (42) being independent of the sensors connected to the sensor unit (12) .