Running custom fixtures/Sensor output as topic


I’m currently using openag_brain to try and get the sensor data from some of the sensors included in the default fixture.

My custom fixture looks like this:

and I have flashed it properly to the arduino (afaik, the platformio logs seem to indicate it flashed properly and looks similar to when I only had an AM2315 on it)

However, when I rostopic echo /environments/environment_1/somesensorvalue or some other relevant looking topic it doesn’t seem to output any data.

Has anyone else had trouble viewing the sensor output? I’m curious if there is a ROS way to output any updates to any rostopic into stdout or something.

My rqt_graph looks something like this.

My suspicions are either I wired my things incorrectly or that there’s some funky business going on where the Arduino talks to ROS and the sensors aren’t writing properly as a ROS topic.


Do you have a DS18b20 temperature sensor wired up to pin 5 (1-wire) and the I2C sensors (Atlas EC & PH, AM2315, MHZ16) wired up to SDA (pin 20) and SCL (pin 21)?

Have you tried rostopic echo /internal_diagnostics? When I tried that, it repeatedly dumped all its sensor readings to the console until I stopped it with ctrl-c. In my case, there weren’t any measurements other than high water level because I had no I2C or 1-wire sensors connected.

Also, if you want to look at the output of your I2C bus, I’ve been working on a simple I2C monitor that I’ve been running on an Arduino Uno clone.

edit: Also, did you check that the SDA and SCL pins are connected all the way through. Here’s an example of how that can go wrong:


Also, what happens if you try rostopic list | grep 'sensor.*raw' and then rostopic echo /sensor/<sensor_name>/<measurement_name>/raw for all the topics in that list?

  1. I’m not using any shield so the SDA and SCL are going straight into the Mega.
  2. One-wire to Digital pin 5, and I2C to the SDA/SCL looks fine
  3. rotopic echo /internal_diagnostics is silent, I also checked with rosbag record -a and that’s also silent
  4. rostopic echo /sensor/some/sensor is also silent.

My suspicions lean towards some place where the arduino talks to ROS.


I asked gordon, he said you’re meant to run rosrun openag_brain flash while ROS is not running, which was new-ish information to me I think.

I’m still getting this problem where the arduino is probably not talking to ROS though, so unless this isn’t “flashing while ROS isn’t running” I’m stuck.


So my problem was that one of the I2C sensors was faulty and was crashing the I2C bus.
Will try reconfiguring and getting all the sensors working…


There’s library code on the Arduino that needs to match versions and configuration with the python rosserial code on the Raspberry Pi. It looks like maybe those are out of sync.

When was the last time you did a git pull on your local copies of the openag_python and the openag_brain repositories?

This is the script I use to get all my local stuff on the Raspberry Pi synced up with GitHub:

echo pulling openag_python
cd ~/openag/src/openag_python
git pull
echo pulling openag_brain
cd ~/catkin_ws/src/openag_brain
git pull

After that, I do source ~/catkin_ws/devel/setup.bash and then start doing stuff with ROS.

The firmware is generated by code in openag_python, and the rosrun commands are implemented by code from openag_brain. The fixture json from openag_brain controls which firmware modules get downloaded and compiled.

I’m not sure when the openag and rosrun openag_brain cli tools will try to update python dependencies and Arduino libraries. It’s possible that one–but not both–of the firmware tool or openag_brain automatically update the rosserial version it uses. Maybe you need to manually run some other script to make sure all the python dependencies are up to date. Gordon would know about this.


Oh, okay. It sounds like you’re making progress then. Good luck.


I had this problem yesterday so I wrote essentially the same thing yesterday lol


Have you seen this sketch that Jake apparently uses for debugging hardware independently of ROS? It might help you isolate I2C problems from rosserial problems.


Yeah, I saw this but I don’t have all the electronics for the pfc2 so I don’t think it would be too useful for me yet.

Once I get around to building the pfc2 I’d probably find it useful though!


So I’ve identified the problems at Atlas Scientific sensor problems.

Reading this datasheet it looks like there are multiple modes and you have to set it to “I2C mode” somehow. (One way is to short a pin)

The firmware module seems to assume it’s already in I2C mode

There’s also an indication of a “permanent mode setting” action.
Is it possible the kits come with the chips in permanent I2C mode??


I “hacked” this a little by doing the shorting the pin routine and got a pH reading.

The next step is going to be figuring out how to isolate the EC and pH sensors…


I don’t know. So far, Caleb has mentioned that work on preparing kits is in progress, but it sounds like they aren’t finalized or available yet. Maybe the I2C setup procedure is to-be-determined.

If you want to see how the “OpenAg Signal PCB v1.1” handles power isolation for EC and PH, check out this photo from the assembly instructions. Zoom in on the board on the right. It looks like there are power isolation circuits in the center of the board to the right of the 3-pin female headers. I haven’t found a schematic for the board, but maybe it’s in with the GrabCAD files somewhere.

By my reading of the PH sensor datasheet, the sensor board has to be manually prepared–either send the start I2C command in UART mode or short the pins while power cycling it–to put it in I2C mode before it’s hooked up to the sensor board. I’m not sure where sensor setup documentation will live eventually, but this seems like a good thing to make an issue or pull request for.


I tend to have a test script that I run directly from Arduino to check the *.h and *.cpp files, as well as the physical sensors. I build it while modifying the sensor code for OpenAg. It allows me to check the sensor without the overhead of Docker or ROS. I have been flashing while ROS is running, then rebooting.

  1. How do you stop ROS so do the flash? I have been running flash while things are running. However while I see data in rostopic, I am not always seeing it get through to the database; though a reboot and some patience seems to work.


if you’re using the systemd service, sudo systemctl stop openag.service and if you ran rosrun openag_brain main then you just ctrl+c stop it.

Not sure about docker.

Putting stuff up to the DB is another matter. I use openag db load_fixture for fixtures.


Do you know where ROS connects an output rostopic message to the CouchDB? I have two sensors running and outputting rostopic data. One happens to be named light_illuminance, so it is hitting some default set-up and going to the database and the UI. The other one is a barometer/temperature sensor (BMP_180). The fixture_module_type sets up the rostopic, and after flashing and rebooting I am getting data via the rostopic. However, that data is not getting to the databse.
It looks like the UI code has a listing of topics it will display. This is not configurable for an individual computer, unless the UI is installed locally.
Somewhere there is a configuration that has the database subscribing to sensor message, any idea where this is? It would make sense to be a json file, but I don’t know its name or location. It would make sense that this would be the same as connecting sensors to controllers.


I think it’s the sensor-persistence node in ROS but I haven’t read into the code for that. I’d assume everything openag related needs to use the specific var_types defined in openag_python/

I had some similar trouble trying to get recipes working and it was just that the topic name wasn’t listed in var_types.

V2 Food Computer Kit Build

Also regarding the UI, maybe here?