Good idea! It is better to have all sensors tested in a single place, there are many individual sensors applications inside apps/examples/, they also need to be moved to apps/sensors/
BR, Alan On Wed, Jan 29, 2025 at 12:40 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > 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 > > > > > > > > > >
