Sha Xin Wei: PLSS hacking

Date: August 12, 2011 11:46:02 AM EDT

Yes, when Michal and I talked, I expressed a preference for an  arduino box that could stand alone on our local Ethernet and send out data without tying up a whole computer (a capital gear overkill vs software library overkill :) 

Sorry it turned out to be on the bleeding edge!   But I look forward to seeing the data available on OSC.  Can it be broadcast to all machines on local net via some usual convention?   I expect the data rate to be very low so this would eat very little bandwidth.

JA watered the plants last week, said they need basic human live attention too.

PLSS will live again!
Xin Wei 

Michal Seta: PLSS hacking

Date: August 12, 2011 11:22:49 AM EDT

Thank you [Morgan] for the pointers on OSC arduino, I had a quick look at both and Adrian's seems like a very cool tool to have in one's toolbox.  However, both of these solutions use serial communication while my understanding is that we want to communicate over the ethernet.  The OSC library I found wraps the ethernet library and adds the OSC protocol.  I do agree that OSC may be an overkill for sending 8 ints around but Xin Wei expressed interest in using OSC.  In the end it all depends on the end-user/maintener who will make use of this and eventually expand on it.  

I could keep it extremely simple and send just an array of 8 ints or some kind of property list or dictionary if that is what you prefer.

Morgan Sutherland: PLSS hacking

Date: August 11, 2011 9:57:36 PM EDT


Just quickly for now, I try to stay away from OSC libraries because OSC is just a (transport agnostic) naming profile and and the libraries are overkill for sending a few floats. You might have better luck sending strings formatted as OSC messages straight over UDP. There should be a library for that shield with a sendUDP() function. Have a look at Adrian's OSCuino and Andrew Bensons OSC Arduino sketches for inspiration. Away from a computer at the moment, so can't check.

Michal Seta: PLSS hacking

On 2011-08-11, at 9:39 PM, Michal Seta wrote:

Here's a little update because I suppose you're back in town.  I have tracked down an OSC library for the ethernet shield which turned out to be a bit of a puzzle (made for an older version of arduino).  I've found an updated fork but with lots of typos/errors that I managed to iron out and made my own fork :https://github.com/djiamnot/Z_OSC
There are still some mysterious issues but I have actually had a successful OSC communication between the arduino and a Pd patch.  I was a bit delayed due to some family distraction and the OSC bugs chase but I am back on the track.  I think that by next week I will heave the thing working.  I will let you know when I am closer to the finish.

Michal Seta: Reproducibility and Monotonicity of sensor systems

On 2011-03-19, at 12:37 PM, Michal Seta wrote:

Thank you all for your comments, this discussion makes it all much clearer for me, especially the role of the LED indicator.  I too believe that the intuitive/social aspect is more appropriate for PLSS.  In any case, I had no intention of interfering with the original goals and philosophy of PLSS but I think I needed a better understanding.  I was under a wrong impression, for instance, that the LED was to serve as a binary indicator.

See my other inline comments below:  

(> blue Morgan, >> red Xin Wei)

On Fri, Mar 18, 2011 at 11:13 PM, Morgan Sutherland <skiptracer@gmail.com> wrote:

> The ONLY qualities that we should try to guarantee is that, for each given sensor in each given location:

> I think that in addition to these two qualities, we should also do our best to insure that reading the LED's is an unambiguous as possible. This is the argument for using digital – going the analog route, given that we do not have a tremendous amount of expertise or time available, will result in an effectively linear relationship between the output of the sensor (which varies linearly with measured soil humidity) and the brightness of the LED, which leads to a very ambiguous signal.

> I don't think that a reading of only one LED can be unambiguous (unless it is simply a matter of on/off situation which I don't believe is the preferred solution here).  My reading of Xin Wei's comments is that letting the human interpret the LED is part of the equation.

 

>> This should be MUCH easier to implement, MUCH less work.

 

> I actually disagree here. I think that passing the sensor values through the microcontroller and back out to the LED's will be slightly more work than making a delicate analog circuit, attaching it to each sensor, and water-proofing it, especially since I think we would need to use an op-amp + a few resistors per sensor. I have aesthetic preference for simple analog solutions vs. verbose digital solutions however.

Am I reading this correctly?  You mean building n copies of analog circuit and water-proofing them is less work than incorporating one more wire into the design and writing one program (with n instantiations of 1 class)?  In any case, I am definitely in favor of an elegant analog solution.  Do we actually need an op-amp and a few resistors?  I understand that there is some concern about linear vs. non-linear solution but in the long run, if left to humans, they will learn to interpret the reading regardless of it being linear or not.  I think that a simple solution (LED + resistor) will yield a reliable reading of the soil's humidity.

 

>> Use analog first.   Digital only when you must, and understand what reductions you are incurring.

Carrots

I harvested the carrots today. Only a few grew to full size 

I ate two straight out of the soil.

Let this serve as proof that it is possible to make sweet life grow in irregular places.

PLSS related project : RepRap

Building a Mendel RepRap 3d printer started in late January. The specific "flavor" we're assembling is a laser-cut Techzone Remix fitted with 3rd Generation electronics and a Thermocouple/OneWire heat sensor. This post is meant to be a progress report and the start of a documentation process for future references.

Here's how it look as of now :

 

"what's done"

You can probably see on these picture that :

  • The frame and platform is fully assembled
  • Electronics are installed and mounted
  • *All* wiring is done (some is working but will be redone more cleanly)

 

What you can't see :

  • All axis are working
  • Sensors are working (IR optosensors and heat sensor)
  • Heating element (nichrome wire) is working
  • USB>>TTL connection is working and we can interface fully with the motherboard
  • "Stock" host firmware (RepRap FiveD GCode Interpreter version 20100806 ) is loaded on the motherboard
  • Modified FiveD firmware (on the RepRap forum) is loaded on the extruder controller board

 

"what's not"

  • Assembly of a new extruder (the laser cut gears were too sticky and nichrome need to be rewire). The new design is a Wade Extruder and only the tip need to be assembled now :

  • The Z axis drive bars (threaded) stand free in the air : that cause a lot of noise when the extruder carrier go up. We will need to make some kind of crutches to hold it still :

  • The bed now stand on bolts (for spacing), we need to put springs instead. Doing so will enable us to precisely level the platform to make sur that our X & Y axis are parallel to the prinmting bed :

 

PLSS Monday, March 21 Meeting Summary by Morgan

Michal and I met today to set tasks for the next couple of weeks. Here are some notes:

1. we're not going to bother with the piano bed. We pushed it to one side for now, which is much nicer!
2. Michal and I nailed down the requirements for the electronics. Some notes:
  • 5 wires per 'branch': {3.3V, Grnd, LED PWM, Sensor1, Sensor2} – we're leaving room to add extra sensors
  • 1 extra branch for the temperature and humidity sensor: {5V, Grnd, Humidity, Temperature} – I think we can use the 5V out on the Seeeduino even when its in 3v3 mode. Check this!
  • temperature and humidity sensor runs at 5V, so the output will need to be stepped down to 3V3 for the ADC's.
  • Potentiometers will be wired in series with the LED's (no need for extra sensor inputs)
  • Jane will lend a Darlington array for controlling solenoid valves. Probably needs diodes+capacitors for kickback – check solenoid circuits online or ask Martin/Elio. (These will require its own power source, 12V! – Jane/Michal, please check whether the 3V3 voltage regulator in the Seeeduino mega can handle a 12V power supply, otherwise you might need to install a beefy voltage regulator in the box for feeding the 3V3 stuff.)
  • A separate 8-channel LED driver needs to be purchased for the LED's. The Seeeduino Mega has 15 PWM outputs.
  • 8 channels available for soil senors. 2 channels for temperature/humidity sensor. That leaves 6 leftover for LDRs or whatever else.
3. Michal and Jane will work together on the electronics.
4. Michal will build two window boxes, aprox. 10" deep, 54" long, 11" wide. (Laura, is 10" deep enough? Want deeper?) – we can use these to grow beans up the windows again!
5. Michal will spruce up the 'valve stands' by drilling holes through the bamboo. 

Thanks Michal! – see you on Wednesday Jane,
Morgan