Selected Academic Projects
Home automation (HA) is gaining much more popularity with advances in Internet-of-Things as currently various open-source and commercialized projects are available for connecting smart home kits to each other for controlling home appliances like OpenHAB, Home Assistant (hass), Domoticz, OpenMotics, OpenRemote in the open-source section and CommandFusion, Savant, RTI to name a few commercial products. In this master’s project, I have selected OpenHAB open-source (GPLv3) home automation bus which is a multi-platform, hardware agnostic, using Java OSGi (Open Service Gateway initiative) that can support any home automation protocols depending on the available bindings. OpenHAB is used for integrating and interoperability of various smart homes (ex. Insteon, WeMo, Ecobee), applications and softwares (like IFTTT, MySQL, etc) and can be considered as glue of the Internet of Things. I have been dealing with setting up both Raspberry Pi 2 and 3 model B version 2, installing and configuring OpenHAB middleware version 1.8.1, setting up Insteon, SmartThings, Belkin WeMo and Philips Hue smart home kits each independently of OpenHAB, controlling each of the the aforementioned kits using Amazon Echo, and configuring OpenHAB so that it can control each of the kits independently of other kits. The final goal of this project was having OpenHAB control an item from smart home kit A based on an event triggered from smart home kit B. This is of importance because without using a third party software like OpenHAB or Amazon Echo HA bridge, users wouldn’t be able to turn on Philips Hue lamp and change its color to red if Insteon motion sensor detects motion due to incompatibility issues. However Insteon allows you to turn on the light bulb connected to its Insteon switch if you define a rule upon the Insteon motion sensor being triggered. This master’s project involved a thorough understanding and survey of setting up various smart home kits each using different communication protocols, conducting various experiments for each smart home kits separately and altogether, networking and Linux troubleshooting, learning how to setup an open-source software based on my needs and how to contribute to the open-source community.
Scheduling large and diverse workloads is inherently hard, and existing approaches tackle this in two alternative ways: 1) centralized solutions offer strict, secure enforcement of scheduling invariants (ex. fairness) for heterogeneous applications, 2) distributed solutions offer scalable, efficient scheduling for homogeneous applications. Mercury is a hybrid resource management framework that supports the full spectrum of scheduling, from centralized to distributed. Mercury paper authors argue that these solutions are complementary, and advocate a blended approach. The Mercury framework harnesses this flexibility by opportunistically utilizing resources to improve task throughput and claims 35% improvement in throughput. However, modern data needs and consumption patterns have thrown data across datacenters and performing well in a single data-center is no longer enough. This project tried to evaluate Mercury in a geo-distributed setting and suggest potential solutions to make it work better. This work tests Mercury in various cluster configurations, with uniform and non-uniform resources to profile it.
Various signal processing algorithms using MATLAB for image processing
In this project I aimed to provide a client-side strategy management for selecting the nodes from EC2 and migrating the instances depending on various metric including node capabilities and needed performance. The aim of this project was gaining more efficiency improvement through use of better policies and assigning the best node type of each zone as a duplication in the bundle of nodes which I select for a client. In case of failure in EC2 nodes or overload in any of the primary nodes selected by client, load will be migrated to another sub-type node in the client node bundle within the same instance type.
Project report
Designed cache, ALU, and four-bank memory for a pipelined processor in Synthesizable Verilog