Skip to content

Project Proposal

Jump to bottom
b-en edited this page Sep 23, 2013 · 13 revisions
  1. [Introduction](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#introduction)
  2. [Background Information](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#background-information)
  3. [Objectives](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#objectives)
  4. [Methods](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#methods)
  5. [Conclusion](https://github.com/ThatGeoGuy/ENGO500/wiki/Project Proposal#conclusion)

Below are rough descriptions of what should go into each section of the report. See the relevant issues in the issue tracker for more details / discussion.

Introduction

  • Introducing the concept of the "Internet of Things (IoT)
  • Proposed benefits / reasons for the existence of IoT
  • Definition of the OGC specification for the IoT
  • Reason why we're using the OGC specification
  • Aims of the project
  • What we hope to accomplish

See issue #2

Background Information

  • What is the Internet of Things (IoT)
  • What is the Open Geospatial Consortium (OGC)
  • What is the OGC specification (OGC RESTful API) that we are using
  • Why we want a common API

See issue #3

Objectives

  • Finding a sensor setup to add to the Internet of Things (IoT) / Sensor Network (SensorWeb) that can measure information relevant to us locally
  • Develop an intermediate library / interface for the sensors to the OGC RESTful API that is being hosted on Dr. Liang's servers
  • Develop some user interface (UI), such as a mobile application or web page, that uses sensor data in some fashion.

Expanded further (but still rough...)

This project is presented as one general umbrella goal, which is broken down into smaller objectives and sub-objectives. Overall goal: Use the Internet of Things to tangibly assist the citizens of the city of Calgary in a practical and user-friendly way.

Objective #1: Determine a location-based application of the IoT which is relevant to the city of Calgary. Further details: Define a problem relevant to Calgarians (or a particular sub-group of citizens, such as civil servants, university students, environmentalists, etc.); specifically identifying a component which can be measured and the importance of its spatial properties.

Objective #2: Design a sensor setup which can measure data suitable for the application determined in objective #1. Sub-objective:

  • Determine technical requirements necessary for data measurement (e.g. sensor(s) required, other periphery elements needed)
  • Create a working prototype of a sensor which could be deployed in the city
  • Test prototype in at least five different locations

Objective #3: Develop a library which links the sensor and the OGC RESTful API Sub-objective:

  • Learn necessary language(s) required for writing a library which will work with the chosen sensor setup
  • Collect test set of data with multiple sensors in a working/usable configuration in the city

Objective #4: Create a user interface (UI) such as a webpage or mobile application which makes use of the OGC RESTful API to display the sensor data. Sub-objective:

  • Design user-friendly graphical interface which is tested and found intuitive by at least 80% of test subjects
  • Represent collected data (in real time) using the created user interface

See issue #4

Methods

  • Sensors used / considered
  • How we plan on creating the library / interfacing with the database
  • Programming languages we may consider using for the task
  • Organization / management (project will be managed and tracked through github)

Computer board

All sensors will be interfaced using a single board computer. These computers are well suited for DIY, educational, and prototyping projects due to their low cost and the wide variety of available sensors. The board chosen for the the project is the Raspberry Pi. This was chosen over the Arduino Uno due to the following projected constraints:

Connectivity: The computer must be connected to the internet so that sensor data can be accessed. The Raspberry Pi includes an Ethernet port by default, and an external WiFi ($10) or 3G ($27) dongle can be attached. The Arduino has WiFi ($70) & GSM "shields" ($115) . It is likely that the sensor will be built to include WiFi capabilities in order to obtain a balance between cost and ease of use. In areas that are not near a WiFi network, a phone with 3G to WiFi capabilities may be utilized.

Performance: The Arduino board is built around a micro-controller with lower specs than the Raspberry Pi. The Arduino is clocked at 8-16 MHz processing speed with 2-8 kB of RAM available. The Raspberry Pi features separate CPU & RAM and boasts a 750 MHz processor which can be overclocked up to 1GHz with 512 MB (shared with GPU) of RAM available. Depending on the application, either could be suitable.

Power consumption: The computer & sensors will need to be powered by an external power source. The Arduino has much lower hardware specs than the Raspberry Pi, and as a result consumes less power. The sensors & network connection are likely to be the dictating factor in how much power is being used.

Cost: Costs of the boards themselves are similar, the Arduino Uno costing $30 and the Raspberry Pi costing $35. External sensors for the Arduino are generally more expensive than Raspberry Pi, as they must be built to work with the Arduino specifically. Sensors for the Raspberry Pi have the benefit of being able to connect via USB and as long as they are Linux compatible, it is likely they can be used.

//Add some details about Raspberry Pi, (OS we will be using (probably Debain derived Raspian)), how we will set up our development environment, how we plan on dealing with saving/transporting data, where we will be getting our raspberry pi (can we use steve's or do we need to order one?), how we plan on powering it (depends a lot on application)

Sensors considered

For the location of the device, the sensor set-up will likely be one of two situations:

  • If the hardware was designed to be used in an application where the sensor is moving, a GPS receiver will likely be included. //Add considerations for including a GPS sensor
  • If the sensor is to be placed in a location for long periods of time, and gathers spatial data of a different kind (ie image based) than the unit will likely not require a GPS receiver.

Other sensors that could be include are: Image (webcam or camera), Sound, Meteorological, Distance, Magnetometer, //some other stuff

Interfacing with the Database

The sensor assembly will have network access of some kind, with which it will be sending sensor data to a database designed specifically for IoT applications. This server is maintained by the Sensor Web Interface for IoT Standard working group. The sensor assembly will require a library which will be developed to adhere to the upcoming Open Geospatial Consortium (OGC) Sensor Web interface for IoT StandardSensor Web interface for IOT (SWIOT) standard. This project will likely be one of the first to use the SWIOT standard, and it is hoped that the project's deliverables will be used and adapted in the future to create a truly cohesive IoT.

Programming Language

The Raspberry Pi is configured to support Python by default, but it is easy to use other languages such as C/C++ or anything else that will compile on ARMv6 architecture. Advantages of using Python are that as high level programming language it allows for easy development and smaller source size. Due to it's interpreted nature, it is slower and uses more resources than C++. Advantages of using C/C++ are that as an intermediate programming language it is faster and more flexible than Python. Development of C++ programs is more complex, which takes more time and code is typically 5-10x larger in C++.

Organization / Planning

The project will be managed through Github which will serve as a means to plan & document the project during it's evolution. Github has many tools to aid project's along their development and is a good choice for the project due to it's open source nature. The tools that will be used throughout the projects lifetime are:

Issues: Any time there is a task that needs doing, an Issue will be created for it. The Issue's description will outline background information, objectives, and in most cases a due date. Issues can be assigned to users or users can volunteer by assigning an issue to themselves. Once an issue is assigned to a user, other user's know not to work on it without addressing the issues owner beforehand. Issues can be labeled and sorted in various ways to help manage the backlog, and will serve as the main organizational system for our day to day work.

Wiki: The wiki will serve as the main repository for all the knowledge amassed throughout the project. It is readable by anyone but only project contributors (our group) can add to it. By compiling all data in one place all team members can stay current with the projects evolution without consulting multiple sources.

Pulling: //Maybe Jeremy can flesh this section out as I only have a basic understanding and no experience yet

See issue #5

Conclusion

The Conclusion of the proposal will not be completed until all the other sections have been, so it is not entirely useful to mark down what will be inside of it now, but it is important to track that it should be done.

See issue #6

Clone this wiki locally