Difference between revisions of "S14: Smart Planter"
Proj user19 (talk | contribs) (→Software Design) |
Proj user19 (talk | contribs) (→Software Design) |
||
| Line 197: | Line 197: | ||
=== Software Design === | === Software Design === | ||
The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows: | The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows: | ||
| − | while (1) | + | |
| + | while (1) | ||
get current time | get current time | ||
send the last time plant was watered to first line of LCD | send the last time plant was watered to first line of LCD | ||
Revision as of 23:14, 22 May 2014
Contents
Project Title
Smart Planter
Abstract
Most people don’t have the time in the day to remember to water a plant. When they do have a moment to water the plant, they over-water therefore wasting resources and hurting the plant. The solution is a system that takes in data on the moisture of the soil, temperature, and humidity of the environment to decide when to pump the necessary water resource accordingly.
Objectives & Introduction
This system will be achieved using two different types of sensors: the first will be a soil hygrometer inserted into the bottom of the plant to detect the amount of water the plant currently possesses in its soil. This will be the highest priority in determining whether the plant needs additional water. The second sensor is a combination of humidity and temperature sensor attached to a peg (for security and to keep the wires safe) that will relay the data back to the SJSUONE board. In order to conserve energy, the system will collect data twice a day (8 am and 3:30 pm) to determine how much water needs to be released. A real-time clock along with an alarm timer will be used to determine when to trigger the sensors and collect data. In addition, a push-button will be implemented as an alternate way to activate the sensors to check if the plant needs to be watered. It will only water the plant if the algorithm determines that the plant needs to be watered to prevent drowning the plant. A drip system was chosen because this method has shown it is the most effective in not wasting water as opposed to a spray sprinkler system that loses more water to evaporation. Finally, information including the last time checked, the temperature at this time, soil moisture, and the watered time will be displayed on an LCD screen for the user to view.
Team Members & Responsibilities
- Carissa Labriola
- Driver Development for sensors, Peripheral Device Hardware Integration, Software Layout, Wikipedia Documentation
- Sovist Thou
- LCD Driver Display, DC Motor Control, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
- Leeladithya Avala
- FreeRTOS Software Design, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
Schedule
| Week# | Date | Task | Description |
|---|---|---|---|
| 1 | 3/23 | Research and order parts | A total of 6 hours were spent researching which parts would fit into the project such as the right DC motor, a dependable hygrometer (many corrode too quickly), an accurate temperature sensor, an LCD screen that isn't too big and doesn't need more than 12V, etc. |
| 2 | 3/30 | Write drivers for peripherals and environment | Initial FreeRTOS environment complete, peripherals started |
| 3 | 4/6 | Finish hardware set up, continue peripherals | Hardware set-up for individual modules, LCD screen progress, |
| 4 | 4/13 | Finish drivers and FreeRTOS environment | LCD screen, DHT22 drivers, DC motor control complete |
| 5 | 4/20 | Test and Edit environment | DHT22 still experiencing issues, hygrometer complete, Motor module complete, adding modules to FreeRTOS |
| 6 | 5/3 | Continue Testing | DHT22 still experiencing issues, assembly of protoboard begins |
| 7 | 5/10 | Continue Testing | Moving to on-board temperature sensor, compiling individual modules into main environment, implemented push button logic
Troubleshooting of protoboard connections |
| 8 | 5/17 | Final testing and set up | All modules added to environment and protoboard, last fine tuning of software and hardware |
| 9 | 5/21 | Demo | Complete |
Parts List & Cost
| Item | Description | Qty | Unit Cost | Total Cost | Source |
|---|---|---|---|---|---|
| 1 | Hygrometer | 1 | $6.00 | $6.00 | http://www.amazon.com/gp/product/B00CKWMLC6/ |
| 2 | 7mm Silicon Tubing | 1 | $8.00 | $8.00 | http://www.amazon.com/gp/product/B0094FZCIW/ |
| 3 | Submersible Water Pump | 1 | $15.00 | $15.00 | http://www.amazon.com/gp/product/B007XHZ25G/ |
| 4 | LCD Screen | 1 | $25.00 | $25.00 | http://www.newhavendisplay.com/lcd-character-4-x-20-characters-c-2_87.html |
| 5 | Plant Pot | 1 | $2.00 | $2.00 | Orchard Supple Hardware |
| 6 | Water Basin | 1 | $4.00 | $4.00 | Target |
| 7 | Plant | 1 | $3.00 | $3.00 | Trader Joe's |
| 8 | Temperature And Humidity Measurement Sensor | 1 | $7.00 | $7.00 | http://amzn.com/B00CDHH3WQ |
| 9 | Protoboard | 1 | $5.00 | $5.00 | RadioShack |
| 10 | Misc Components (And gate SN1708, DC Jack, Power Regulator LM7805, N-Channel MOSFET NTD5865N) | 1 | $5.00 | $5.00 | HSC |
| 11 | SJSUONE Board | 1 | $80.00 | $80.00 | HSC |
|
Total |
$160.00 |
Design & Implementation
Hardware Design
The hardware for the project was broken down by the needs of the different sensors. To have the design function as expected, the team required circuitry to provide the appropriate power to each peripheral as well as the microcontroller. The Basic System Design, shown in the figure below, shows how each component was laid out onto the base board. The LCD, SJSUONE board, and prototype board is set inside a clear box to protect the circuitry from any water spills and allows viewing of the embedded design. The prototype board was used to build the circuitry, including the power unit for the system so that there could be a 12V and 5V power rail supplied by a 12 DCV wall supply, a ground rail, as well as a 3.3V rail supplied by the SJSUONE's Vout pin. The water supply includes a submersible DC water pump that sits at the bottom of the bucket since it is not self-priming and needs to be completely submerged to avoid damage. The silicon tubing coming out of the bucket is fed to the plant' s soil as a drip system. A single push button was implemented to allow the user to check the parameters at any given time in the day while not allowing them to over-water the plant.
The Figure below shows the circuit design for our system. Not shown in the circuit box is the DC motor.
Hardware Interface
Each of the peripherals utilized a different type of BUS communication. The soil hygrometer works by sending voltage through the pegs, measures the resistance between them, a value dependent on the moisture level, and translates this information into an analog output. Therefore, the pin is attached to one of the analog to digital pins on the board in order to translate the signal into a number that will determine the appropriate level. While the original intent for the project was to use the DHT22 temperature/humidity sensor, the protocol was more complicated than initially anticipated so the sensor was exchanged for the on-board I2C sensor. Since significant strides were made in the development of the DHT driver, its description has been included. The DHT22 utilizes a custom single-line open collector communication BUS connected to +5V, ground, and a 10kohm resister connected from voltage to the communication pin to pull it high. The sensor waits for the microcontroller to pull the line low for 1-20ms, then pulls the line actively high for 20-40us. The microcontroller then needs to switch to an input to receive the acknowledge signal followed by 40 bits. The bits are determined 0 or 1 by the length of how long the particular segment of data is high or low. The sensor needs to wait 2s in between reads and critical read times need to be protected from being interrupted in order to be successful.
The DC motor is a food-safe motor that takes +10-12DCV and has two inputs: the voltage and an active high signal that needs to be ~+3-5V to turn on the motor. This system was set up by attaching a GPIO pin located on the SJSUONE board to the input of a SN1708 AND gate with a high signal on the second input. This results in the AND gate outputting a high signal of +5V which is enough to activate the motor. An important note for the hardware implementation of the motor control is the use of zener diode 1N4001 to regulate feedback current to protect the MOSFET from blowing out. When the DC motor powers down, a high reverse voltage spikes back and could potentially damage the mosfet.
The LCD screen has an onboard controller or "backpack" that is capable of selecting different communication protocols (UART, I2C, and SPI). For this project, SPI (Serial Peripheral interface) was chosen as the appropriate communication for its simplicity and speed. To use the LCD in SPI mode, the SJSUONE board acts as a master providing SCLK (clock), display data to the LCD through MOSI data line, and SS (chip select). The chip select is used to start and end a transmission frame while in the process enabling the writing of data to the LCD. The LCD acts as a slave and only reads data sent by the microcontroller. Though the SPI bus works as an exchange protocol where a data byte is sent to receive a data byte, the MISO (slave output data) was ignored since the data sent by the LCD are not of interest.
Software Design
The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows:
while (1) get current time send the last time plant was watered to first line of LCD send the last temperature read to the second line of the LCD send the last soil moisture read to the third line of the LCD send the current time to the fourth line of the LCD delay loop for 50ms
The check reading task, when activated, updates the temperature and soil moisture and fetches the current time. If the moisture level, which ranges from ~14-50 is below 20 or the temperature is above 90*F, then the motor is activated for three seconds and the time last watered is updated. The motor is activated for two seconds is the temperature is between 80*F and 90*F or is the moisture level is less than 30. The motor is activated for one second if the temperature is between 70*F and 80*F or the moisture is below 40. If it does not fit into these parameters, than the plant is deemed to not need water and the power is not powered nor is the time watered updated.
The individual drivers for the peripherals will be described in the implementation section.
Implementation
Since the overall system code has already been detailed, this section will be focusing on the software implementation of each of the peripherals.
Temperature/Humidity Sensor: The temperature/humidity sensor DHT22 utilizes the tri-state properties of the open collector to operate. The microcontroller must first set up a single pin as an open collector GPIO with an output pulled high. Only when the user requests data does the pin pull low for 20ms the pull high actively for 40us. The pin then needs to switch to being an external interrupt pin activated on both the falling edge to capture the start of the acknowledge as well as start a protected time from the interrupts of the FreeRTOS. When the edge is triggered, a timer will start counting such that if the rising edge trigger is not found within 100us then there is a timeout on the acknowledge indicating an error. Else the interrupt again looks for the incoming 40 bits that represent 16 bits of humidity, 16 bits of temperature, and 8 bits of check sum. The counter for the bits is such that at the positive edge of a high the count is started and ends when the negative edge is triggered. If the counter is 26-28us, then the bit is considered a '0'. If the counter is 70us, then the bit is considered a '1'. The bits are concatenated accordingly for the humidity, temperature, and check sum and if the data compared appropriately with the check sum then the read is considered successful. If called, the data for the temperature can be converted into *F since it comes as *C.
I2C Temperature Sensor: The I2C sensor had the driver pre-written and verified to be working, but we had to have a working understanding of how it works. The particular process needed for this sensor was a read command. For this command to work, the microcontroller, acting as master, sent a start signal over the data line with the slave address. Using the SCLK to stay synchronized, the sensor sent back an acknowledge signal. The start signal was sent again with an off address and after the second acknowledge was confirmed the read signal was sent, which places the sensor's data into a buffer. The buffer was then sent in a 16-bit package over the line back to the master, converted into degrees in Celsius and then converted again into Fahrenheit degrees.
Hygrometer: The majority of the hygrometer data is processed through the hardware, since the analog signal is put into the Analog to Digital converter pin. Therefore, the pin must be set to it's ADC setting as an input pin. When the pin needs to be read, the BURST bit is set to start communications, a while loop waits until bit 31 is set to indicate transfer complete, and the data is transferred into an declared integer.
RTC: The Real-Time Clock needs to be set in order for the alarms to be effective. Therefore the RTC header needs to be included in the main program, the initialize function called, and there needs to be a declaration of type rtc_t so that the program has it's own time parameters that can update the clock time and date for the local program and the actual RTC.
DC Motor: The DC motor involves setting a pin to be a GPIO, setting it to be an output and pulling the line low. When the motor is to be activated, the pin is driven high, taking in as input the amount of time to delay in milliseconds before pulling the line low again.
LCD Screen: To operate the LCD, the LCD data sheet details commands that can be deciphered by the LCD controller to perform specific functions such as a write to line one of the LCD. To perform this write to line one of the LCD, the following must take place in software: 1) Chip select is turned on to select the device. 2) Send the function command to the LCD. In this case a write of hex 0xFE followed by 0x45 and 0x00 sets the cursor position to line one of the LCD. 3) Send the text to be displayed to the LCD. 4) Deactivate chip select to complete an operation. The controller reads character commands therefore the text and the command itself is sent to the LCD through a character byte exchange function. In the project software design each line of the 4 line LCD has its own unique write function and message created with the procedure described. The function receives input information from the real time clock and sensors then displays the information in real time.
Testing & Technical Challenges
For testing this project, each of the sub-modules was completed individually and then compiled together to work in unison. The temperature/humidity sensor required the majority of the debugging time since it utilizes microsecond-precision in transferring the data. Across the board, the team found that when testing that making a separate project folder just for testing sub-modules made the debugging process more efficient. The team's procedure was to write the drivers for each of the devices with their own test code then one by one start to integrate each one into a main test program. Starting with the hygrometer being placed into the FreeRTOS frame, a button interrupt was integrated. Once this procedure was successful, the temperature sensor's input was added in. This was followed by the integration of the motor pump and lastly the LCD screen. The issues that were encountered along the testing procedure can be seen below:
Temperature Sensor Issues #1
While the documentation for the DHT22 temperature sensor says that the minimum voltage level is 3.3V and the board is supposed to output 3.3V, in reality this does not work. This was found to be a combination of the sensor really needing +5V to work properly and the board was found to only output 3.2V (tested using a multimeter). The fix for the issue was to alter the power line portion of the circuitry such that we now have the initial +12V set up to drive the DC motor then a +5V line for the microcontroller and the temperature/humidity sensor to connect to for power.
Temperature Sensor Issues #2
The first issue encountered was in writing the driver for the temperature and humidity sensor. The DHT22 works off of a single line for data transfer using the tri-state of an open collector to send start and acknowledge signals back and forth between the microcontroller and the device. The timing for sending the data is down to the microseconds so the driver timing has to be very precise or data would be missed. Hours were spent debugging a delay-based version that would hang while waiting for the end of the acknowledge from the sensor. In the end, time was running out for the DHT22 module was abandoned in favor of the I2C based temperature sensor on the board.
Hygrometer Issue #1
Programming the analog signal from the hygrometer sensor required a little research and debugging. Since this type of communication had not been experimented with before, it took a few hours completely of research to make sure that all of the correct bits were being set but ultimately this extra time spent double checking all of the inputs meant only a few trials on the board before it worked successfully.
LCD Issue #1
Initially, when sending a byte of data (command functions) to the LCD, the byte would be displayed on the LCD in ASCII representation rather than performing the operation such as setting a cursor on. This was noticed when a closer look was taken at the binary representation of the displayed character within the data sheet. The byte was taken as a literal write data rather than actually being read as a hex command. This was an occurrence that was unexplained online when researching for a solution. In search of a solution, multiple experiments with the LCD were conducted. It was found that while sending the clear hex command in a loop, the hex command at some point reads as an operation and clears the screen rather than be displayed as a literal. After consulting a generic LCD data sheet, it was soon discovered that in most cases an LCD controller needs a delay of 100ms after the chip select is on to synch the transmission frame for SPI. Once this delay was placed inside the software a simple clear command would take place. The following issue was how to send long messages written in continual byte streams rather than single byte characters.The solution was to create a function that would leverage our single exchangeByte function with another function that could write the Byte as a string. The lesson of this issue is to always buy products that are well documented.
DC Motor Issue #1
During the initial implementation phase of the motor control on a breadboard, the input signal voltage to drive the MOSFET to activate the DC motor was +3.3V. The DC motor control software was tested multiple times to validate the correctness of the software. However, when a final implementation of the DC motor control circuit was made on a prototype board, the DC motor would not turn on with the same software. After multiple tests, the DC motor would not function consistently until it no longer activated completely. After thorough testing with a multimeter and monitoring the voltage levels of the MOSFET, it was found out that the mosfet needed +5V to drive the DC motor. This posed an issue as the microcontroller GPIO pin can only output +3.3V max. As a solution we used an AND gate as a signal driver, using its output logic at +5V to drive our DC motor. The troubleshooting for this issue was an incredible task as the issue was neither in software nor hardware implementation but an internal change in the MOSFET that was not seen to the testers.
Water container #1
The plastic water container for the project needed to have two holes drilled in for the silicon tubing and the wires for the DC motor. While the sealing for the silicon tubing held up, the wires produced a small leak, which became a hazard around all of the electronics. The solution for this issue was to add more hot glue whenever a drip was noticed and to seal both sides of the hole for extra support. As a result the container is now successfully sealed.
Conclusion
The Smart Planter utilized a breadth of knowledge acquired in the embedded systems course to become successful. This included implementing I2C, SPI, GPIO, FreeRTOS, interrupts, Real-Time Clock alarms, analog-to-digital conversions, single line communications, and DC motors. Clean hardware implementation was reinforced as well as proper use of voltage regulators, MOSFETs, and setting up power lines. In the software portion of the project an understanding of interacting tasks and being conscious of the real-time operation was invaluable to the success of the project. How to troubleshoot problems across software and hardware modules was also an important learning lesson in this project. Being able to identify a problem, such as why the time function isn't updating on the LCD screen, and following the logic of the code to discover the RTC gettime function was not properly implemented, is an important skill to cultivate in engineering since the ones encountered in this project are minor compared to industry issues. All of these technical experience was combined with the soft skills of division of labor, communication across a team, time management with other on-going projects, and verbal and written explanation of technical concepts. A few improvements could have been made: for example, a water level sensor could have been added to the water tank so that if the water level got too low then the user could be warned, especially since the motor is damaged if it tries to run without water. A battery for the RTC would also be nice since currently it is reset to a specified time and date every time it loses power. Had there been more time, a wireless connection to receive weather predictions from weather.com would have been a nice addition for the plant that the tea did not have time to implement as an extra. Overall, this project was abundant in learning opportunities for the entire team so while the concept of the project was simple there was still plenty of valuable knowledge to gathered and problem solving to be had.
Project Video
Upload a video of your project and post the link here.
Project Source Code
Send me your zipped source code and I will upload this to SourceForge and link it for you.
References
Acknowledgement
Thank you to Carlos Fernandez-Martinez for providing parts and advice, Professor Ozemek for changing our lifestyles, and to Preet for providing a solid background in FreeRTOS and drivers so we could complete everything!
References Used
Humidity Sensor AM2302 Datasheet http://www.adafruit.com/datasheets/Digital%20humidity%20and%20temperature%20sensor%20AM2302.pdf
Humidity Sensor AM2302 / DHT22 Usage Reference http://blog.ringerc.id.au/2012/01/using-rht03-aliases-rht-22.html
LCD Datasheet http://www.newhavendisplay.com/specs/NHD-0420DZ-FSB-GBW.pdf
DC Motor Control With MOSFET Reference http://bildr.org/2012/03/rfp30n06le-arduino/
LPC1758 User Manual
LPC1758 Hardware schematics
Socialledge I2C tutorial
Appendix
You can list the references you used.
