Sensors are an important part of IoT. Phones, robots and drones all
have a slurry of sensors. Sensor chips are everywhere, doing all kinds
of jobs to help and entertain us. Modern games and game consoles can
thank sensors for some wonderfully active games.
Since I became involved with sensors and wrote QtSensorGestures as part of the QtSensors team at Nokia, sensors have only gotten cheaper and more prolific.
I used Ubuntu Server, snappy, a raspberry pi 3, and the senseHAT
sensor board to create a senseHAT sensors snap. Of course, this
currently only runs in devmode on raspberry pi3 (and pi2 as well) .
To future proof this, I wanted to get sensor data all the way up to QtSensors, for future QML access.
I now work at Canonical. Snappy is new and still in heavy development so I did run into a few
issues. First up was QFactoryLoader which
finds and loads plugins, was not looking in the correct spot. For some
reason, it uses $SNAP/usr/bin as it's QT_PLUGIN_PATH. I got around this
for now by using a wrapper script and setting QT_PLUGIN_PATH
to $SNAP/usr/lib/arm-linux-gnueabihf/qt5/plugins
Second issue was
that QSensorManager could not see it's configuration file in
/etc/xdg/QtProject which is not accessible to a snap. So I used the
wrapper script to set up XDG_CONFIG_DIRS as $SNAP/etc/xdg
[NOTE] I just discovered there is a part named "qt5conf" that can be used to setup Qt's env vars by using the included command qt5-launch to run your snap's commands.
Since there is no libhybris in Ubuntu Core, I had to decide what QtSensor backend to use. I could have used sensorfw, or maybe iio-sensor-proxy but RTIMULib
already worked for senseHAT. It was easier to write a QtSensors plugin
that used RTIMULib, as opposed to adding it into sensorfw. iio-sensor-proxy is more for laptop like machines and lacks many sensors.
RTIMULib
uses a configuration file that needs to be in a writable area, to hold
additional device specific calibration data. Luckily, one of it's
functions takes a directory path to look in. Since I was creating the
plugin, I made it use a new variable SENSEHAT_CONFIG_DIR so I could then set that up in
the wrapper script.
This also runs in confinement
without devmode, but involves a simple sensors snapd
interface.
One of the issues I can already see with this is that there
are a myriad ways of accessing the sensors. Different kernel interfaces -
iio, sysfs, evdev, different middleware - android
SensorManager/hybris, libhardware/hybris, sensorfw and others either I
cannot speak of or do not know about.
Once the snap goes through a review, it will live here https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/sensehat, but for now, there is working code is at my sensehat repo.
Next up to snapify, the Matrix Creator sensor array! Perhaps I can use my sensorfw snap or iio-sensor-proxy snap for that.