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.