Question on the Github Raspberry Pi image


Hi all,
Can anyone tell me if the image file on Github includes all the required software and drivers for the TFT touch screen ?
If so, can I still use an external HDMI monitor while the touch screen is connected to the Raspberry Pi ?


Good evening,

External Hdmi don’t work! The image run only with this one:


@Peperoni, To which repo are you referring? It’s been updated since I’ve last been on there.

The image I used included what the touch screen needs. Though it does not allow for an external HDMI monitor :frowning2:


I thought so too, but I’ve heard others say it does. I believe it works if its plugged in at boot.


I was using an HDMI monitor with this image. The problem is that I don’t know if it’s possible to load the GUI, or at least I couldn’t do it. So I used only the terminal. But since that’s the same as connecting to it via ssh, that’s what I’m doing now.


Forgive my ignorance… but what is the name/location of the raspberry image file that you are referring to ? (I don’t seem to be able to find it on the OpenAG Github repository…



Ah… OK. So I should not worry about the fact that it is stated: DEPRECATED ?
Thanks !


Hmm… I donwloaded this image and flashed it to my SD card. I am running it on a Raspberry Pi model 3 with 3,5" PiTFT touch screen >> no boot up !
I disconnected the touch screen and used an HDMI screen >> no boot up.
( I only get a ‘rainbow screen’ from my PI )
Any other suggestions ? (much appreciated)
( I had a running set-up first, without the GRO software. Is there somewhere a manual on how to instell all packages manually on the Raspberry PI ??)


Did you see the comments here about using WinRAR?


@toby I did! But I’m using MacOS. I didn’t have any issues with other img files, so I don’t think the problem emerges from unzipping. Or could it be specific for this images? (Maybe caused by the Google Drive?)
I will test another unzipper and report back.


My bet is that it’s because you’re trying to put it on a Pi 3. My understanding is that the image is for a Pi 2 model B. Do you have one available that you can test with?

I just download the image (twice, to make sure it ended up the same), extracted it with WinRAR 5.40 beta 2 on Windows, wrote it with Win32 Disk Imager version 0.9.5 and tried to boot the Pi. It did not boot when connected to an external HDMI monitor. I connected the display listed in the BOM and it booted without issue.

I then ran a apt-get update && apt-get upgrade, and I was worried that it would botch something, but it seems to boot fine. The UX on such a tiny screen isn’t great, and there’s a screensaver that always seems to be popping up…

I also can’t seem to ssh into it, something to figure out shortly I guess.

Toby's Build Diary


Its the same with the PI2!


I just had another go at it > still tte same problem: No boot on HDMI and no boot on PiTFT…
I unzipped using the command line (WinRAR for Mac did not work for me…)
It does not seem logical to me to downgrade the hardware to a RPI model 2 in order to get a working set-up. In my opinion software should adept to hardware and not the other wat around. I prefer to try to make a new build for RPI 3, but I need to understand which software should be installed (and preferably how… I am still new at this !) Can anyone help me here ?
Soon there will be no RPI 2 available so we need to move forward anyway…
If this is not an option I will need to find an old model 2 somewhere, but again: that doesn’t seem to be the right way forward to me…


Well then, that rules out that idea!

I agree, it would definitely be preferable to use more modern hardware. My understanding was it was imaged off the Pi 2, so my suspicion was that it would not work on other models (newer or older).

I believe @DougieFresh has been working on a Docker based install here - I have no idea where that is relative to the image or if they’re even trying to accomplish the same thing. My understanding is they’re trying to move to ROS and the first rev was not?

While it’s frustrating that it doesn’t work like that, it makes sense - by definition hardware drivers are bound to the hardware, so a software abstraction is a tough thing to accomplish. It’s the same as trying to switch the boot drive between regular computers with Windows, OSX or Linux - frustrating, but not unexpected that it doesn’t work at all.

@Peperoni - are you able to boot with a “regular” Pi image and the same hardware? E.g. you’ve ruled out power supply issues, SD card corruption etc?


@toby Yes, booting with a clean image from Adafruit give no problems at all… so that’s why I thought that I needed to start building from there.
To be honest: I get the feeling that the OpenAG Github repository lacks of documentation that can be understood by novices like my self. There are just too many acronyms going around that don’t make sense (yet !) and working from a sub-directory that is tagged ‘deprecated’ is just not inviting at all :-). What I would really appreciate is a ’ Gro-software-for-dummies ’ manual take makes me understand what is what. Just copying an image file and running it without understanding it does not give me the option of contributing… Maybe we should consider adding a new category for newbies like myself, explaining how everything works. A lot of information comes from trial-and-error. If we want more people to start building PFCs we need to make the information more accessible. I would love to help out if there was someone that truly understands what is happening. What is the best way to move forward ?


Hmm… I’m pretty much out of ideas then. Maybe it’s just a particularly fragile image that needs to be coddled with exactly the right software? I can try creating an image of mine, although I suspect it will be almost identical. Let me know if that would be any help.

I’m right there with you - it’s a bit intimidating to get into it. So far the community has been pretty responsive on this forum though, so I’m encouraged.

I think what you’re running into is early-adopter-itis. The team behind the food computer looks like they’re busy building - my guess is that that’s where people like you and I come in. Plenty of opportunity to make it more accessible for the next person to build.

I’m in almost exactly the same position, just a little behind. I’ve started ordering things, but I haven’t figured out what the essence of the food computer really is. I was hoping once I got a bit further along and had some concrete questions people would be helpful. There seem to be at least a handful of people in the community who have a working food computer.


So as has been mentioned several times, the documentation for the initial release of the software was pretty minimal. The reason it hasn’t been improved is that we decided to redesign a lot of the architecture (e.g. moving to ROS and CouchDB) and basically threw out that code. However, the new codebase doesn’t yet have all of the features of the first version and isn’t well documented either (although I’m currently in the process of writing documentation for the Raspberry Pi code). We’re also trying to make things like setting up the Raspberry Pi much easier (see this thread).


Dear all nerd farmers @JoshSinykin, @adrianlu, @gordonb and Co, our last task is the configuration of the RPi and with the constant proliferation of new content in GitHub, plus comments in the forum, we are more confused than one month ago.

We got the original image of the software a while ago, thanks to @JoshSinykin (2016-02-19-gro-raspberrypi.img), and we were able to boot the RPi (but the grodaemon service closed unexpectedly), and since then, this has evolved in several ways: the original img was deprecated, then it came the openag_brain, the openag_brain_install_rpi, the openag_brain_docker_rpi, all this conversation about using the docker, … so could anyone help us with a clearer set of indications (“first do A, then do B and finally do C”)?. As soon as this is done, we can start our first crop.

Thanks in advance,

Pau & Rafa


Hey @pauanta, didn’t want to leave you hanging. Unfortunately, I haven’t been staying on top of the development. I’ve taken a step back to figure out what I should do next with the FC.