[Solved] "Food computer was unable to start recipe"


Hello! I’m developing in my computer, using the “Generic Installation From Source” instructions available in the openag_brain docs, on a Ubuntu 16 virtual machine with ROS Indigo. So far I have been able to test an isolated sensor with

openag firmware run_module -p csv -t upload [args]

and also test it with the full system, using

rosrun openag_brain main -f myfixture

The UI is showing the output variables of the sensor in the fixture.

My last change in the fixture was adding a binary_actuator module in the firmware_module and firmware_module_type databases, as I want to test (via rostopic echo) if the control is working. However, I load the long_test_recipe found here and it is not working. The UI says “Food computer was unable to start recipe”, and the main node says - - [2016-12-06 16:25:53] “POST /api/0.0.1/service/environment_1/start_recipe HTTP/1.1” 400 203 0.068352

Any hints on this?

If useful, more info:

rostopic list says (should’t recipe_handler be here?) :


Here’s the fixture I’ve been using.

How to set up and test a fixture?

@aguadopd I don’t know what the underlying problem might be with starting your recipe, but one thing that I’d like to point out is that the recipe_handler is a node, not a topic (alongside with other software modules). So it should show up when calling rosnode list

Whenever you are attempt to start the recipe, try running rosparam get current_recipe, that should return the ID of the recipe that you started. If I recall correctly, if it isn’t populated it may mean that the recipe has finished, or that it was never started.

EDIT: I’m not sure if the rosparam param name is correct, so make sure it is by running rosparam list first


@david thanks a lot for the input. You have a point, it is a node, not a topic…and also I was unaware of the existence of rosparams haha.

rosparam get /environment_1/current_recipe effectively tells that there is no recipe loaded: ''

rosparam get /environment_1/supported_recipe_formats output is simple, which agrees with the sample recipe used.

So I’m starting to think that maybe it is a problem with the virtual machine or something. We’ve just ordered the Raspberry Pi 3, so I will try in it when it arrives.

Meanwhile, I will wait for someone to help decoding the - - [2016-12-06 16:25:53] "POST /api/0.0.1/service/environment_1/start_recipe HTTP/1.1" 400 203 0.068352 message.


Just tested with the Docker image on the Raspberry and … still not working. Same error (I found it in the Docker logs: docker logs -f openagbraindockerrpi_brain_1: - - [2016-12-29 19:32:10] "POST /api/0.0.1/service/environment_1/start_recipe HTTP/1.1" 400 204 0.152083

UI says Food computer was unable to start recipe

So network problem or virtual machine problem are discarded. The new suspects are the fixture and the recipe.


@aguadopd By getting a 400 status code, it seems that attempting to run the /environment_1/start_recipe ROS Service fails - source here. I don’t know why that could be happening, but here are a couple of things you could try.


I was able to replicate the issue and I think I’ve found the problem.

The UI is sending the following JSON payload when starting a recipe via this bit of code:

{"recipe_id": "test_recipe"}

However, it looks like the API expects the JSON payload to be an array of arguments that will be passed to the service, such as this:


Here is a curl example request that should work with the current API.

curl -XPOST '' \
     -H "Content-Type: application/json" \
     -d '["test_recipe"]'

I just filed an issue on the github repo in case you want to follow up there: https://github.com/OpenAgInitiative/openag_ui/issues/124


Been off some days; sorry for the delay and thank you for your work!

I’ve just tried and yes, the recipes are in the the database. I could start one with
rosservice call /environment_1/start_recipe recipe_name
and then stop it with
rosservice call /environment_1/stop_recipe

Main node logs: - - [2017-01-14 18:14:01] "POST /api/0.0.1/service/environment_1/start_recipe HTTP/1.1" 200 153 0.076069

The curl request way also works perfectly. May we assume that the current official way of loading recipes is with the rosservice call?

In any case, the UI is not showing any target value for variables, but that, I think, is a totally different bug, as rostopic echo /environment_1/desired/air_temperature is correctly outputting the desired values of the recipe. However, rostopic echo /environment_1/commanded/air_temperature never outputs a thing, so I don’t know if I am really controlling — will test one of these days with the Arduino connected. (I don’t know if there should be something anyway). Same for rostopic echo /actuators/heater_1/cmd.
EDIT: Forget about all this paragraph, as there seem to be some fixes in the lastests commits. Will update if problems are solved.
EDIT2: Just pulled the changes and now the UI is showing the desired values. Now topics and params for a specific environment are all grouped under the /enviroments/environment_n prefix, which is OK. The new topics related to commanded variables are still saying nothing, but maybe it’s because there is no sensed variable (I’m still testing without the Arduino) — it seems logical, as there is no value to compare against. Will update if problems are solved.

Thanks again, David, for helping and pointing out the problem! I’ll keep an eye on the issue in Github.


Hey! yeah, I’d say the proper way to start a recipe is via the ROS service call. That’s what the API does, and I believe is the only way to change the running recipe during runtime. However, during initialization, the recipe handler also resumes previous recipes loaded from the db, so you could potentially add one manually to the db to preload it on the next time it restarts.

I believe the /commanded/air_temperature topic was recently renamed to /air_temperature/commanded, so perhaps you were echoing on the wrong topic. Also, controllers don’t currently publish when set points from a recipe are received, they only publish when a new measurement is received. And given that you are testing without the Arduino, you could fake a measurement using:

rostopic pub /environments/environment_1/air_temperature/measured std_msgs/Float64 10


Thank you again David! Well, I meant to ask if that was the easiest and normal way, but it seems that loading recipes from the UI was working before.

I was not lucky faking the measurments, nor with the Arduino and sensor connected. I’m getting values in /environment_1/measured/air_temperature but nothing is happening in /actuators/heater_1/cmd nor /environment_1/commanded/air_temperature; I also measured the pin and is fixed in 0 V. Now I’m working under the Docker environment. It seems it’s not the lastest version or maybe I don’t know how to update it (isn’t it automatic?). I’ve tried docker-compose up -d and docker-compose stop followed by `docker-compose start’.

Anyway, the recipe is working. Maybe I should start another thread.