DEV Community: Laneone

DSCE Hack, 2016

Laneone — Fri, 21 Dec 2018 06:29:45 +0000

Dayananda Sagar College of Engineering, the college I am a part of currently, conducted an open themed 16-hour hackathon for the Computer Science Engineering students of the college during March 2016. Mostly people from the second and third year were participating, with me being the only kid from the first year.

I wanted to build a product roughly in the IoT area, a mentor from DERBI, a entrepreneurship cell in my college, suggested that I try to show him a fully functional IoT stack, I agreed and started with one.

HackIndia had thought me a thing or two about IoT, in this demo, I had 2 LEDs that represented the state of bulbs in 2 rooms, the LEDs were connected to a laptop which was in turn connected to the Internet. I had a separate circuit built with just a motion sensor, it was connected to a different laptop and sent requests to turn on/off the LEDs that were connected to the first laptop. Apart from the motion sensor, you could also change the state of the switches with the help of an Android app we quickly wrote from scratch, it also sent requests to the LED connected laptop. This was all possible because of a web server running on the first laptop, we made a front end for this server and this allowed you to switch the LEDs from the computer too. So you had like 3 toggle-able access points per LED, you could easily replace the LED with an actual household appliance with a single channel relay per appliance.

This allows you to control your home appliances with the help of technology, you could potentially scale this system to detect movement and in the absence of any, you could automatically switch off all the lights in the house to save electricity. In order to improve the product, you could potentially add thermos-sensors so that you could know the temperature of the room, and alter the speed of the fan to match a given user temperature, you could also add light sensors so that you could dim lights that are in the presence of natural sunlight. Adding Google's Nest API support would go a long way in helping new devices interact with the existing IoT stack, most of the toggling could be handled through the Nest API, we therefore do not need to build client side interfaces to the user.

Right now this was built with an Arduino as it was just a demo, if you were to implement this to scale, you'll ideally want to look at ESP8266 with a strong base signal so that you can do peer-2-peer control of the appliances, it'll also work out significantly cheaper. The cost-barrier to entry to a product that'll be built with an ESP8266 could be as low as Rs. 350 per appliance at home, that's Rs. 280 for the ESP8266 and Rs. 70 for the single channel relay.

The judges were impressed with my product and I was placed First in this hackathon, I received a medal, a certificate and an Amazon gift voucher of Rs. 1000.

Pravega, 2016

Laneone — Tue, 11 Dec 2018 11:59:53 +0000

Pravega was a data science hackathon conducted in Indian Institute of Science, Bangalore, during January 2016. It was a solely Microsoft sponsored event, they were trying to push this new platform called Azure ML that took care of most of the heavy lifting when it came to Machine Learning and gave a simple user interface that you could use to learn/train data.

We were given a three hour lecture on how to use Machine Learning for preliminary tasks like prediction in case of linear regression and other easy to explain examples. At the end of the lecture, they asked us to find data-sets on http://data.gov.in and use those to show them valuable visualizations. It was an open topic, so you could pick any topic that you were comfortable with and draw conclusions on that topic.

The Azure ML platform took raw data from the user and learnt using the data based on the algorithm you decide. The learnt algorithm could then be exposed to a web service and hosted on the Azure cloud, which can be run at any time. We were supposed to, as part of this hackathon, claim raw data, learn from the data, expose the algorithm to a web service, optionally call the web service from a thin client and display the visualization to the user.

We picked blackouts as our area of interest, we looked at two data-sets one from data.gov.in which was rather useless and one from http://powercuts.in, which wouldn't allow you to download the reports. We later found a cached copy on a repository in GitHub of the same set. It had only around 292 rows of data which I assume was a factor in the prediction of the algorithm.

The intuition was to machine learn the different factors that influenced power cuts in India. A lot of factors such as whether it was planned/unplanned, the geolocation of the powercut, date, time and other factors were given as variables in the data-set. We used Azure ML to machine learn the report using the Two-Class Boosted Decision Tree algorithm. So the input data-set was divided into 2 parts, 70% and 30% respectively, 70% is used to train the model and the algorithm, and 30% is used to test the algorithm and get an accuracy score which can be used to compare how good the algorithm is working. We got an accuracy of 99.7% and that seemed a bit too good to be true at the time. We planned to expose this to a web service that listened for a timestamp and a location and given the two variables, it would tell you whether there could be a power blackout expected in the next 8 hours.

We did not win anything at this hackathon, but it was an amazing experience, the judges and the mentors we were given throughout the hackathon were extremely helpful and resourceful. I loved the time I spent at this hackathon and learnt a significant amount about machine learning and the Azure ML platform.

Under 25 Hack, 2016

Laneone — Mon, 03 Dec 2018 08:03:02 +0000

Under 25 Hack was a hack arranged in NUMA, Bangalore, during the first few weeks of 2016, January. It was a hiring hackathon and was the first one we'd been to.

Following the application we used to conserve mobile data, we saw lots of enterprise potential in being able to move around files in hyper-local storage, we improved on our previous product and branded it as BroGet, a file sharing system on steroids.

The intuition behind BroGet is that there are some files that have to be pushed to a user based on their geolocation, and we use hybrid storage to push those files, we aimed our demo at three product use cases, a Library management system, an Office document management system, and a Restaurant order management system. Ideally we'd have another use case for Home users but it won't be enterprise oriented, that version would be free for users to download, and use without restriction thereby promoting users to have the app installed on their phone.

In the case of the Library, you could imagine a Raspberry Pi based download box that is plugged into the LAN of the library, it could facilitate in pushing an e-book containing a catalog of all the present books in the library to the user's phone directly with the BroGet background app running on the phone ready to receive the e-book and give a generalized interface to the library, and provide the ability to download e-book variants of the books that have been borrowed in the library and are currently unavailable, all from the same hybrid local download box.

In the case of an Office, you could imagine an important document that had to be circulated to every new employee who joins the office, the document could be uploaded once to the hybrid local download box connected to the office's LAN connection and it would facilitate in sending the said document to every user as and when he/she joins the corporate network. This would allow the user to receive a document as and when he enters the geolocation of the office. Broadcast messages and overall public announcements could be distributed via BroGet as the app would automatically sync and update the most relevant document for the user to view based on the priority of the message.

In the case of a Restaurant order management system, we'd ideally have a Raspberry Pi based download box set up in the vicinity of the restaurant and have the menu uploaded as an e-book on the device. The menu/pricing and billing systems would co-exist in the same stack and would be kept offline, As a user enters the geolocation of the restaurant, the menu would be pushed from the download box to the app on the user's phone, and the background app would receive the file, and provide a generalized interface to order food from the application. BroGet in this case becomes a hyper-local terminal to the Restaurant's order management download box. A user can now order his menu from his phone and the order will be placed directly to the kitchen where a dumb terminal is made to receive the order from the download box and show list of menu items to prepare in the kitchen to the chef. A backend allows for orders to be entered through the cloud to ensure that home deliveries are also tracked.

In the home use case, it's pretty much like the app that allowed you to conserve mobile data, except this time you're buying the BroGet download box and you can have it download things for you, when you're not home.

The entire suite was enterprise oriented, and we had made presentations to showcase the different use cases, the judges were impressed with the demo that allowed them to sanction downloads using their mobile data. A good viewpoint a judge felt is that our team lacked the oratorical skills to showcase the full use of our product line. We were approached by a startup that wanted to work with us because they were working on a system with a hybrid cloud storage system and BroGet was relevant to them.

Being a hiring hackathon, first place was a job at a startup of your choice from the list of sponsors who had made this hack possible. We finished in second place and got an Indian Chrome-cast derivative called the Teevee, and a Raspberry Pi 2, plus tickets to witness the Startup India Conference, New Delhi.

Hashcode, 2015

Laneone — Sat, 01 Dec 2018 06:35:09 +0000

HashCode was another very well conducted PES hackathon, with some really good competition, it was conducted in PES University, during November, 2015.

The hack was divided into 4 themes, the last theme being an open Hack, therefore we chose that track, and built a product that'll help you conserve mobile data.

The idea behind it is simple, with your mobile data turned on, you make a request to download something, an intent filter on Android listened for downloads and the exact link to the file is picked up by the Android app, it packages the link and sends it to a download box sitting at home, connected to your home broadband, the download box consisted of nothing but a Raspberry Pi with a python backend that listened for links to download, upon receiving a link to download, the server application used this library called Aria2c to download the particular file in question, aria was mature enough to support multiple protocols like HTTP, FTP, BitTorrent even so by using this library we abstracted the downloading aspect of the application. Once the files were on the Raspberry Pi locally, it listened for new entrants on the Home WiFi network, as soon as it detects a state change in the WiFi table, it automatically tries to send the file to the device, if it's an android device with the client application loaded on it, it realizes that a request to retrieve the file was issued and sends the file to the device, automatically adding the downloaded content into the user's gallery, seamlessly and effortlessly, and finally deleted the file from the local SD card.

The judges loved the idea and could quickly relate it to Pocket, google's proprietary link sharing application, pocket allowed you to save links and open them later when you had access to a reliable internet connection, our application downloaded the content for you in real time, and sent it to you when you had WLAN access to the download box.

A few ways in which we can improve the application right off the bat is by extruding the 4 USB ports we get on the RPi and force it to act as one big file system thereby allowing users to hotplug additional storage in case the standard SD card's size does not fit their consumption. Adding metrics and analytics to this product would go a long way in helping users analyze the type of content they consume and where most of their data ends up getting used in. Auto detection of new entrants and subsequent signups to a download box could be implemented to help ease bandwidth traffic, say a video that you and your family members both want could be downloaded only once and served hyper-locally from the download box instead of downloading it twice and wasting bandwidth.

At the end of the day this application was built out of a necessity where some of us who live in the hostel end up with an outrageously slow internet connection when we have one at home that can download a lot without a sweat, so the point was to build this application so that we could use it ourselves, throw all the things you have to download onto a list and execute it remotely, fetching it as and when we go back home, again, seamlessly. This could also be used when you're surfing in class and realize that the latest episode of Game of Thrones comes out and you don't want to download it using your mobile data, but you use our application to put it on download, and when you go back home, it's already downloaded and it syncs via LAN, almost momentarily and it's instantly there in your phone for consumption.

We ended up in the second place for this hackathon and were given a trophy each and 25k cash bonus. This was the starting point at which we truly began understanding the intricacies of what they expected at hackathons and how to deliver to that particular niche.

Siddhi, 2015

Laneone — Wed, 28 Nov 2018 03:32:09 +0000

Siddhi hackathon was conducted online during the month of October 2015, you had to register with an email ID on Hacker Earth and submit code to the hackathon during the day. It was conducted by Persistent Systems, there were 2 tracks, one for business oriented product lines, and another for environmentally oriented product lines.

I built a social media scraper tool that evaluated and profiled people based on their online interaction. It considered factors like the pages you interact with, likes you make in public, your comments on public pages, and other such factors. The idea was to make a tool for HR teams who could run the suite against potential employees, the tool would look through their publicly available online interaction, look for any red flags, and generate a scored report for the said user. This report can then be instrumental in hiring the candidate.

The main assumption behind this tool is that the confidentiality of the user will be maintained, only the algorithm or the tool would be able to look at posts made by the user, if it detects a red flag, only the acknowledgement of the red flag would be made in the report, the post that the user had originally made would not be shown/factored into the report, this way you can be sure that there will be no partiality or unfairness between any two trials with the tool.

The tool expected you to point the candidate's name, after which it requests Facebook/Twitter for his OAuth permissions, once the user grants these permissions, the tool scrapes everything that's available through their respective APIs and runs it through a classifier that takes care of flagging any activity.

The judges loved the idea, but it was an incomplete product, I could only get permissions from Facebook and Twitter and couldn't convincingly build the machine learning algorithm, still we were invited to Taj Vivanta, Bangalore for an offline session where the top 5 teams were selected. We each had 5 minutes to showcase our idea and talk about how our idea would leave an impact on businesses.

We didn't win anything at this hackathon, but the experience of meeting Mr Mritunjay Singh from Persistent Systems was really valuable to me.

InGenius, 2015

Laneone — Sat, 24 Nov 2018 06:11:33 +0000

InGenius was a hackathon that was very excellently conducted, everything about the hackathon seemed to be very well thought out and outrageously well executed. It was an open theme hack conducted during October 2015, in PES South Campus.

The competition we faced at the hack was really excellent, they came with lots of preparation and had ironed out the flaws in their application, the review process used to evaluate the weight of the ideas was well thought out too, it consisted of a few rounds, first round was where they heard an overview of the idea and evaluated the presentation skills of the team, the next round was in front of a panel of judges where you could explain the intricacies of your application and get real time feedback from the judges. The next round consists of a demonstration of your idea in front of two judges who will evaluate/test your application and give you insights on the best way to take it to the market.

One thing I've realized at PES hackathons is that they encourage prototyping and pushing of a product to the market. The majority of the advice I've heard from the mentors were aimed mostly at implementing things in the real world, and trying to launch the product in the market and improving it over time.

The product we built at this hackathon lacked a certain understanding, but the idea was to build a tool using Node.js that allowed us to give a developer the fastest and easiest way to setup an initial API. If a hardware developer picks up an Arduino and prototypes a potato launcher, our app, called SnAPI, would allow him to quickly set up an API that can be launched from a web server, and the api calls made to the server would be tracked in real time and analyzed and put into charts using D3.js, quantitative values would be put in bar graphs, and it drew a line over a graph for values that were non-discrete. Our implementation depended on 2 fields, one field custom.js needed a declaration of the functions to be used by your program and the other field consisted of values. Once the api was setup, custom.js would be used to start the script and track calls, compute graphs, etc.

The demo we showed the judges failed to show them the relevancy of the need for that tool, they did not see monetary potential in the idea and we must fairly admit that too. At this hackathon I realized the importance of backing a product with monetary potential, anything you pick in a product to pitch to a hack, back it up with relevant sources on how to bring it to market and make an earning off it. Show them a business model that works and they'll be instantly a lot more interested in the product, regardless of the scope of the product.

This hack had a bar code based entry to dinner that was tracked in real time using a bar code on your ID card, I felt that was really cool and well managed. They even gave out snacks with that and I think that's a really splendid way of managing resources at a hackathon.

We were about to leave empty handed at this hackathon, but there was a competition that gave a 5k gift voucher to anyone who got the highest number of retweets with the #InGenius tag, therefore promoting their hack. So we thought we could game this competition. We posted a picture of our idea on twitter and shared the link on social media until we had around 62 retweets. Therefore we ended up being the team with the highest number of retweets so that landed us that 5k voucher. So we split the voucher in 3 and bought 3 wireless keyboard and mouse combinations for 5k.

Hackerupt, 2015

Laneone — Mon, 19 Nov 2018 04:07:39 +0000

Hackerupt was a hackathon that was aimed at High School students which consisted of first year engineering students, 11th and 12th grade students. The theme of this hackathon was Education, with the focus being on finding ways to disrupt the current education practices. The hack was for 12 hours and was too short to get anything done. The project we wanted to build was called Nitro, a real time student/teacher interface program that consisted of giving an Android app to the students present on the lecture and asking them to live select answers in an MCQ when presented with them on screen. This hack was conducted in WorkBench Projects, MG Road during August, 2015.

The analytics from the app could be used to study the individual child's ability to learn and interest in key topics, based on which the further courses could be tweaked to ensure maximum efficiency in teaching the students. The real advantage of the app was to facilitate a real time feedback loop that kept constantly improving the base lecture that the teacher was responsible to design.

The stack consisted of 3 parts, we built a small 433 MHz transmitter with 4 push buttons one for each of the answers in the mcq, which was a cost effective solution to deployment in case Mobile phones were not easily accessible in remote locations. There was also an android app in the stack that emulated the 4 answers and allowed students to pick one based on the question shown on screen. The server consisted of an MEAN stack with an api that allowed you to setup questions, review progress of the entire subject versus an individual child's score pertaining to that particular subject, among other analytics.

The light around this application is that everything was stored on the cloud, questions once uploaded in the application could be accessed and modified by teachers who felt the need to improve/correct the given question set. Future plans could include building a system around the question submission process, and include reviews for the best question set to train students with, overtime if this gets adopted we will have aggregated the best and most efficient tool to raise question sets as far as day to day teaching is concerned, and the best part is that there will be uniformity in teaching the students with these said question sets. This gives us the advantage to move from locally and geographically restricted classrooms to more e-learning based applications. Suppose a kid is on leave and does not attend the classes, he can log into his mobile and continue attending the lecture/ answer questions that were given to him by the teacher, and his progress would not go unaccounted.

Also by bringing the barrier of entry down to nothing but a phone seemed very straight forward, the mobile connects us directly to the information grid and sooner or later, a hefty portion of learning would mostly be carried out online and at your own pace, so this seemed to us like a worthy venture.

We left empty handed at this hack too, because we were overambitious in our attempt to build a fully thought out product but wasted too much time on the specifics, we set out to learn how to build a minimal viable product and hard code specifics at this hack.

HackIndia, 2015

Laneone — Fri, 16 Nov 2018 06:47:46 +0000

HackIndia was the first Hackathon we ever attended, we as in me and my squad of tech friendly friends, we never really understood the essence of what a hackathon was at this point even though we had a fairly good go to strategy to try. It was an open hack, meaning you could pretty much build a hack idea in any theme/context you wished and present that to the judges. We chose home-automation/IoT. It was conducted in PES University, Banashankari during October, 2015.

The first product we built at this hack was called IoTomate, an end to end solution that abstracted and simplified the entire process of having an IoT enabled home. The concept behind it was simple, every appliance was connected to the cloud, in particular to a cloud instance of Bluemix, an IBM product that allows you to host an API in the form of chunks of code written in Node-RED, it allowed us to sense/actuate the appliances, it also allowed us to set "trigger" conditions with the use of an Android application, what this meant is that every reaction the appliance takes at home is a result of some sensor value, say if the temperature in the room is rising above 30 degrees, automatically turn on the Fan, and if it drops below 27 degrees turn it off, another example would be if there are no "home" devices connected to the WiFi there's a good chance there's no one at home, so immediately turn off every light/fan in the house.

Now we really believed that the selling point in our product was the API that we had written on the cloud-end, we also built a small breakout around the ESP8266 that turned a relay on/off which was in turn connected to a desk lamp that acted as our demo/test appliance. This was an additional key selling point in our application, the ESP8266 with it's sister components ran us about 360 rupees to implement, 280 for the ESP and 80 for the 8 channel relay, this really puts our product on the low end of the spectrum when it comes to implementation, we could probably bring cost down a lot more if we mass produce this.

Being our first hack, we had no clue about what kind of judging criteria they had in mind, they had initially white listed 5 contestants out of which our team was one of them, we knew we were getting some kind of traction, but it was too early for us to capitalize on this. We explained to the judges how this api could be extruded to allow for a lot many more trigger conditions ranging from additional sensors like presence with IR etc, that could also be connected to the cloud. A key factor we failed to consider is if there was some kind of attempt similar to this already being attempted, a judge pointed out to us that Google was implementing something called the Nest API which was something we had failed to even look at in the first place.

We left empty handed from that hack but we learned a lot about the general expectations of judges and the kind of passion they look for at these kind of events. Also we were interviewed by CNBC because we were all from First year of Engineering which gave us quite some weight for being probably one of the youngest teams in the scene.

You can take a look at the exact API spec here: it lists down almost every endpoint we considered when trying to implement IoTomate.