hello Matteo Golin: I'm Donny. About these questions, i have some suggestions.
Regarding the first question, we first need to clarify what data the sensor reports. Can only temperature and time suffice? If they can, try to reuse the sensor_temp structure instead of introducing a new type. If they cannot suffice, there are two solutions. 1>. The first is to populate the sensor_temp structure, but only add members related to temperature. If the additional data is highly unrelated, you have to choose the other approach: 2>. Using custom_sensor. With this, you can fully define your own structure and size. Register it through sensor_custom_register and specify a name, which is usually the name of the structure and also the topic name for subscription through the ORB API. Questions 3 and 4: For multiple thermocouples, uORB supports multiple instances of topics. You need to specify the driver type and device number when registering the driver, which will register them as different nodes. When subscribing using uORB, you can specify which sensor entity to subscribe to using something like uorb_subscribe_multi. These entities can all have data structures that are either sensor_temp or a custom structure you have defined. For example: /dev/uorb/temp0, /dev/uorb/temp1, etc. You can subscribe to specific instances using: c复制代码 uorb_subscribe_multi(ORB_ID(SENSOR_TEMPERATURE), 0); uorb_subscribe_multi(ORB_ID(SENSOR_TEMPERATURE), 1); Actually, when registering the driver, you should know which device uses which devno, so you can differentiate based on devno. However, if you are unsure, you can retrieve the info of each sensor to make a judgment. But regardless, you still need to populate different info for different sensors when registering the driver. Donny. Matteo Golin <matteo.go...@gmail.com> 于2025年1月17日周五 11:16写道： > Hello everyone, > > I am working on writing drivers for some of InSpace's new sensors for our > hybrid control system. Of these sensors, one > of them is the MCP9600 thermocouple amplifier for reading temperatures off > of our oxidizer tank and combustion chamber. > > I wrote this driver using the legacy format here: > https://github.com/apache/nuttx/pull/15525 > > I want to adapt it to UORB now because that is the direction NuttX is > moving in and because that framework provides > InSpace with a lot of nice features like mocking, buffering, configurable > sampling rate, etc. for free. > > The UORB implementation as it stands only has one sensor type for > temperature, and it is ambient temperature. > Thermocouples are measuring the temperature of a specific object. I will > need to extend the framework for this > functionality, and I have a few questions to consult the community on > beforehand so I follow the idiomatic "UORB way". > > 1) I would add a new type, of which I'm thinking of calling > `SENSOR_TYPE_OBJECT_TEMPERATURE`. Are there any name > suggestions that might be more intuitive and which convey that this type > is for the temperature of a specific > object/entity, not ambient? > > 2) In the same way, I am thinking of calling the topic `therm<n>` instead > of `temp<n>` that is used for ambient > temperature. This conveys that we are measuring the therm(als) using a > therm(ocoupler). Any comments on this name > selection? > > 3) Is it possible to re-use the `struct sensor_temp` data type for this > sensor type since a timestamp and temperature > `float` are all that's required for both thermocouple temperature and > ambient temperature? Or should I add another > datatype with a different name but the same members? > > 4) In a system with thermocouples there are likely to be more than one, > each one measuring a different entity. In our > case there would be one for an oxidizer tank, source tank, combustion > chamber, etc. How should I structure this > extension of UORB to allow differentiation between the > `/dev/uorb/therm<n>` topics so they can be associated with the > entity in question? I don't think I could encode this within the > `sensor_device_info_s` struct since that is reserved > for sensor and vendor info. Do you think differentiating by `devno` is > fine? I.e. user must know that `therm0` is > connected to the oxidizer tank, `therm1` is the combustion chamber, etc. > > If you have any other suggestions for me, please let me know. I'll > probably reach out again in this thread once I get > started with the implementation. > > Thank you! > > -- > Matteo Golin >
