Sensor programming: Assumptions


#1

To get into things, I am working on connecting two sensors into the Brain, a TSL2561 digital light sensor, and a BPM180 barometer. Most of the code is up and running on the Arduino, but I have come across some issues with the ROS messaging.

There are a number of sensors that have multiple values. The barometer has pressure and temperature (and altitude), and temperature and humidity are often packaged together. There are two ways to code these sensors: 1) create a separate message for each value, and 2) create an array message that packages all values together.

I was having trouble with the latter (and little documentation for multidimensional ROS arrays) and noticed that the humidity/temperature sensor in git has two messages.

  1. Is this the standard? Is this needed so individual values can be charted and stored in the database?

If not the standard, I think it should be declared as such. While it requires more control code, it simplifies messaging and handling.

  1. Is there a limit to what can/should be returned? Not limiting the messages allows for numerous permutations to be send (barometric pressure as Pascals, atmospheres, mm Hg, inches water, altitude, …; temperature as F or C (or K)). This also avoids array packages where you don’t know what you are getting.

  2. Are there any standards for units (ie. “temperature should always be exchanged in C”)? Now is a good time to start pushing standards while things are just getting started.

Regards,
Howard


#2

@webbhm

  1. Publishing a compound value to a topic it’s an interesting idea in order to optimize things, however I don’t think they are supported (within the openag_brain scope) because the way the rest of the software modules are structured. They expect a single value per topic, which gets filtered (smoothed), persisted in the db, and acted upon. I believe publishing value arrays per topic would require adjusting the Subscribing logic.

  2. & 3) Very good point, I don’t think there is documentation anywhere on what units are the values expected in, and there should be. Currently message types are just primitive data types (such as std_msgs/Int32, std_msgs/Float32) which don’t have any semantic meaning of what kind of units they represent. Specific message types could be used, perhaps using the ROS sensor_msgs package is a good idea, it defines message types like this one: sensor_msgs/Temperature, which states the units should be in Celsius.


#3
  1. @david is right on this one. Most of the logic assumes that there will be one value per topic.

  2. & 3) We have decided on standard units for all of the variables we have been using in house. This file on github lists the chosen standards. I agree that this should be documented better, though.