You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by "raiden00pl (via GitHub)" <gi...@apache.org> on 2023/09/16 09:09:41 UTC
[GitHub] [nuttx] raiden00pl opened a new issue, #10644: Proposed improvements to the sensor framwork
raiden00pl opened a new issue, #10644:
URL: https://github.com/apache/nuttx/issues/10644
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-3961448309
Some other issues:
1. Think about support for current/power monitors like INA2xx
2. Should we use sensor framework for encoders (both TIMER-based and external IC-based) ?
3. Should we use sensor framework for zerocross ?
4. Should we use sensor framework for hall sensors ?
5. Think about other non-standard sensors. We should decide what we consider a sensor and what not.
Ideally, everything should be handled by one framework.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-2592061754
> 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-2593312419
Yes, this is an acceptable approach to handle no-FPU case.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 commented on issue #10644: Proposed improvements to the sensor framwork
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-1722230472
> 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](https://github.com/apache/nuttx/commit/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.
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-1754454922
the built in uorb is compatible with PX4, but the performance and size will be much better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 commented on issue #10644: Proposed improvements to the sensor framwork
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-1722667188
@Donny9 could you review the suggestion?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "cederom (via GitHub)" <gi...@apache.org>.
cederom commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-3576721580
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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "minrui-hust (via GitHub)" <gi...@apache.org>.
minrui-hust commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-1754359019
”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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "cederom (via GitHub)" <gi...@apache.org>.
cederom commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-3576662438
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. The disadvantage is that caller and called need to know on what data type they operate in advance :-P
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-3576703753
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Proposed improvements to the sensor framwork [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #10644:
URL: https://github.com/apache/nuttx/issues/10644#issuecomment-3591935724
here some PoC for fixed-math data type: https://github.com/apache/nuttx/pull/17408
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org