Adding sensor-based question types

In ODK Collect, we currently have the Bearing question type, which allows users to collect data from the device's compass sensor. However, there are many other sensors available on Android devices that could benefit from dedicated question types, such as:

  • Ambient Light Sensor
  • Temperature Sensor
  • Humidity Sensor
  • Pressure Sensor
  • and more

Implementing these would offer several benefits:

  1. No need for external apps - Users would no longer need to rely on third-party applications that may not be compatible with ODK.
  2. No manual data entry - Automatic data collection would eliminate the need for manual input, reducing the risk of transcription errors.
  3. Streamlined workflow - With data being automatically collected, the overall data collection process becomes faster and more efficient

Adding these question types is something I’ve been considering for a while, but reading this forum post really motivated me to bring it up.

I’m curious if this feature would be useful to you, and why.

8 Likes

I could benefit from having data from all of those sensor types. I already use a lot of separate temperature and humidity type sensors.

My assumption is that similar to the bearing question these would all require the user to tap a button to record a reading. Would it be possible to have these values be collected in the background automatically without having the user need to tap a button? I know this is possible with GPS and users can modify the parameters column accordingly. I would propose something similar if possible.

And/or, another option would be something like this where the data is taken in the background at the beginning of the survey.

This might diverge from what is being proposed here as an appearance modification to the decimal question, but these are two different ways that this kind of data would be valuable to me. That is not to say that this wouldn't be valuable to have users tap the button, I'm just always looking for ways to speed up data collection while maintaining data quality.

3 Likes

I'd be interested in sensor based question types for sure. Most of my use cases would be some kind of external sensor, but with more and more sensors being integrated into devices there could certainly be ones of use.

This would make it more useful. eg when a photo is captured, the bearing is automatically recorded.

2 Likes

Having a way to collect data directly from sensors would be very useful, and it would benefit me as well. Right now, we use external devices to collect the data.

I’m curious about something: for measurements like temperature and humidity, you might need a device (like a tablet) to stay in one place (like a room) for a while to record accurate values. If that’s the case, it might be helpful to let the user know that they need to wait for some time (15 minutes) while the values are being recorded. If it’s not necessary to wait, then there’s no need to indicate that.

1 Like

We measure compass bearings (emerging turtle hatchlings heading towards the sea, or if disoriented towards any artificial light source).

The built-in compass in our Samsung Galaxy S2 tablets was off by a range of about 20 degrees. We used handheld compasses and entered degrees by hand. So here the available sensors were not accurate enough.

Two use cases not for a sensor from an external device:

Another project uses a laser rangefinder which captures azimuth, bearing, and distance in one measurement. Here we'd love to connect this as an external app. I couldn't get my hands on a device long enough to work on the API.

Lastly, turtles (and donkeys) worldwide would enjoy having a one click PIT tag scan enabled as widget. I've spoken to Callum and this is something that sounds like it could be commissioned.
The challenge here is the range of different PIT tag scanners used.
We use one robust but affordable model and I could not figure out (with manual and driver installed) how to trigger a scan.
Simply switching from the one model we use to another device that works with ODK is expensive (100 devices at 250 AUD each, ouch).

2 Likes

I didn't mention this, but when I tested the compass function a couple of years back I also found the values were unusable on Galaxy Tab S6 devices so I shelved it and haven't tried again since.

We've posted about this before! This is one I would quite like too, using Bosch/Leica LDMs to return a distance/angle/calculated pythagorean height...

1 Like