A presentation I gave at the 2-day Workshop on Field and Assistive Robotics (WFAR'10) at Dagstuhl, Saarland, Germany.
The workshop was led by Prof. Dr. Karsten Berns and was attended by faculty and students from TU Kaiserslautern, University of Central Punjab, UET Lahore, LUMS and NED University.
The presentation describes the hardware architecture of two prototypes that have been developed by KFRL, NED University for Smart Irrigation System. This work is being done under the umbrella of DAAD funded project titled Water Resource Management (WaRM). WaRM is a collaboration between KFRL, NED University - based in Pakistan - and DFKI, which is based in Germany.
Navigating Complexity: The Role of Trusted Partners and VIAS3D in Dassault Sy...
Smart Irrigation System: Hardware Architecture for WaRM project
1. Smart Irrigation Systems:
Hardware Architecture
Muhammad Yaseen
(muhammad.yaseen@dfki.de, mohammadyaseen13@gmail.com)
Research Student, Koshish Foundation Research Lab
NED University of Engineering and Technology
Karachi, Pakistan
Intern, Knowledge Management Group
German Research Center for Artificial Intelligence (DFKI)
Kaiserslautern, Germany
10th Workshop on Field and Assistive Robots (WFAR-10) 1
2. Goal
10th Workshop on Field and Assistive Robots (WFAR-10) 2
To present the hardware (architecture of Wireless Sensor
Network nodes) designed for Water Resource Management
(WaRM) Project
3. Outline
• Crop Monitoring
• How?
• Why not go for off-the-shelf solutions?
• Hardware Architecture of Sensor Node
• Iteration 1
• Iteration 2
• Conclusion and Further Dimensions
10th Workshop on Field and Assistive Robots (WFAR-10) 3
4. Crop Monitoring: How?
10th Workshop on Field and Assistive Robots (WFAR-10) 4
A Farm in Gadap Town, Karachi, Pakistan
5. Crop Monitoring: Wireless Sensor Networks!
10th Workshop on Field and Assistive Robots (WFAR-10) 5
A Farm in Gadap Town, Karachi, Pakistan
6. Why not go for off-the-shelf solutions?
e.g. Libelium
• Smart Agriculture Node ranging from 375 €-550€
• Closed platform.
• We want to offer our own platform
10th Workshop on Field and Assistive Robots (WFAR-10) 6
7. Why not go for off-the-shelf solutions?
• Our long term objective is to develop a custom solution.
• Sensing
• Storage
• Machine Learning
• High Performance Computing Centre (HPCC) at CIS Department, NED
University can provide:
• Cloud storage
• Data visualization
• Machine Learning and Knowledge Management
10th Workshop on Field and Assistive Robots (WFAR-10) 7
8. Hardware Architecture of Sensor Node
Iteration 1
10th Workshop on Field and Assistive Robots (WFAR-10) 8
10. Iteration 1
10th Workshop on Field and Assistive Robots (WFAR-10) 10
• 4 Sensors
• Temperature
• Humidity
• Soil Moisture
• Light Intensity
11. Iteration 1: System Architecture
10th Workshop on Field and Assistive Robots (WFAR-10) 11
12. Iteration 1: Summary
• Arduino based nodes
• 4 Basic sensors: Temperature, Humidity, Soil Moisture, Light Intensity
• AM Radio for local communication.
10th Workshop on Field and Assistive Robots (WFAR-10) 12
13. Iteration 1: Summary
• Arduino based nodes
• 4 Basic sensors: Temperature, Humidity, Soil Moisture, Light Intensity
• AM Radio for local communication.
10th Workshop on Field and Assistive Robots (WFAR-10) 13
14. Iteration 1: Summary
• Arduino based nodes
• 4 Basic sensors: Temperature, Humidity, Soil Moisture, Light Intensity
• AM Radio for local communication.
10th Workshop on Field and Assistive Robots (WFAR-10) 14
15. Iteration 1: What we learned?
• Arduino – not a low power MCU
• Target battery life: Several months – 1 Year.
• Arduino Firmware is fine, but we need deeper level of control
• Task scheduling
• Power saving modes
• Need low power standards based protocols
• AM consumes too much power
• Problems with Scalability, PAN, Healing…
• Need an integrated solution
• Signal level mismatches (3.3V, 5V), incompatible communication interfaces…
10th Workshop on Field and Assistive Robots (WFAR-10) 15
16. Iteration 1: What we learned?
• Arduino – not a low power MCU
• Target battery life: Several months – 1 Year.
• Arduino Firmware is fine, but we need deeper level of control
• Task scheduling
• Power saving modes
• Need low power standards based protocols
• AM consumes too much power
• Problems with Scalability, PAN, Healing…
• Need an integrated solution
• Signal level mismatches (3.3V, 5V), incompatible communication interfaces…
10th Workshop on Field and Assistive Robots (WFAR-10) 16
17. Iteration 1: What we learned?
• Arduino – not a low power MCU
• Target battery life: Several months – 1 Year.
• Arduino Firmware is fine, but we need deeper level of control
• Task scheduling
• Power saving modes
• Need low power standards based protocols
• AM consumes too much power
• Problems with Scalability, PAN, Healing…
• Need an integrated solution
• Signal level mismatches (3.3V, 5V), incompatible communication interfaces…
10th Workshop on Field and Assistive Robots (WFAR-10) 17
18. Iteration 1: What we learned?
• Arduino – not a low power MCU
• Target battery life: Several months – 1 Year.
• Arduino Firmware is fine, but we need deeper level of control
• Task scheduling
• Power saving modes
• Need low power standards based protocols
• AM consumes too much power
• Problems with Scalability, PAN, Healing…
• Need an integrated solution
• Signal level mismatches (3.3V, 5V), incompatible communication interfaces…
10th Workshop on Field and Assistive Robots (WFAR-10) 18
19. Hardware Architecture of Sensor Node
Iteration 2
10th Workshop on Field and Assistive Robots (WFAR-10) 19
20. Iteration 2: System Architecture
2010th Workshop on Field and Assistive Robots (WFAR-10)
21. Iteration 2: System Architecture
2110th Workshop on Field and Assistive Robots (WFAR-10)
22. Iteration 2: System Architecture
2210th Workshop on Field and Assistive Robots (WFAR-10)
23. Iteration 2: System Architecture
2310th Workshop on Field and Assistive Robots (WFAR-10)
25. Iteration 2: Summary
• Exploring APIs and SDKs (BLE Protocol Stack, RTOS)
• Schematic design and PCB layout completed
• …now, evaluating quotations from PCB manufacturers
• Best quote so far: 225 € per piece (1 Main Board + 1 Sensor Board)
10th Workshop on Field and Assistive Robots (WFAR-10) 25
26. Iteration 2: Summary
• Exploring APIs and SDKs (BLE Protocol Stack, RTOS)
• Schematic design and PCB layout completed
• …now, evaluating quotations from PCB manufacturers
• Best quote so far: 225 € per piece (1 Main Board + 1 Sensor Board)
10th Workshop on Field and Assistive Robots (WFAR-10) 26
27. Iteration 2: Summary
• Exploring APIs and SDKs (BLE Protocol Stack, RTOS)
• Schematic design and PCB layout completed
• …now, evaluating quotations from PCB manufacturers
• Best quote so far: 225 € per piece (1 Main Board + 1 Sensor Board)
10th Workshop on Field and Assistive Robots (WFAR-10) 27
28. Iter. 1 vs Iter. 2: Problems and Solutions
Low Level Device Control Thread level control, Task scheduling
10th Workshop on Field and Assistive Robots (WFAR-10) 28
29. Iter. 1 vs Iter. 2: Problems and Solutions
Low Level Device Control
Low Power MCU
Thread level control, Task scheduling
CC2650: Purpose Built Low Power SoC
10th Workshop on Field and Assistive Robots (WFAR-10) 29
30. Iter. 1 vs Iter. 2: Problems and Solutions
Low Level Device Control
Low Power MCU
Standards based, low power protocols
Thread level control, Task scheduling
CC2650: Purpose Built Low Power SoC
We get 3:
10th Workshop on Field and Assistive Robots (WFAR-10) 30
31. Iter. 1 vs Iter. 2: Problems and Solutions
Low Level Device Control
Low Power MCU
Standards based, low power protocols
Integrated System
Thread level control, Task scheduling
CC2650: Purpose Built Low Power SoC
We get 3:
MCU and RF in one SoC
10th Workshop on Field and Assistive Robots (WFAR-10) 31
32. Conclusion and Further Dimensions
Objective
Develop a platform for WSN and IoT projects
10th Workshop on Field and Assistive Robots (WFAR-10) 32
33. Conclusion and Further Dimensions
Further Dimensions
• Port the code for ZigBee networks (TI Z-Stack API)
• Test basic ML models on the WSN node
• Integration with Cloud service, and developing an API
10th Workshop on Field and Assistive Robots (WFAR-10) 33
Hello everyone! My name is Muhammad Yaseen, and the topic I’ll talk about today is Smart Irrigation Systems. Specifically, I will focusing more on the hardware design perspective. I am an Undergrad Research Student at Koshish Foundation Research Lab at NED University, Karachi. I am here on an internship at DFKI in the Knowledge Management Group where I’m working with Dr Saqib Bukhari on the Water Resource management project. So, let’s start…
The objective of today’s presentation is to describe the work we have done on the hardware side. And to discuss the designs we have developed for warm project. … So I hope the scope of presentation is clear now. Let’s see the outline.
So the first thing is… how are we going to monitor the crop parameters. There are many challenges here, and the NEXT presentation will address some of those challenges in details.. Some obvious questions we can ask are… “what crop parameters are important”, “what do the sensor values means, the interpretation of readings…”.But here I will talk about the hardware aspect. So, that once you have decided you want to monitor parameter X and parameter Y.. How are you going to do it… I will also talk about our motivation to develop our own solution and why we didn’t want to go for off the shelf solutions…
Secondly, we delve into technical details and talk about controllers and sensors. I will discuss two Iterations, or you can say prototype 1 an prototype 2. Finally, I will conclude the presentation by talking about our future goals, and the work we are planning to do with designed nodes. So, let’s start with ‘Crop Monitoring’
So, again here is the crop you’d like to monitor. How are you going to do it?
The most promising solution we found was to use Wireless Sensors Networks or WSNs for short.
The WSNs are getting a lot of attention these days because of the popularity of Internet of Things.
This brings us to our first prototype.
It is an Arduino based system. You can also see a picture of prototype in a box. So we have arduino board, and radios, there is also a humidity sensor.
In this version we used simple AM radios for communication.
Once we have the sensor values, we want to send these value to a central station for storage and decision making... AM radios are used for that. We are using ThingSpeak cloud service to store our data. It also provides some basic graphing and visualization capability and APIs.
Let’s take a look at the sensors now…
We have used 4 different sensors in this version.
You can see in the picture.. We have soil moisture sensors at different levels, underground and external temperature sensors.. And the humidity sensor which you saw in last slide..
These happen to be the key parameters in determining the water usage, as you will see in the NEXT presentation.
…and here is a block diagram of the architecture.
Arduino communicates with the radios and the sensors and the radio transmits the sensor data.
Now to summarize… In our first prototype we have… An arduino based nodes
3 basic sensors: temperature, humidity and soil moisture..
and AM radios for communication…
Now, I’d like to talk about what we learned from this exercise..
First, Arduino was NOT designed for low power applications. It doesn’t work well for applications where you are targeting very long battery life.. Like several months … or even a year.
Arduino firmware helps to rapidly develop the system… but problems arise when you want more deeper level of control.. If you want to control peripherals, task scheduling and different power saving modes.
The firmware gets in the way.
AM consumes too much power.
Also, while it is simple, it is not scalable.
There is a lack of more advanced features like routing, personal area networks and advanced power saving features.
AM won’t work for low power long battery life applications.
There were problems like… differing voltage levels, different current ratings and power requirements. It isn’t very feasible from an architectural point of view and adds to the hassle.
Now, these are all the things we learned from our first prototype, and we have addressed all these issues in our next prototype..
So Now let’s take a look at the second iteration..
The first thing to notice is that now there is this big gray box instead of different blocks for Radio and Controller… So what does this mean? In the second version of prototype, we have used a system on chip. Specifically, a cc2650 SoC.
Now, What does this SoC offers us?
As you can see, now we have the Radio and controller both on the same chip.. Also, we now have a Cortex m3 processor, which is a great improvement over arduino.
Another important thing is that this SoC provides RF frontend for 3 major wireless technologies..
So the SoC supports Bluetooth, ZigBee and 6LoWPAN.. This offers a lot of flexibility.
As you can see, this system is much more complex than simple arduino system, where all we had to do was connect some wires and write some libraries for interfacing..
Here we have to deal with the protocol stack and APIs. So clearly there is a lot of complexity.
This is where the Real Time OS comes into play..
It provides APIs for protocol stacks and also allows thread level control over execution. Just what we wanted.
Here you can see the PCB layout for Second prototype…
We have completed the schematic and layout and are now moving to fabricate the design.
Here’s the summary of all the work we have done in our second iteration…
We explored the Apis and SDKs.
We designed sensor board and controller boards based on cc2650 SoC
And now we are evaluating quotes from different fab houses.. The best we have got so far is 225 Euro, per piece.. That includes 1 sensor board and one controller board.
So up to this point, we have a sensor network, and are capable of receiving data from the field.
The next step is to interpret this data and identify meaningful parameters and their functions for decision making…
This is what will be discussed in the next presentation.
Thank You!
