Hello, Any updates on the migration? If you need help I can, I would just like to be able to start on writing some fusion implementations with the files migrated properly.
Matteo On Wed, Jun 18, 2025 at 4:26 PM Matteo Golin <matteo.go...@gmail.com> wrote: > 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 >> > > >> > >> >
