RFC: Architecting a sensor subsystem

[yperess]

Introduction

Sensor improvements are underway for kernel level drivers. But they assume a single consumer. A sensor subsystem has been proposed in #36963 and has been under development under subsys/sensing. The goals of the subsystem is to provide higher level functionality:

• Demuxing data into multiple consumers
• Arbitration of consumer configuration requests

Problem description

The current path of the implementation does not appear to be in the best interest of Zephyr as a whole. The implementation:

• Duplicates APIs
• Creates a "driver" node per type (this leads to synchronization issues when both type poke the same physical device)
• Highly dependent on the scheduler

Proposed change

I'm proposing we stick to the engineering principle of Single Responsibility Principal (as much as possible).

The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor."[1] The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module.

Taken from SRP

What this boils down to is that we should finish the work that's ongoing for updating the sensor driver API structs. These structs will be used both in the kernel level drivers AND in the subsystem's virtual sensors. It will be a single API for "sensors". Regardless of how the sensor gets the data.

Next, the subsystem should be responsible for the fanout. This means sending data to consumers and arbitrating configurations. Most likely, sending the data will leverage the zbus subsystem.

Links:

• Pending kernel level changes: sensors: Implement a vertical decoder API #61022 and sensors: Add streaming APIs #60063
• WIP subsystem https://github.com/yperess/zephyr/tree/peress/sensors
  • Shell support subsys/sensing/src/shell.c
  • Tests tests/subsys/sensing/
  • Video demos (1) and (2)
• Presentation: Google sensor subsystem pitch
• Presentation: Sensing Subsystem design considerations and response to raised concerns

Related issues/PRs

• lack of a performant sensor API #1387
• Updated Sensor API #13718
• Fixing design concerns with Sensor Subsystem (sensing) #58925
• sensors: Update to the Sensors V2 decoder API #60944

[rodrigopex]

@yperess have you guys consider using ZBus to share the data and control sensor subsystem? I can help with that.

[yperess]

@yperess have you guys consider using ZBus to share the data and control sensor subsystem? I can help with that.

Yes, most likely the internal implementation will end up using zbus. Also, yes please, I'll be happy to get any help you can offer on that

[rodrigopex]

Yes, most likely the internal implementation will end up using zbus. Also, yes please, I'll be happy to get any help you can offer on that

@yperess How would you like to proceed?

[fabiobaltieri]

Architecture WG notes:

• @yperess: <overview of the current requirements from Google and shortcomings of the currently proposed approach, Google sensor subsystem pitch>
  • key points: the sensing api duplicates the sensor api functionalities, as well as the subsystem APIs, issues with coordinating multiple sensors
  • presents a proposed plan of next steps
• @KeHIntel: <overview of the sensning proposal Sensing Subsystem design considerations and response to raised concerns>
  • Addressing points from the first presentation (slides 5 to 14)
• @henrikbrixandersen asks for clarificataion about developer experience clarification
• @KeHIntel: the virtual sensor concept is meant to help data scientist work with this, abstracting from the specific device interface, datasheet details
• @yperess the existing API already does that
• @henrikbrixandersen <comments on the devicetre slide, page 8> the current devicetree design is not limiting dynamic configuration options
• @bjarki-trackunit the new API builds on top of the current API (set attribute fetch attribute) does not seem to be usable for implementing fifo, is the idea to extend that
• @yperess yes, there's work in progress to support senso fifos, asyncronous read and data timestamped on the interrupt and separated decoder APIs, sensor subsystem would build on top of it
• @MaureenHelm question about the vertical decoder proposal: why is it a dependency
  • @yperess <shows sensors: Update to the Sensors V2 decoder API #60944>, explains the point about processing grouped by channel related to non uniform data between frames
• @MaureenHelm question about the propose changes to the sensor driver apis, trying to understand how the api would look like after the change
  • @KeHIntel: <back to slide 7> the API restructuring would remove the duplication against sensor
• Wojciech Macek (Google): asks both presenters how to handle sensor data rate change and resampling, seems like the current API is just decimating the data, which is making the data useless for some type of sensors
  • @KeHIntel: sensing provides the data at the requested frequency
  • @yperess the driver would get notified when the rate changes and provide a library for decimation of resampling, but the data reprocessing responsability is on the application
• @teburd does not see the subsystem implementing detailed data processing primitives (resampling, filtering...)
• @henrikbrixandersen / @MaureenHelm / @bjarki-trackunit: few more comments about difficulties in implementing arbitration with arbitrary parameters in an effective way

---

• Followup:
  • [both authors] create an RFC with more details about how the sensor API should be extended
  • @yperess post the proposal for unified device structure as a PR

[OgnjenX]

I'm trying to better understand if this proposal has been implemented since all PRs that I found to be related seem to be merged. If so, could you let me know since which release version it is included?
Thanks in advance.