Proposed improvements to the sensor framwork

[raiden00pl]

I've spent some time playing with the new sensor framework, and I'm much less skeptical about this approach (previous discussion here https://github.com/apache/nuttx/pull/10077). It seems to me that with some changes, it can be a good universal solution. Unfortunately, the lack of documentation causes some misunderstanding. Most information about framework can be found in the discussion under https://github.com/apache/nuttx/pull/2039 and https://github.com/apache/nuttx/pull/2215. Somehow I missed this before :)

Some ideas for improvement from my side:

1. We should stop referring to this sensor framework as uorb. uorb is optional and is part of the apps. Referring to uorb on the kernel side gives the false impression that uorb is required.

2. Make sensor register path configurable. Now it is /dev/uorb (changed in c4bed9eae9037297b3f8de6a3547e8ca6361b933) but as uorb is application-specific property, this should be configurable.

3. Add options to disable some framework functionality. This can save memory on small systems. For example, disabling polling logic and relying only on the fetch interface saves some space and gives the user full control over sensor sampling. Another thing is timestamp; in many cases, timestamp doesn't matter for user.

4. The biggest problem I see now is forcing the user to use float. This is not the best solution for applications without FPU (e.g. CM0 which are often used in sensor nodes). What if we made the sensor data type configurable? It would be nice if we had an interface that return data in RAW format, but this may unnecessarily complicate the framework. Support for fixedmath type seems to be a good compromise (b16_t ?).

If there is consent to these changes, I can take care of them.

[xiaoxiang781216]

I've spent some time playing with the new sensor framework, and I'm much less skeptical about this approach (previous discussion here #10077). It seems to me that with some changes, it can be a good universal solution. Unfortunately, the lack of documentation causes some misunderstanding. Most information about framework can be found in the discussion under #2039 and #2215. Somehow I missed this before :)

@Donny9 has a representation about this new driver framework on NuttX workshop 2022: https://www.youtube.com/watch?v=ESpAE6wqy9o

Some ideas for improvement from my side:

1. We should stop referring to this sensor framework as uorb. uorb is optional and is part of the apps. Referring to uorb on the kernel side gives the false impression that uorb is required.

Yes, uorb is a simple and optional wrapper on top of sensor ioctl, but we need find a good name since sensor isn't a good name too:

1. The advanced algorithm(eg. step counter, heart rate) can be built with this framework.
2. Other notification can publish with this framework(eg. BT/WiFi connection state and signal strength)

2. Make sensor register path configurable. Now it is /dev/uorb (changed in c4bed9e) but as uorb is application-specific property, this should be configurable.
3. Add options to disable some framework functionality. This can save memory on small systems. For example, disabling polling logic and relying only on the fetch interface saves some space and gives the user full control over sensor sampling.

Each request is reasonable.

Another thing is timestamp; in many cases, timestamp doesn't matter for user.

It depends on the sensor type and application. If the timestamp isn't really used, driver could skip fill the timestamp value.

4. The biggest problem I see now is forcing the user to use float. This is not the best solution for applications without FPU (e.g. CM0 which are often used in sensor nodes). What if we made the sensor data type configurable? It would be nice if we had an interface that return data in RAW format, but this may unnecessarily complicate the framework.

Since hardwire normally report the measurement with the different unit, raw format makes us can't write the general application.

Support for fixedmath type seems to be a good compromise (b16_t ?).

Yes, fixedmath may a good option if the hardware doesn't have FPU.

[xiaoxiang781216]

@Donny9 could you review the proposal?

[minrui-hust]

”uorb“ is borrow from PX4，which is really a event-driven middle layer for inter-thread communication. And "uorb" is inspired by ROS (but with limited functionality and flexibility). If nuttx has it own middle layer say "nuttx-ROS" that would be great. ROS2 is claimed to support bare metal, but progress seems slow

[xiaoxiang781216]

the built in uorb is compatible with PX4, but the performance and size will be much better.

[raiden00pl]

The biggest problem I see now is forcing the user to use float. This is not the best solution for applications without FPU (e.g. CM0 which are often used in sensor nodes). What if we made the sensor data type configurable? It would be nice if we had an interface that return data in RAW format, but this may unnecessarily complicate the framework. Support for fixedmath type seems to be a good compromise (b16_t ?).

If we want to adopt the new framework on a larger scale, we have to solve this problem. @xiaoxiang781216 @Donny9 do you have any ideas for this?

Something like this is a solution, but it creates 2 alternative interfaces that are incompatible with each other:

Kconfig:

config SENSORS_USE_B16
   bool "Use fixed-math type as sensors data"
   default !ARCH_FPU

sensors.h:

#ifndef CONFIG_SENSORS_USE_B16
typedef float sensors_data_t;
#else
typedef b16_t sensors_data_t;
#endif

Math operations on sensors_data_t won't be compatible with each other, but we can create a portable interface with macros that operate on this type like sensor_data_add(x1, x2), sensor_data_div(x1,x2), sensor_data_mul(x1,x2) etc. If we want to use fractional numeric types, then I don't see any other option at the moment.

[xiaoxiang781216]

Yes, this is an acceptable approach to handle no-FPU case.

[cederom]

I sometimes use union with fixed point number (int) and floating point number (double), so the common variable type can be passed over functions in the whole project with a common api. The disadvantage is that caller and called need to know on what data type they operate in advance :-P

[raiden00pl]

I think support for fixed-math and float at the same time doesn't make much sense. If a user wants to use float, they most likely have FPU support or accepts all the disadvantages of using float type without FPU. Mixing data types in the same build will be difficult to implement, maintain and will probably provide no advantages for users.

[cederom]

True! I do that when both integer and floating point data are used in the same project. But here you are right @raiden00pl users will prefer either one or the other. I like this uORB standardization of interface concept because we can have common api for every sensor. Otherwise user will have to always calculate things on their own and probably also using floats in most cases :D

[raiden00pl]

here some PoC for fixed-math data type: https://github.com/apache/nuttx/pull/17408