Go Down

Topic: Going forward with my prototype (Read 215 times) previous topic - next topic

MonyetIblis

Hi everyone,

I have been using this forum for a few months now as a guide to developing my prototype. It has been very helpful and I would like to thank all contributors out there.

The device that I have been working on is a little side project of mine which I intend to implement at a farm I work for.

It measures the soil moisture based on weight of a sample of pots containing plants. As the moisture evaporates and is consumed by the plants the weight decreases over time. Once the weight of the pots reaches a certain level, the arduino triggers a relay, which will close a circuit connected to our existing irrigation controller causing it to irrigate.

The device logs all the measurement data to an SD card, as well as uploads the data to a thingspeak channel through a SIM800 module.

So far so good. Everything seems to be working fine, and I am very happy with the result so far.

Up till now I have been testing the device in a small 'home' setup. I would like to implement it in one of our greenhouses at the farm, however I am a little concerned for bugs and the like that I may have missed in the sketch. Especially since scaling up my project means I am putting thousands of plants at risk. Also, since this is my very first time programming anything, I am sure my sketch is full of mistakes.

How do people usually go about improving their prototype code to an 'implementable' level? Are there people within the arduino community that offer 'code rewrite' services to eliminate potential bugs, make it run smoother, improve overall performance etc?

In general, once people have a working prototype, and want to go on to develop a more robust version (but don't have the knowledge to do it themselves), what options are there?

I hope to learn more about the general development process.

This project is not necessarily a hobby of mine, nor does it have a commercial aim. Its somewhere in between, and is primarily meant to improve irrigation at the farm.

Thanks!
Johan

Robin2

#1
Apr 27, 2017, 03:20 pm Last Edit: Apr 27, 2017, 03:21 pm by Robin2
however I am a little concerned for bugs and the like that I may have missed in the sketch. Especially since scaling up my project means I am putting thousands of plants at risk. Also, since this is my very first time programming anything, I am sure my sketch is full of mistakes.
This can be a complex area.

There is a whole "science" of test-driven-development or test-driven-programming. But it is probably much easier to use those techniques with a system (such as accounting) that exists entirely within the computer. Your system must also take account of the external world which can introduce all sorts of failures that are difficult to envisage.

I was reading (skimming might be a better word) about the early stages of computer control of railway signalling in Britain. Their system normally used 3 identical "computer modules" for every activity. If one of them disagreed with the others it was taken out of use. If the remaining 2 could not agree then the system shut down. That is probably overkill for your system - but it may give you some ideas.

I suggest you do a lot of thinking about how you would know if there is a failure and how you might detect that. And then you have to balance the cost of protection against the value of lost product. I don't think it would be easy (or indeed possible) to produce a system of software and hardware that was guaranteed not to fail. So rather than focus on a fault-free system I think it would be better to take a high-level look at how a failure of the system can be detected so that an alarm can be triggered. Then there is the question - what happens if the alarm system also fails ...

Of course I am not suggesting that you neglect building a reliable system to the best of your ability - there should be minimal reliance on the alarms

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

MonyetIblis

Thanks Robin for your answer.

I agree that alarms are a necessary part of such a setup. Having multiple redundant systems operating in parallel would be overkill. Unlike the British railway, we are not dealing with human lives.

In the world of automated irrigation there are a multitude of alarms for example to detect whether or not a valve is working, or if a pipeline has burst (high/low flow alarm) or if there is a fault in the fertilizer dosing (high/low pH & EC alarm). The existing irrigation system will be used, and thus most of these 'failure detection systems' will remain in place.

This is however not within the scope of the current stage of my project. My question was more aimed at the next step in going from a 'table-top' prototype to a real-world trial. Especially concerning the code of my sketch, and how one would go about getting it checked/improved.

Johan

Robin2

Jeez - I had a long reply written and it just vanished when I pressed POST :(    I will try again

Quote
Especially concerning the code of my sketch, and how one would go about getting it checked/improved.
If you are just focusing on your program code I suggest you study test-driven-programming as I suggested earlier.

You have not posted your program (and I am not offering to study it - I am poor at that sort of thing) so I don't know if it is well organized or if it is tangled spaghetti. Writing a program as a series of short single-purpose functions allows each part to be tested separately and also makes it easier to see the overall logic. Maybe have a look at Planning and Implementing a Program

You could get an expert to review your program but that would probably cost as much as getting him to write it in the first place. It may not be any more reliable but a professional would have insurance :)

Quote
This is however not within the scope of the current stage of my project.
I suggest you see your program as part of the wider scope and not separate from it.

My only "real-world" Arduino project is my fridge controller. It is very simple - too hot, turn on the motor, too cold turn it off. In development I could monitor its performance with an external thermometer. It has been working reliably for a few years now. It would be a real PITA if it failed and I lost the contents of the freezer compartment. But it would not bankrupt me. I think you need to view your project from a similar risk-assessment point of view - complexity and consequence.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

MonyetIblis

The link is indeed what I was looking for.

My code is a spaghetti... think I'll spend the coming weeks trying to improve it by following your tutorial.
I didn't want to post my code because I feel I should have an attempt at improving it myself first.

You are right, it is a balance between cost and benefit. Thankfully there are always people in the greenhouse that would be instantly aware of any problems.

Thanks again,
Johan

Go Up