MVP - Product Design


#40

I think the MQTT route with data published to Adafruit IO, or another free service provides this feature. No need for exposed ports or firewall exceptions, it’s simple to use with a great UI Considering alternatives to the Raspberry Pi and Arduino


#41

Here is a test of the survey I plan to post so far:

What size should the MVP be?

  • Minimum Size for one plant (leafy green)
  • Same as PFC V2

0 voters

Minimum sensing requirements?

  • Temperature (Air)
  • Temperature (Water)
  • Humidity (Air)
  • USB Camera (Aerial)

0 voters

Minimum actuation requirements?

  • On/Off Relay (blinking LEDs or 120V relay)
  • Variable Actuation (Thermostat)

0 voters

@wsnook In your lettuce dataset, how did you remove all images without light?

@yusuf.khan.su I haven’t made any hard decisions yet on the frame/skin. I do think though that PVC is probably the cheapest common material we can use to make a frame. I also think that some sort of reflectivity is a very important aspect. I would prefer not to require the user to paint/coat anything which is why Mylar has been very appealing. After I get feedback from the surveys and have made more decisions based on local prototyping I will update the wiki.

Point of clarification: when you say “MVC” what exactly are you referring too? I’m going to assume you mean Minimum Viable Computer or Concept, pardon me if I’m being naive.

I defined at the start of this post “It is for this reason that I propose we develop our MVP to be designed by the average hobbyist maker, and is intended to be operated by an elementary school teacher with the help of their class.” That being said, I am inclined to start to agree with you that our true MVP is just for makers. Could you elaborate more though on what you see the differences between a simpler PFC and an MVP to be?

I love the simple bottle design. This is something we had discussed locally doing as a teaching exercise or a classroom experiment, I think @TechBrainstorm has done something similar as well. That’s very interesting that your camera is day/night. Does the camera use the two bulbs on the side for night lighting? Or is there some other method for night vision, also it isn’t wide angle, correct?

I definitely think there are people who would appreciate if you posted a little guide to doing the plastic water bottle. I also love the idea of using LED’s as actuators for testing.I’m also curious your results as it grows and whether or not you experience disease or are able to keep a healthy root zone. Can you provide a link to your lights? I’d be curious to see if they’re powerful enough.

Absolutely love this idea. What a great idea to enable to the software development and control functions to be defined in parallel to the hardware and system design without requiring people to have all of it in front of them.

On the subject of temperature sensors, @webbhm where did you get your SI7021 & for how much? DHT11’s are common and cheap, Si7021 seems like a fine alternative so long as I2C is easy and on the table.

Will reply to the rest of the comments in a bit, and then post the survey questions. I appreciate everyone’s active participation, this is quite a lot to digest!


#42

In regards to your MVP software requirements list:

  1. RTC - Is there any need for a RTC? To me, this is an unnecessary expense so long as we can rely on things to sync correctly. I know the argument can be made that someone might not have internet, but for this MVP I don’t think we should try to worry about that.

  2. @webbhm wants a wall timer, this would eliminate the need for any relays in the MVP which is a plus. @wsnook would it be possible to log photoperiod based upon camera sensing? I know you were able to remove dark images, perhaps we can use similar logic to calculate photoperoid without having actuated it via the controller? The other route is we create an AC relay block similar to the PFC V1 AC Control Block, this would be nice because we’d have 4 plugs now that can be used for whatever the user wants. They could plug in a space heater and actuate that to raise temperature, or a humidifier, etc. The third route would be more the route of the V2 where a 12V DC current is actuated via a relay. The problem is with going this route now we’re getting into LED drivers, etc, which I would just assume stay away from for the MVP.

  3. I have to disagree that the temperature in the reservoir and the air is uniform. This can vary quite a lot based upon air flow, lighting, water level, and even color of your reservoir. All of that being said, since there is at this point nothing we can do about the temperature of the reservoir there isn’t a ton of value in measuring it. This is also another example where if one of us measures both temperatures, we can likely “guesstimate” what the reservoir temp is based upon air temp with __ lighting and __ reservoir.

  4. The real decision with this one is does it need to be variable speed, PID, or simple on/off. I’m tempted to say simple on/off which would allow us more flexibility for the user in choosing which fan. We could also then build the fan to plug directly into a 120V relay and be controlled the same way as other things like I mentioned above. @webbhm what is the minimum hardware requirements to run a 12V DC fan at variable speed?


#43

Yes, very much so.

  1. There seems to be height based stratification if I don’t have a fan blowing. The dynamics change based on whether the grow light is on or off.
  2. For microgreens, it seemed like evaporative cooling was lowering the tank temperature below ambient when I had the fan pointed directly at the grow tray.
  3. For AeroGarden lettuce, the LED power supply was under the tank, so it heated the tank about 2°C above ambient without a fan. If I pointed a fan right at it, the tank temperature tracked ambient air. [edit: aquarium pumps or the like could have a similar heating effect]

Based on building inspection thermal imaging work that I’ve done, I can tell you that it’s common for things in close proximity to be substantially different temperatures for surprising reasons. Since we don’t naturally see heat, it’s hard to develop intuition for how it works. DS18B20 sensors are cheap and easy to use, so we might as well stick them on stuff that might matter.

To begin with, I set the timer for on at 6am and off at 8pm, and I used file names with timestamps for all the images. So, it was easy to predict the file names of dark images.

First I used rsync to get a copy of the images on my mac from the pi, then I duplicated the directory to avoid irreversible mistakes, then I used rm with a glob pattern to remove what I didn’t want. Since I picked the image recording times to be 10 minutes away from the timer switching, I didn’t have to worry about clock drift.

I think this would work, but I’m just making it up now, so I might not have done the pattern right. I always test this stuff with ls first anyway before using an aggressive glob pattern with rm or mv.

# file names have the format YYYY-MM-DD_HH.mm.SS.jpg
rm *_{20,21,22,23,00,01,02,03,04,05}.jpg

I used a similar approach to separate the files for 30 minutes past the hour

rm *_??.{10,20}.??.jpg

#44

I overlooked this question in my earlier reply. Yes, probably so. If you use the Raspberry Pi camera with the raspistill command line tool, it saves exposure details in the jpeg EXIF metadata. By checking the ISO setting, it’s easy to get a relative measure of lots of light vs. not so much light. This comment talks about using exiv2 to check the ISO: Growing food: I just ordered a MicroGrow Kit from Hamama

It’s also possible to make histograms and fancier stuff using ImageMagick (convert, mogrify, etc.), but that takes a lot more CPU than just checking the metadata.


CV and Image Processing for the PFC
#45

I posted a survey to the MVP - Commmunity Development thread. I would appreciate all of your feedback. I hope I did a good job representing the discussions concerns and hopefully we’ll get a few responses which will tell us what users really care about.


#46

@webbhm as an update to my comments on temperature, here’s my current temperature chart for today. Blue dots are DS18B20 and red dots are Si7021, x axis is time, y axis is °C. I’ve got the Si7021 taped to the side of the bookshelf I’ve been using as a growth chamber–about 5 inches up and maybe 0.5 inches out from the side of the shelf. Until 2:40pm, I had the DS18B20 laying on the bottom of the shelf, but then I moved it so it’s hanging in the air about a foot above the Si7021. As you can see, starting at 2:50pm, the DS18B20 is now a little warmer than the Si7021 instead of about half a degree cooler.


#47

@wsnook
Once we get some boxes, these sorts of graphs will be useful to see how much (or little) the circulation fan affects things, leaf canopy, etc.
The other factor we need to watch is callibration. I have several thermometers, and they can be a half degree different from each other.


#48

I absolutely agree with you. In refrigeration manufacturing they commonly test the cases at dozens of places in the unit. They also do these tests at varying levels of content (full shelves, empty shelves). One thing that we’ve yet to even mention is how much as the plants grow that will change the unit. In the very beginning, when the plants are tiny much of the light will be hitting the top of a reservoir (if your reservoir is black, this can really make an impact). As your plants grow, much of that energy that then turns into heat is later blocked by the canopy of your plant. I definitely think there is a huge amount we can learn by comparing the differences inside of a grow box.

@wsnook cool graph btw. Curiosity, why do you think there was a dip midday?


#49

Thermal mass filters and delays heat changes–it’s kinda like an audio filter circuit with a time constant and a phase shift. The big drivers are radiative heating from the sun (really hot) and radiative cooling to the night sky (really cold). Today, 9am was about when the effects of today’s sun caught up with the effects of last night’s cold empty space.


#50

@_ic and @yusuf.khan.su (cc Peter & Howard),

I’ve picked a short term direction for my experiments, and I’m interested to hear if you have ideas about ways I might make that work more relevant to your own projects. In particular, I’m curious about maybe porting firmware from Photon to Arduino-like hardware that you might already have.

Last night, I started hacking on my farm controller and firmware, and…

  • I decided to remove everything about the Raspberry Pi camera. My sense is that, for most people, using a cron job with raspistill would probably be sufficient–no need for a custom controller. If you also used a script to make a symbolic link to the latest picture–maybe in a place like /var/www/html/latest.jpg–it would be easy to see the pictures using nginx.

  • I’m in the process of working on a simple plaintext record based file format that can record all of my sensor measurements. Previously, I could only record two temperatures and notes. But, the new way will handle lots of different measurements and metadata. This is a work in progress.

  • Once I collect a day or two of data in a file format I’m happy with, I want to start improving my SVG charting code to display temperature, relative humidity, and pressure.

My questions for you folks:

  1. Does the sensor file format I’m working on sound interesting to you? What about the SVG chart generation code? If the answer is “yes” to either of those, is it a problem that I’m writing the code in golang? Would it be a lot better for you if I were using Python?

  2. Do you think the firmware I’ve been working on (sensor & actuator drivers + serial control protocol) has the potential to be useful in your projects? Are you interested in trying to run it on other Arduino-like platforms? Photon is mostly compatible with Arduino, so there’s a good chance that my code might work fine in the Arduino IDE for many other devices.

  3. Do you have any ideas about ways I could steer my work that would help with your projects? I make no promises, but I would enjoy seeing my code be helpful outside my own little experiments.

[edit: here’s a gist with a sample of the data I’ve been collecting since last night: https://gist.github.com/wsnook/05f756ae1b6df0b851761343c9cc19a1. I’m not happy with the record format yet, but it’s a good start. I think something like this would be better: https://gist.github.com/wsnook/fcf1d49faf650f1f5a5483d46d60e41a ]


#51

@wsnook We seem to have pivoted in different directions. Now I think a camera is vital, and after a question from Peter, I’ve decided to build my next controller around a Pi Zero.
I think the MVP should support all popular platforms, including Arduino (covers ESP, Edison and the new boards), but I’m more focused on a full PFC for now.

For the recipes, my plan was that the PFC would store data in a .csv file, something like this
time,air_int_temp,air_int_rh,co2,air_ext_temp,air_ext_rh,water_temp,water_ec,water_pH,ppfd_red,ppfd_green,ppfd_blue,hpa_feed,hpa_interval,hydro_feed,hydro_interval 1495646318,22,60,,23,70,19,,,30,12,7,1500,600,,

Blanks where the PFC can’t capture that data, or if it doesn’t apply, ie hydroponics or HPA
This file can be processed afterwards into a recipe that analyzes changes and important conditions.

For your questions, I have no preference for the code language.
For the firmware, our data acquisition methods are quite similar, but most of my code is for MQTT. I’m not familiar with how the Photon’s WiFi works, is that a wireless serial bridge? I would like to see how it develops. When I return to Arduino, I think the methods could be useful.
I don’t know how and where our projects could intersect at the moment, mostly because my direction is in limbo.

Let me know what you think of the data format, and I’ll post my Brainbox plans soon


#52

I agree that cameras are very useful. I removed the camera control stuff from my code in the last couple days because it seems like I was going to a lot of trouble to accomplish a task that cron and a bash script could do better. I still think images are important.

I started off using a column based file format, but I got frustrated with it. The trouble is that it’s hard to anticipate in advance what you might want to add or change. On the other hand, a big advantage of CSV is that it’s easy to import into a spreadsheet. Chapter 5 of “The Art of UNIX Programming” has an interesting discussion of plain text file formats.

[edit: For your question about Photon wifi, I’m not sure what underlying protocol they use. Their focus is on an ecosystem of APIs to provide things like low latency event notifications (haven’t tried it), over the air firmware updates (this is what I care about–it’s great), IFTTT integration (haven’t tried it), and webooks (haven’t tried it). In my firmware, I mostly leave the wifi turned off and talk to a Pi Zero or Pi 3 over usb serial.]


#53

Particle seems to be working nicely, but fighting Pi.
The logic to get lights on/off from the camera (especially if using a USB camera) gets to be a bit tricky, so I decided to go with a simple ($1) photocell. After getting no readings (and it works fine in Arduino!), I discovered that Raspberry doesn’t really implement analogRead. So I grabbed my handy TSL2591. Again nothing, though it works fine on Arduino with my old code. Turns out I have a Grove version which doesn’t work with Particle’s Adafruit public library. So, order another sensor via Amazon. My $1 solution has now jumped an order of magnitude.
It looks like Particle will not write to a local disk (it is IoT), so will likely dump data out to a Google spreadsheet (code examples already exist). Some of the Spark dashboard looks nice for output, but keeping it minimal for now.
@wsnook
The problem with data formats is you either have to say (almost) everything in one line, or you need a relational database. For sorting and extraction, I like each reading on a separate line (rather than bundled by sensor); but then there is the problem of associating readings to sensors and/or locations - where to put this relationship information. The other issue is where to put context which is needed when uploading/consolidating data; do you put this identifier (which one?) on each sensor reading, or add it when doing the uploading. I can go either way, but inclined to ignore space issues and make a full record from the start.
I don’t have a Pi Zero at the moment, but if they work with Particle then it might be a cheaper option to the Pi 3. Either way, I am starting to see the price point of the MVP to be at or below $200.
At the rate we are moving forward, my tomato may soon require a box and controlled environment.


#54

If you add an appropriately sized capacitor, you can measure resistance with a digital pin using RC time constants. Adafruit has a good article explaining how to measure photocell resistance on a Pi along with a longer tutorial on photocells that gives more background.

Where did you look? Have you read this, this, and this on the Particle forums? I haven’t tried using the SDFat library they recommend, but I’ve been thinking about getting a microSD card breakout adapter and having a go at it. Even if it works and saves maybe $10-$20 in parts over just using a Pi Zero, I’m not sure if it would be worth it though. It’s hard to beat the convenience of ssh, scp, and rsync for moving data around.

Yes, I agree. That’s a big part of why I’ve switched my code from logging with a TSV file format to using records. Relational databases are popular, but people forget that they aren’t the only way to implement records (see my link above to The Art of UNIX Programming, my code to parse the log file, my code to draw charts from the parsed log data, and this gist with my sensor data from the past couple days).

I like the tomato picture.


#55

@wsnook
I saw the idea of using a capacitor and timer to coerce an analog pin, but the accuracy and issues with processor lags scared me off. I will likely do a ‘bake off’ with the I2C sensor and this method and see how they compare, nothing to loose since I have the photocell and can probably scrounge a capacitor. Have you ever tried this, how well did it work?

I missed the SDFat and other postings, will definitely have to look into that as it would greatly simplify the architecture and keep all data local. Thanks for the reference! If do this, then we definitely need to get into discussions on file formats.

Just stumbled over another problem (minor) which is the flip side of the analog read - controlling fans. I have had my circulation fan hard wired to GND and 5v, but was thinking of an analog pin for the exhaust fan: 1) There is no analog out (though can fake it with a capacitor), 2) Raspberry only has 3v on the GIPO, which would cut the speed by 1/4 of normal (12v). I hate adding more stuff, but seriously thinking of a 12v PWM fan with power from a wall wart and hooking the PWM to a pin. I believe @Webb.Peter used this trick on his early growth boxes. Might just do both fans this way, for consistency; and it would allow experimenting with the circulation fan and its affects on plant strength. Any opinions or thoughts?


#56

Yes–years ago on a Basic Stamp and it worked great. But, if you use a Photon instead of the Raspberry Pi beta, you can just make a voltage divider circuit, use a real analog pin, and be done with it.

I’d suggest you think low tech and just get a fan that’s rated for the voltage and flow rate you want. If you buy from an electronic parts supplier like DigiKey or Mouser, it’s easy to get detailed specs before you buy. If you want to experiment with flow rates on the cheap, buy more than one fan and swap them out. Alternately, since a lot of the relay boards have multiple relays, you could use more than one fan and adjust the flow rate by how many fans you have turned on at once. Or, you could wire up a low-flow fan to be always on and supplement it with a switchable higher flow rate fan.


#57

@webbhm I’ve been thinking about what it would take to make a mostly offline data logger and controller that will periodically try to phone home to the mother ship (Particle API, local server, or whatever) and upload its sensor log.

The SD cards we talked about would be one option for storage, but I’m not so sure about the cost benefit in code complexity, hardware, and ridiculously over-provisioned storage capacity. Using the record format in the gist I linked to above, 24 hours worth of DS18B20 + Si7021 + BME280 data recorded at 20 minute intervals only took 6691 bytes.

By my calculation, at that rate, it would take about 400 years to generate 1GB of data. One year would take about 2.5MB, a month would take about 210KB, and a week would take about 50KB. My present record format is meant for easy human readability including units and full sensor names. I could easily shrink it down to 4543 bytes per day (1.7MB/year, 150KB/month) without affecting readability much, and a packed binary encoding could go a lot lower.

All that is to say, SD cards might be the wrong way to go. Perhaps we should look at things more like this 32KB I2C FRAM chip (fast like RAM, non-volatile like flash, and lasts a long time). 32KB would be big enough to go several days without network connectivity.


#58
  1. @wsnook I personally (and I feel like others would too) find value in a post (even a thread) describing your chart generation techniques. As for the code question, I don’t have a ton of experience with either, though I do have some with Python. The only charts I’ve ever made from scratch were using Google Charts. I definitely think charting is a necessary function of our application. The lazy part of me wants to ask is it really necessary that we build our own charts from scratch? Most of what I’ve done over the past few years for my day job is reporting/dashboarding configuration (fan of Power BI). I would love to try and integrate into some pre-existing BI tool that we can piggy-back off of for free (similar to Particle). Perhaps I’m thinking more on the analysis end and you’re trying to get at real-time monitoring. This is just my opinion if you feel this is a bad direction to go in I’d love to hear why.

  2. Yes, depending on which sensors you are picking. I am extremely interested in trying to test different controllers with similar code, I think if we develop our work with that mentality it will allow us to pivot and experiment much easier down the line. I’d be most interested in knowing what is different between platforms. One of the reasons I was checking out Blynk early on was because it seemed to allow for such ease switching between controllers using its virtual pin interface.

  3. I’ll answer this more in other posts.

Are you trying to actually go into the image itself or the meta? I was under the impression there was a way we could determine the brightness of the image just by reading the metadata, I can’t remember but I think it was @wsnook who pointed me to that idea.

What are the hardware requirements? (Wire to the cell, breadboard, resistors, etc).

Did you end up saving to a local disk? If so what’s your preference on file formats?

@wsnook how would you manage images if you moved away from an SD card? Also, do you see yourself as having intermittent connectivity? I understand the desire for this in remote locations or specific applications, but most users I feel will want some sort of real-time monitoring. Would you plan to have both options depending on the connectivity?


#59

This is the first of many future actuators that will cause problems for us. This is why I really like the idea of controlling EVERYTHING from the beginning off of a 120V AC relay. Similiar to the AC Control Block in the V1 PFC:

The BOM and assembly instructions are 1. here: https://github.com/OpenAgInitiative/gro-hardware/blob/master/Guides/PDF/MotherboardAssemblyGuide.pdf

I bring this option for two primary reasons:

  1. Simplicity - I haven’t dug into the code on the V1 yet for the control block, but I’m going to assume it’s pretty straight forward. If we stick with a relay as opposed to some sort of PID or PWM. This simplifies not only our software, but our hardware as well. In terms of a driver for the 12V fan this is what I used previously. The moment we try and actuate things above 5V the “user” will have to purchase lots of little parts, something we may not mind, but it increases the difficulty in sourcing and assembly. Here is an idea of what was required when I did this previously.
  2. Easily customized - User won’t have to rewire anything to unplug one actuator and plug in another. We can default TL (Top Left) Exhaust fan and then just turn the relay on and off when necessary. This gives the user a system that’s just waiting for an “expansion pack” to add on a heater, or humidifier.