Thank you for the explanation! That sounds like a good plan. Please ping me (@linguini1) on the PR when you open it for visibility. In the meantime, I'll brainstorm what the best method of creating a fusion library might be. I want the user to choose themselves whether a thread is spawned to asynchronously perform fusion or if they want to do it synchronously, so I'll have to come up with some kind of standard way to generate fused data with function calls.
Thanks again, Matteo On Wed, Jun 18, 2025 at 12:04 AM 董九柱 <dongjiuzhu0...@gmail.com> wrote: > Hi Matteo Golin： > > I see under `uorb/sensors` there are > > lots of header and C files that just contain declarations for uORB types, > > but these declarations already exist in the kernel. Why are they > duplicated > > in nuttx-apps? > > > 1.We define all the uORB-related metadata for physical sensors under the > directory nuttx-apps/system/uorb/sensor(by using ORB macro > function:ORB_DEFINE、ORB_DECLARE). This metadata primarily describes the > name of each topic, the size of its associated structure, and debug > callback functions. > And the structure definitions for these topics are placed in > nuttx/include/nuttx/uorb.h, allowing kernel drivers to utilize them > directly. > > 2. When we want to use a specific topic, such as the accelerometer topic, > we simply need to include <sensor/accel.h> in our application and then use > APIs like orb_subscribe to subscribe to it. However, this assumes that the > accelerometer driver is functioning correctly. > > The main reason for separating them is that uORB is a user-layer SDK and is > not utilized by the kernel. However, the structure definitions are required > by both the kernel and user-space applications. Hence, they are placed > within the kernel. > > Can anyone shine some light on why the `uorb/sensor` declarations are > > necessary, and if it would be possible for me to create user space fusion > > drivers in `uorb/fusion` with their own Kconfig file? > > > Previously, xiangxiao suggested moving all sensor-related components to > the *apps/sensor* directory. So, We could create a separate > *apps/sensor/fusion/* directory under it, and within the fusion directory, > we could establish our own Kconfig file. This fusion directory would be at > the same level as the apps/sensor/uorb directory. > I will submit a PR to move them, and we can have discussions under that PR. > > > Matteo Golin <matteo.go...@gmail.com> 于2025年6月18日周三 02:34写道： > > > Hello, > > > > Was starting to work more on this today, but I'm confused about how the > > `uorb` directory is currently set up. I see under `uorb/sensors` there > are > > lots of header and C files that just contain declarations for uORB types, > > but these declarations already exist in the kernel. Why are they > duplicated > > in nuttx-apps? > > > > I was hoping to create a "fusion library", with userspace implementations > > of uORB drivers using `usensor`. Something where the user can include > this > > library and choose which fusion nodes they want to register in their > > application, *not* an example program that just runs and registers a > > sensor. This way the user has full control. I was thinking about putting > > this under `uorb/fusion`, but I want to include a Kconfig file so users > can > > enable/disable fusion drivers that they want to include using > `menuconfig`. > > I don't think I can put another Kconfig file in `uorb/fusion` since > there's > > already a Kconfig file in `uorb`, but I could be wrong. To me, this > > location seems like the intuitive place to put fusion libraries, but I > > don't want it conflated with the `uorb_listener` application since it's a > > user-available library. > > > > Can anyone shine some light on why the `uorb/sensor` declarations are > > necessary, and if it would be possible for me to create user space fusion > > drivers in `uorb/fusion` with their own Kconfig file? > > > > Matteo > > > > On Fri, Jan 31, 2025 at 5:52 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > > On Fri, Jan 31, 2025 at 10:56 PM Matteo Golin <matteo.go...@gmail.com> > > > wrote: > > > > Given the discourse around breakages in synchronization between the > > > > nuttx-apps and nuttx repositories, I think I may begin adding new > > > > applications to `apps/sensors` but I will hold off on moving any > > already > > > > existing sensor examples. In the coming days I expect to have > something > > > > functional for determining altitude from barometer data. > > > > > > Looks like someone missed something, or we didn't catch the problem on > > > time with PR/CI, its clearly a bug not by design, but it seems easier > > > to write emails than send actual patches :-) > > > > > > Keep your repos in sync, fear not, share your stuff, report problems > > > when found any, have fun, if you plan to break existing stuff just > > > create a separate application so everyone is safe :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > >
