In the upcoming age of the next generation internet, Wireless Sensor Networks are something with the potential to seriously influence the way we perceive the universe. With connectivity to the Internet of Things, WSN's can help us predict and monitor events from a remote locations. at various degrees of autonomy these WSN's pose interesting challenges in terms of routing algorithm design, protocols, network topology and even the core design of the sensor nodes themselves.
A major concern in WSN design is fault tolerance. WSN nodes may deployed in obscure locations and are generally not touched for months maybe even years. In such a case fault tolerance within the network is an important design parameter. A case in point is the WSN deployment in the Swiss Alps, where a fault manifested in the network in the form of clock drift at dawn and dusk, leading to loss of synchronization.
Talking about Fault Tolerance, I read a paper titled "A Two-Tier Data Dissemination Model for Large-scale Wireless Sensor Networks ". This paper talks about a data dissemination technique for efficient routing in large scale Wireless Sensor Networks. It also handles mobile data sinks as long as the source of data is static. Basically a virtual grid is set up by the source within the WSN and queries and responses travel along this grid.
A small issue with this method was that it proposes only one "upstream node" for every node, hence a unique path from the source to every node in the grid. Hence when a node fails, or a cluster of nodes fails, we might have to set up a major portion of the grid leading to increased traffic in the network. I studied this paper as a part of the "Embedded Systems Design" course, (Anyone from BITS Pilani will know exactly what I am talking about :P). As a solution I thought of using priority queuing and storing alternate redundant paths from the source to every node in the grid. This will not require the added cost involved with centralization in the network but at the same time will introduce fault tolerance in the sense that a path with lesser priority can be used in case of a fault.
The ideas that went into this are presented here in the form of a paper.
We haven't yet implemented these ideas in simulation or otherwise, but I would really appreciate anyone's views on these before I implement the same.
Sunday, February 5, 2012
Tuesday, January 31, 2012
A walk down the field, and along memory lane
I blogged (about a year ago :P) about work at CEERI Pilani, India.
Here is a follow up to that. It was a genuine dream to build a farm robot, I believed that it could actually contribute to a country like India. Moreover it is a serious technical challenge to any engineer, and brings to the forefront some very tough problems in embedded systems, computer vision, robotics and control theory. My continuing obsession with the "3 C's" has always kept me revisiting these problems sometimes through coding or circuit design, or some times as pure idle thoughts. "Sit back and reflect", as the great Hercule Poirot says. Admittedly these idle reflections have taught me a lot and I believe widened my perspective to an extent. I feel its really enriching to try and imagine all the pitfalls that one's design might get trapped into. A good designer I believe, can not only correct design flaws, but also predict and prevent them.
Following is an abstract of the project
"Identification of plant disease is of paramount importance in the greenhouse and plant wilting is a primary cause for loss of revenue in the industry. The need for an automated feature to identify plant anomaly is therefore necessary. The current work describes a farm robot with multiple sensors interfaced to acquire information about various physical parameters of the specimen as well as the environment. Image processing for defect identification utilizes machine vision and neural networks. The robot therefore serves as an efficient method for early detection of plant illness besides helping the user correct any anomalies that may be prevailing in the system. Besides the inherent fore-warning capabilities, it also enables the user to put in place measures to check further spread of any particular plant affliction."
We published our work in Procedia Engineering 2011 by Elsevier. Here are some slides, which I used for presenting the paper in Malaysia. (File upload courtesy opendrive!!, I found this site really useful)
This project is really close to me as it was the true beginning of what has been a wonderful journey as an undergrad student of Electrical Engineering. I sincerely hope that I can keep going along this quest, and who knows, be a part of future revolutions in the information age....
Here is a follow up to that. It was a genuine dream to build a farm robot, I believed that it could actually contribute to a country like India. Moreover it is a serious technical challenge to any engineer, and brings to the forefront some very tough problems in embedded systems, computer vision, robotics and control theory. My continuing obsession with the "3 C's" has always kept me revisiting these problems sometimes through coding or circuit design, or some times as pure idle thoughts. "Sit back and reflect", as the great Hercule Poirot says. Admittedly these idle reflections have taught me a lot and I believe widened my perspective to an extent. I feel its really enriching to try and imagine all the pitfalls that one's design might get trapped into. A good designer I believe, can not only correct design flaws, but also predict and prevent them.
Following is an abstract of the project
"Identification of plant disease is of paramount importance in the greenhouse and plant wilting is a primary cause for loss of revenue in the industry. The need for an automated feature to identify plant anomaly is therefore necessary. The current work describes a farm robot with multiple sensors interfaced to acquire information about various physical parameters of the specimen as well as the environment. Image processing for defect identification utilizes machine vision and neural networks. The robot therefore serves as an efficient method for early detection of plant illness besides helping the user correct any anomalies that may be prevailing in the system. Besides the inherent fore-warning capabilities, it also enables the user to put in place measures to check further spread of any particular plant affliction."
We published our work in Procedia Engineering 2011 by Elsevier. Here are some slides, which I used for presenting the paper in Malaysia. (File upload courtesy opendrive!!, I found this site really useful)
This project is really close to me as it was the true beginning of what has been a wonderful journey as an undergrad student of Electrical Engineering. I sincerely hope that I can keep going along this quest, and who knows, be a part of future revolutions in the information age....
Thursday, December 22, 2011
The internet: standing in motion
We are now in the information age. The internet, the backbone of our society has the potential to shape the way in which we perceive the universe.
With this in view, the following where I think where tomorrow's internet is going as a student of Electrical Engineering and Computer Science.
The internet today has nowhere to hide. The internet of things will be required support true information exchange. This information exchange warrants a forum for all concerned parties to "talk to each other"; we call this forum the internet. The strict layering imposed by the traditional model of the internet stood the test of homogenous scaling as it proliferated across the globe. But this model essentially assumed that all end systems were following the same standards, the same protocol. Today with the advent of sensor networks, vehicular networks etc. we suddenly have participants in the information exchange that "speak different languages". Therefore the new generation internet will have to be scalable such that it accommodates heterogeneous platforms.
A possible way to gain more flexibility in terms of end systems connected to the internet, might be to make the boundaries of the layers to fade. But this will lead to monolithic solutions that prohibit the internet's ability to adapt further. The purpose of protocol layering is to establish how we separate our "concerns", each layer corresponding to a different level of abstraction that indicates the part of the network in concern. What is needed is defining or at least interpreting the concerns afresh.
These "concerns" are based on the requirements from the information shared on the internet. For example, the purpose or the intent of an email containing a video clip of a football game is completely different from the intent of a communication with a cluster of environmental sensors at the Great Barrier Reef or atop the Himalayas. These messages differ not only in their information size but also in their urgency, their impact on the receiver and the required network resources. A rough parallel to the heterogeneity in the internet can be the internal architecture of a computing device. Different "nodes" like the CPU, MMU, ALU, Memory, I / O Devices, etc. share information across a common "network" namely the computer's internal bus. Since all the nodes here are within the computer's chip, the Operating System's scheduling algorithms and other such techniques manage allocation of "network resources" (the bus) among these nodes. Similarly the communication protocol developed for the internet also needs to manage how the network resources "shared" by the various nodes in the network. More interestingly, since the network here is inherently distributed the allocation cannot be centralized.
Protocol development also should encompass the hardware and software architecture of the nodes involved in the communication. As an example, sensor nodes have a resource constrained, event driven architecture. Hence information exchange with these cannot be done using standard SMTP / HTTP communication. Also given the low throughput, range issues and possible faults and failures in sensor networks we need to revisit our current monitoring scheme ICMP. When we talk of wireless networks, there are no hard and fast "connections" as in a wired internet. No network graph is known and communication is inherently unreliable. Control signals are needed for setting up the network, and for "house keeping" operations subsequently. All of these added requirements need to be handled by the internet.
A long story cut short, each layer of the protocol stacks along with standard protocols in these layers need to be revisited in terms of the changed requirement and the changed architectural constraints when we talk about the internet of things.
With this in view, the following where I think where tomorrow's internet is going as a student of Electrical Engineering and Computer Science.
The internet today has nowhere to hide. The internet of things will be required support true information exchange. This information exchange warrants a forum for all concerned parties to "talk to each other"; we call this forum the internet. The strict layering imposed by the traditional model of the internet stood the test of homogenous scaling as it proliferated across the globe. But this model essentially assumed that all end systems were following the same standards, the same protocol. Today with the advent of sensor networks, vehicular networks etc. we suddenly have participants in the information exchange that "speak different languages". Therefore the new generation internet will have to be scalable such that it accommodates heterogeneous platforms.
A possible way to gain more flexibility in terms of end systems connected to the internet, might be to make the boundaries of the layers to fade. But this will lead to monolithic solutions that prohibit the internet's ability to adapt further. The purpose of protocol layering is to establish how we separate our "concerns", each layer corresponding to a different level of abstraction that indicates the part of the network in concern. What is needed is defining or at least interpreting the concerns afresh.
These "concerns" are based on the requirements from the information shared on the internet. For example, the purpose or the intent of an email containing a video clip of a football game is completely different from the intent of a communication with a cluster of environmental sensors at the Great Barrier Reef or atop the Himalayas. These messages differ not only in their information size but also in their urgency, their impact on the receiver and the required network resources. A rough parallel to the heterogeneity in the internet can be the internal architecture of a computing device. Different "nodes" like the CPU, MMU, ALU, Memory, I / O Devices, etc. share information across a common "network" namely the computer's internal bus. Since all the nodes here are within the computer's chip, the Operating System's scheduling algorithms and other such techniques manage allocation of "network resources" (the bus) among these nodes. Similarly the communication protocol developed for the internet also needs to manage how the network resources "shared" by the various nodes in the network. More interestingly, since the network here is inherently distributed the allocation cannot be centralized.
Protocol development also should encompass the hardware and software architecture of the nodes involved in the communication. As an example, sensor nodes have a resource constrained, event driven architecture. Hence information exchange with these cannot be done using standard SMTP / HTTP communication. Also given the low throughput, range issues and possible faults and failures in sensor networks we need to revisit our current monitoring scheme ICMP. When we talk of wireless networks, there are no hard and fast "connections" as in a wired internet. No network graph is known and communication is inherently unreliable. Control signals are needed for setting up the network, and for "house keeping" operations subsequently. All of these added requirements need to be handled by the internet.
A long story cut short, each layer of the protocol stacks along with standard protocols in these layers need to be revisited in terms of the changed requirement and the changed architectural constraints when we talk about the internet of things.
Saturday, October 16, 2010
PS... I love you
Its been a really long time since I wrote my last post. Then suddenly last week I received my PS-1 Grade sheet and i thought i could write about my PS.. So here I am..
For all those outside the BITS community, PS-1 stands for Practice School-1. This is the summer internship completed by all BITSians in the summer term after our second year. This internship is really a milestone in a BITSian's life, and helps many of us to gain an insight into what kind of work we will like to do in the future.
My PS-1 was at CEERI, Pilani (Central Electronics Engineering Research Institute, Pilani) which is one of the topmost Central Government Research Labs in India. I had the privilege to work with the Agri - Electronics Group (AEG) at CEERI, under the guidance of two highly inspirational and approachable guides, Dr. Shashikant Sadistap (Scientist E2, Head, AEG) and Dr. B. A. Botre (Scientist C). I was interested in working in the field of Embedded Systems, and the AEG carries out research about the design of embedded systems for agricultural applications. I worked there for 2 months with my friend and colleague Smarjeet Sharma. Our project was an extension of something I had been working on for almost a semester before that with my neighbour, Abhinav Gupta in college.
The project was titled "Design and Interfacing of a Farm Robot for Green House Monitoring". The main aim here was to build a mobile robotic system, that can navigate its way in a green house and monitor all the parameters like temperature, humidity, soil pH, etc. related to plant health. Building something like this in two months was definitely not easy, so we took a chassis with 2 motors to drive the wheels available in the market. We also had an ARM9 based micro-controller, the Samsung S3C2440 available with us. (Actually we had a development board for this micro-controller(mu-c) called the Friendly ARM). This micro-controller has runs with Linux 2.6.29 onwards.
Our task was to interface analog sensors and DC motors with our mu-c. For this we had to figure out how to use the General Purpose Input Output (GPIO) port on the Friendly Arm board. It turns out that this port provides pins for using 4 ADC lines, the SPI bus and about 20 other general purpose lines. I must thank here the Friendly ARM forum (www.friendlyarm.net/forum) for their awesome spot-on help for this. The forum gave me the configure file necessary to include the GPIO drivers in my Linux kernel. It also told me how to build my own ADC drivers for all four ADC lines. We also designed the circuit using a programmable gain amplifier, and L298 motor driver chips to drive the entire system. The only part left was the coding.. 2 nights with the C compiler.. and yes the robot was functional!!
This was at the time of our "Mid-semester feedback" in PS-1. The question in front of us was how to enrich the robot during the remaining month. In a discussion woth my guides, we thought that giving the robot vision capabilities will make it capable of many more tasks. We figured out that the OpenCV libraries by Intel are compatible with the ARM9 architecture. So we took a Logitech webcam, and hooked it to the USB port of the Friendly ARM. We wrote another decently lengthy C code using OpenCV libraries and by the end of the internship, our robot can detect anomalies in the color distribution over a plant leaf.
This was all for PS-1, but the farm robot was just a start. What I really see here is a platform for building mobile robotic applications, based on sensory and vision feedback. I am currently working on computational modeling of robotic systems, that will help us to check robotic hardware, and algorithm design before it is implemented on field.. especially for safety critical applications. I am planning to use the Robot Schema (RS) model and Hybrid Automata Theory.
But all this was possible only because of the kick start from PS-1. Seriously.. PS I love you
For all those outside the BITS community, PS-1 stands for Practice School-1. This is the summer internship completed by all BITSians in the summer term after our second year. This internship is really a milestone in a BITSian's life, and helps many of us to gain an insight into what kind of work we will like to do in the future.
My PS-1 was at CEERI, Pilani (Central Electronics Engineering Research Institute, Pilani) which is one of the topmost Central Government Research Labs in India. I had the privilege to work with the Agri - Electronics Group (AEG) at CEERI, under the guidance of two highly inspirational and approachable guides, Dr. Shashikant Sadistap (Scientist E2, Head, AEG) and Dr. B. A. Botre (Scientist C). I was interested in working in the field of Embedded Systems, and the AEG carries out research about the design of embedded systems for agricultural applications. I worked there for 2 months with my friend and colleague Smarjeet Sharma. Our project was an extension of something I had been working on for almost a semester before that with my neighbour, Abhinav Gupta in college.
The project was titled "Design and Interfacing of a Farm Robot for Green House Monitoring". The main aim here was to build a mobile robotic system, that can navigate its way in a green house and monitor all the parameters like temperature, humidity, soil pH, etc. related to plant health. Building something like this in two months was definitely not easy, so we took a chassis with 2 motors to drive the wheels available in the market. We also had an ARM9 based micro-controller, the Samsung S3C2440 available with us. (Actually we had a development board for this micro-controller(mu-c) called the Friendly ARM). This micro-controller has runs with Linux 2.6.29 onwards.
Our task was to interface analog sensors and DC motors with our mu-c. For this we had to figure out how to use the General Purpose Input Output (GPIO) port on the Friendly Arm board. It turns out that this port provides pins for using 4 ADC lines, the SPI bus and about 20 other general purpose lines. I must thank here the Friendly ARM forum (www.friendlyarm.net/forum) for their awesome spot-on help for this. The forum gave me the configure file necessary to include the GPIO drivers in my Linux kernel. It also told me how to build my own ADC drivers for all four ADC lines. We also designed the circuit using a programmable gain amplifier, and L298 motor driver chips to drive the entire system. The only part left was the coding.. 2 nights with the C compiler.. and yes the robot was functional!!
This was at the time of our "Mid-semester feedback" in PS-1. The question in front of us was how to enrich the robot during the remaining month. In a discussion woth my guides, we thought that giving the robot vision capabilities will make it capable of many more tasks. We figured out that the OpenCV libraries by Intel are compatible with the ARM9 architecture. So we took a Logitech webcam, and hooked it to the USB port of the Friendly ARM. We wrote another decently lengthy C code using OpenCV libraries and by the end of the internship, our robot can detect anomalies in the color distribution over a plant leaf.
This was all for PS-1, but the farm robot was just a start. What I really see here is a platform for building mobile robotic applications, based on sensory and vision feedback. I am currently working on computational modeling of robotic systems, that will help us to check robotic hardware, and algorithm design before it is implemented on field.. especially for safety critical applications. I am planning to use the Robot Schema (RS) model and Hybrid Automata Theory.
But all this was possible only because of the kick start from PS-1. Seriously.. PS I love you
Wednesday, September 1, 2010
Hello World!!!
Probably the most popular opening post! But this is probably the only program that most of us can confidently write without the ubiquitous "Segmentation Fault" . This is a blog dedicated to the challenges and achievements, to the highs and lows, to the glasses half-full,half-empty and overdesigned, in short to the Segmentation Faults and Successful runs for programmers, engineers.. and thinkers in general...
Hope to get in touch with all members of the brethren...
Please click here to download my resume.
I can be reached at chinmay21990@gmail.com or chinmay.duvedi@gmail.com
Hope to get in touch with all members of the brethren...
Please click here to download my resume.
I can be reached at chinmay21990@gmail.com or chinmay.duvedi@gmail.com
Subscribe to:
Posts (Atom)