-
Notifications
You must be signed in to change notification settings - Fork 34
Easing the Burden of Deploying New Sensors
A major area where SensorHub users and contributors will focus is in the development and deployment of new sensors and actuators. We therefore want to make that path as simple as possible. While the complexity of some sensors will require a developer to create a driver from scratch using procedures described in Sensor Module API and Adding New Modules, there are other options that are available or will be made available that should allow much easier deployment of new sensors and actuators. These are listed below from perhaps most challenging to easiest.
This is the most general method and perhaps the one favored by some hardcore developers. It involves developing classes that implement the interfaces ISensorModule, ISensorDataInterface, and ISensorControlInterface and extend the class SensorConfig.
Availability: This option is currently available.
This method utilizes Abstract implementations of the Sensor API Interfaces described above. These "Helper" classes can be used as a base to develop most sensor drivers. By providing default implementations of many of the methods required by the Interfaces, the Helper classes relieve some of the programming burden and provide some consistency across different sensor drivers.
Availability: This option is currently available utilizing AbstractSensorModule, AbstractSensorOutput, and AbstractSensorControl.
This method utilizes pre-built sensor modules that have been developed to support specific sensor types (e.g. video cameras, weather stations, UAS, GPS units, etc.). Using pre-built sensor modules will greatly ease the development effort required, and will provide consistency between sensors of that specific types (e.g. consistent data structures, tasking commands, and filter parameters). While much of the functionality will be provided by the pre-built module, this particular option still requires some development to support a specific sensor (e.g. communication protocols, reformatting of data, etc.).
Availability: Modules are currently being built to support certain sensor types. As these and others become available, they will be advertised in the list of available sensor modules.
This option requires no software development by the deployer. Instead, the sensor deployer only needs to select the appropriate pre-built sensor module, and provide more specific sensor information through the SensorHub Configuration user interface.
Availability: This method does require pre-built modules for specific sensors or sensor types. Such modules are currently being built to support certain sensors (e.g. video cameras using Video4Linux protocols). As these and others become available, they will be advertised in the list of available sensor modules.
This option requires no additional software development to introduce a new sensor or sensor type. Instead, the drivers for the sensor are automatically generated based on a SensorML description of that sensor types. The deployer of the sensor can then provide more specific sensor information through the SensorHub Configuration user interface.
Availability: This method requires the development of a special sensor module that is capable of auto-generating or auto-configuring sensor drivers based on a SensorML description. This module will require that the SensorML description provide output and tasking data structures and encodings, as well as a description of the interface (e.g. RS-232, USB, PUCK, etc) sufficient to allow machine-to-machine communication between SensorHub and the sensor system.
This method is very closely tied to the previous two above, particularly since the SensorHub Configuration user interface and sensor modules automatically generate SensorML descriptions. However, it is also possible for an Original Equipment Manufacturer (OEM) or sensor deployer to externally create a complete SensorML description of the sensor and have this auto-configure the sensor system in SensorHub.
Availability: This method is dependent on the SensorML-enabled module described in the previous option.
In this option, one merely clones an existing SensorHub deployment that supports the same sensor set as the new deployment. There will still need to be some minor Configuration input of the SensorHub (e.g. URL, location, etc.), but in essence, the process is exceedingly simple.
Availability: One should be able to create a GitHub repository for a complete SensorHub deployment and allow that to be cloned by public or private users using GitHub clone commands.