Hello Xiang, Thank you for the links! What do you think about making a `uorb_fusion` group in the NuttX apps? Where any UORB fusion node implementations can be kept? That way they're separated from that inertial application you linked which is not UORB. Also, do you have any suggestions for how one might start multiple user code applications after boot? I think it makes sense to separate out the different nodes by topic (altitude, position, etc.), but in my applications I would like to have them all available right after boot before my main application runs. Is there a way to do this without registering fusion nodes in board startup code with something like `orb_advertise`?
Matteo On Wed, Jan 29, 2025 at 12:17 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > On Wed, Jan 29, 2025 at 6:34 AM Matteo Golin <matteo.go...@gmail.com> > wrote: > > > Hello again everyone, > > > > I was going through some of the NuttX documentation for UORB again since > > InSpace is using it in our applications and > > also to mock our sensors to see our system response in different > scenarios > > (we are planning to use a modified fakesensor > > example). > > > > I noticed an intriguing application mentioned in the documentation that > it > > would be possible to create a UORB node that > > subscribes to other sensor nodes and performs fusion/creates a new > output. > > The docs mention PX4's use of this and links > > to this graph: https://docs.px4.io/main/en/middleware/uorb_graph.html > > > > > Yes, you can subscribe sensor and read data from userspace by: > orb_subscribe: > > https://github.com/apache/nuttx-apps/blob/master/system/uorb/uORB/uORB.h#L447 > orb_copy: > > https://github.com/apache/nuttx-apps/blob/master/system/uorb/uORB/uORB.h#L495 > Note: you need poll fd before orb_copy, or use orb_loop_init to assist you > manage multiple data sources. > > and publish the fusion data by: > orb_advertise: > > https://github.com/apache/nuttx-apps/blob/master/system/uorb/uORB/uORB.h#L284 > orb_publish: > > https://github.com/apache/nuttx-apps/blob/master/system/uorb/uORB/uORB.h#L374 > > For our application, we would be doing things such as calculating altitude > > from barometer data, or roll/pitch/yaw > > measurements from IMU + magnetometer data. I am thinking that such a node > > might become useful for other NuttX users, but > > I'm not sure where in the source tree it would live (or if it belongs > > there). It's not a sensor so I don't think it > > would go in `drivers/sensors`, > > > Yes, only the physical sensor should be put into drivers/sensors, all algo > should be put to userspace. This capability come from usensor: > https://github.com/apache/nuttx/blob/master/drivers/sensors/usensor.c. > > but I'm not too sure. My reasoning is that since a "barometer topic" under > > UORB has a > > standard interface, it would be possible to register a altitude fusion > > node which pulls from any barometer node, > > irregardless of the barometer type. > > > Please check whether > https://github.com/apache/nuttx-apps/tree/master/system/uorb/sensor has > defined the topic you need. > If not, it's easy to add the new topic by following the same style. > > > > If the user needs to add more configuration to the barometer, they could > > use > > `orb_ioctl` commands to modify the sensor settings from their application > > and these changes would bubble up to any > > fusion nodes. > > > > What are your thoughts on this? Would something like this be beneficial > > for NuttX? > > > > > Yes, it's a good idea to share the algo to the community, but we need to > find a common place for them. > Here is the current layout: > kernel driver: https://github.com/apache/nuttx/tree/master/drivers/sensors > userspace framework and tools: > https://github.com/apache/nuttx-apps/tree/master/system/uorb > fusion algo(not use uorb): > https://github.com/apache/nuttx-apps/tree/master/inertial/madgwick > we may need to consolidate the source code in userspace into one place. > > -- > > Matteo Golin > > >
