Six Questions to Answer When Scoping an Arduino-Based Irrigation Project

Note: This article is part of series which includes these articles:

• Part 1 - Six Questions to Answer When Scoping an Arduino-Based Irrigation Project
• Part 2 - Careful Sensor Selection Ensures Desirable – and Avoids Undesirable – Outcomes
• Part 3 - Communication Considerations for Distributed Control Applications

Scoping a project involves finding a delicate balance between many often competing requirements. This article, the first in a multi-part series, presents an overview for scoping an irrigation project because it involves asking and answering the same types of questions needed to scope almost any project that interacts with its environment using sensors and actuators.

There are six main questions that must be answered for any such project:

1. What are the project specific issues and constraints, including fault tolerance?
2. Which processor platforms will satisfy the project requirements?
3. What types of sensors should be used?
4. What types of actuators are appropriate?
5. What communication capabilities are necessary?
6. What are the power management needs?

Irrigation is the artificial delivery of water to an area, usually to grow plants. How to create efficient watering systems has challenged mankind since we sowed our first seeds. Agriculture irrigation projects must maximize the benefit they extract from the water that they use because they compete with industry and urban users for scarce fresh-water resources, especially during periods of drought. Fortunately, the opportunity to improve the efficiency of watering systems continues to expand as technology advances.

The options are numerous for using electronic instrumentation and controls to improve the efficiency of watering projects. The most significant constraints that drive what options are appropriate for an irrigation project are the source of the water and the size and location of the target watering area relative to that source. Target watering areas broadly cover small box gardens, medium bed gardens, and larger crop plots. The sources of water split between self-replenishing reservoirs and static reservoirs that the project needs to arrange to explicitly refill in some manner.

The project can start with a smaller, basic sensing and control unit that might be usable in each of these target contexts. However, the project operates with and around water, so there is also a need to protect the electronics in a watertight enclosure because the unit needs to be able to continue working even if it is misted or covered in water during its operational life.

Processor platforms

The processor platform forms the heart of most projects. As a result, there is a wide range of processor platforms available to designers, such as Arduino and Beagleboard, which offer a range of options from small, energy-sipping 8-bit processors to higher-performance 32-bit options to best fit the requirements of any project. These platforms feature processors with various memory options, clock speeds, and board form factors supplied from a variety of processor and board manufacturers, such as Atmel, Texas Instruments, and Sparkfun Electronics.

Figure 1: The 3.3 V Arduino Pro Mini delivers flexibility in a small form factor

A good example to work from is the Sparkfun Electronics DEV-11114 Arduino Pro Mini 328 - 3.3V/8MHz Development Board. This is a variant of Arduino open-source hardware that is good for fitting into tiny water-tight enclosures (Figure 1). Using the board does require some soldering, but the joints are easy through-hole jobs. The 18 x 33 mm board is about one-sixth (1/6) the size of the Arduino Uno, so it is not physically compatible with Arduino shields, but it can be wired to any Arduino shield (Figure 2).

Figure 2: The Arduino Pro Mini (foreground) is about one-sixth the size of the Arduino Uno (background, faded) making it great for projects that need to fit into tiny enclosures.

The Pro Mini uses an ATmega328 running at 8 MHz with an external resonator (0.5% tolerance). The board has a 3.3 V regulator and can handle DC input 3.3 V up to 12 V. It includes eight (8) analog pins and fourteen (14) digital I/Os. In order to make this board so small, there is no USB circuitry included which means an external component, the FTDI Breakout, is required to upload code to the board.

More than humidity sensors

The project needs sensors for detecting humidity or moisture in the soil. This could be just a few humidity sensors when targeting a box garden, with the number of sensors increasing along with the size of the garden. The humidity sensors might need to be placed in both shallow and deep locations under the surface of the soil to ensure that water is delivered optimally for the target plants. Temperature and light sensors can help the system better time the delivery of water based on environmental conditions.

Less obvious sensors, which grow in importance as the garden size increases for fault detection reasons, are those that provide feedback about the operation of the system to the controller. For example, pressure sensors can be used as feedback to enable the controller to detect whether or not water is flowing when and where expected. A flow meter can provide detection and verification of how much water is being delivered in use cases where a water reservoir supply might run low on water inventory, as well as detect obstruction and leaks in the water delivery system. Sufficient fault detection can prevent the irrigation system from wasting water or allowing plants to die that destroys the value of using the system.

Fail-close actuators

The type of water source and power constraints will need to be factored in when determining the appropriate actuators for the irrigation system. There are two main categories of water sources: those that require a pump, and those that can rely on opening and closing a valve. A water reservoir that requires operating a motor to pump, such as a ground-level reservoir, and deliver the water to the plants is going to consume a lot more power than systems that can rely on just opening and closing valves. To save even more power during operation, the system might be able to use latching valves that only consume power when switching between open and closed positions.

There is a possibility the irrigation system can overwater if it loses power during a watering operation. A pump-based water delivery system is a natural fail-close system because if it loses power, the pump stops operating and water stops flowing. On the other hand, a latching, valve-based water delivery system could lose power with the valve in the open position, and so would continue to deliver water until power is restored. This is a good reason to use active solenoids. They do consume power during operation, but fail in a closed-valve position. If saving power is highly valued, say when using an energy-harvesting approach for power management, the system could use extra circuitry that can locally store enough energy to latch a valve to the closed position not only during normal operation, but in the event of a loss of power.

Communication

Ideally an irrigation system can operate autonomously most of the time. That said, it is likely that both the environment and target plants the system services will undergo significant changes over time. As a result, the system needs the ability to configure, command, and query. Water delivery is a “distributed” problem, so the ability to communicate with all of the modules that make up the irrigation system is critical.

As the system expands, supporting wireless communication becomes a necessity, especially when irrigation controller enclosures need to be water-tight or the size of the garden increases beyond a simple indoor box. The system’s power requirements affect the choices for wireless communication options, especially if it relies on energy harvesting for power. Using an Arduino Wi-Fi shield incurs a large consumption of power that may not support frequent communication. To consume less power, irrigation projects may be wise to opt for a sub-1GHz radio.

The need for central versus local control and feedback for the system is another reason to have distributed communication capabilities. The ability to collect data from each node in a central location makes fault detection and correction faster and easier than having to visit each node physically.

Power management

While the central controller for an irrigation system might be connected to tethered power, it is almost certain that the distributed, remote, modules will rely on rechargeable batteries and energy-harvesting techniques. Solar panels not only offer the most mature option for energy harvesting, but are the most relevant for collecting energy when the system needs watering the most. Water delivery, under most circumstance, is needed more during dry and sunny conditions, which are obviously more ideal for collecting solar power.

The most important design consideration for power management for the energy-harvesting nodes is how to extend the battery life. This system might accomplish this through less frequent waking from sleep modes, simpler and less frequent communication, or even offloading processing or communication to another device, via NFC (near field communication) devices or cell phones.

Conclusion

An in-depth examination of the trade-offs for each of these categories of questions is beyond the scope of this article. Instead, future articles will tackle each category separately with specific components identified, while continuing to use the irrigation example. This will provide continuity that usefully captures and shares lessons learned by other makers and designers that are working with irrigation systems.

What should be clear though from this exercise of considering an irrigation project is that the design must consider not only the primary functions that must be performed but also what actions and conditions must be avoided. Each specific circumstance that must be avoided causes requirements to ripple into the other portions of the design. Nothing can be an isolated island. In fact, a significant portion of a design effort is consumed by making sure the system does not do what it is not supposed to do.