-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed improvements to the sensor framwork #10644
Comments
@Donny9 has a representation about this new driver framework on NuttX workshop 2022:
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:
Each request is reasonable.
It depends on the sensor type and application. If the timestamp isn't really used, driver could skip fill the timestamp value.
Since hardwire normally report the measurement with the different unit, raw format makes us can't write the general application.
Yes, fixedmath may a good option if the hardware doesn't have FPU. |
@Donny9 could you review the proposal? |
”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. |
the built in uorb is compatible with PX4, but the performance and size will be much better. |
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 :)
Some ideas for improvement from my side:
We should stop referring to this sensor framework as
uorb
.uorb
is optional and is part of the apps. Referring touorb
on the kernel side gives the false impression that uorb is required.Make sensor register path configurable. Now it is
/dev/uorb
(changed in c4bed9e) but asuorb
is application-specific property, this should be configurable.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 istimestamp
; in many cases, timestamp doesn't matter for user.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.
The text was updated successfully, but these errors were encountered: