On Wed, Jan 29, 2025 at 10:52 PM Matteo Golin <matteo.go...@gmail.com> wrote:
> 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. > since sensor is very important IoT application, maybe, we can name it apps/sensors and move all related stuff into it: https://github.com/apache/nuttx-apps/tree/master/inertial/madgwick https://github.com/apache/nuttx-apps/tree/master/system/uorb https://github.com/apache/nuttx-apps/tree/master/system/sensortest https://github.com/apache/nuttx-apps/tree/master/system/sensorscope and your new fusion algo. > 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`? > we normally launch the userspace daemon with rc like Unix, you can reference how this done on sim: https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc/init.d > > 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 > > > > > >
