FOSSASIA Open Tech Community

A low-cost laboratory for everyone: Sensor Plug-ins for ExpEYES to measure temperature, pressure, humidity, wind speed, acceleration, tilt angle and magnetic field

Post author:Praveen Patil
Post published:August 19, 2015
Post category:FOSSASIA loklak Pocket Science Lab

Working on ExpEYES in the last few months has been an amazing journey and I am gratful of the support of Mario Behling, Hong Phuc Dang and Andre Rebentisch at FOSSASIA. I had a lot of learning adventures with experimenting and exploring with new ideas to build sensor plug-ins for ExpEYES. There were some moments which were disappointing and there were some other moments which brought the joy of creating sensor plug-ins, add-on devices and GUI improvements for ExpEYES.

My GSoC Gallery of Sensors and Devices: Here are all the sensors I played with for PSLab..

The complete list of sensor plug-ins developed is available at http://gnovi.edublogs.org/2015/08/21/gsoc-2015-with-fossasia-list-of-sensor-plug-ins-developed-for-expeyes/

Sensor Plugins for ExpEYES

The aim of my project is to develop new Sensor Plug-ins for ExpEYES to measure a variety of parameters like temperature, pressure, humidity, wind speed, acceleration, tilt angle, magnetic field etc. and to provide low-cost open source laboratory equipment for students and citizien scientists all over the world.

We are enhancing the scope of ExpEYES for using it to perform several new experiments. Developing a low-cost stand alone data acquisition system that can be used for weather monitoring or environmental studies is another objective of our project.

I am happy to see that the things have taken good shape with additional gas sensors added which were not included in the initial plan and we have almost achieved all the objectives of the project, except for some difficulties in calibrating sensor outputs and documentation. This issue will be solved in a couple of days.

Experimenting with different sensors in my kitchen laboratory

I started exploring and experimenting with different sensors. After doing preliminary studies I procured analog and a few digital sensors for measuring weather parameters like temperature, relative humidity and barometric pressure. A few other sensors like low cost piezoelectric sensor, accelerometer ADXL-335, Hall effect magnetic sensor, Gyro-module etc were also added to my kitchen laboratory. We then decided to add gas sensors for detecting Carbon Monoxide, LPG and Methane.

With this development ExpEYES can now be used for pollution monitoring and also in safety systems in Physics/chemistry laboratory. The work on the low-cost Dust Sensor is under progress.

Challenges, Data Sheet, GUI programs

I had to spend a lot of time in getting the sensor components, studying their data sheets, soldering and setting them up with ExpEYES. And then little time in writing GUI Programs. I started working almost 8 to 10 hours every evening after college hours (sometimes whole night) and now things have taken good shape.

Thanks to my mentor at FOSSASIA for pushing me, sometimes with strict words. I could add many new sensor plug-ins to ExpEYES and now I will also be working on Light sensors so that the Pocket Science Lab can be used in optics. With these new sensor plug-ins one can replace many costly devices from Physics, Chemistry, Biology and also Geology Lab.

What’s next? My Plan for next steps

Calibration of sensor data
Prototyping stand-alone weather station
Pushing data to Loklak server
Work on PSLab@Fossasia website
Fossasia Live Cd based on Lubuntu with ExpEYES and other educational softwares
Set-up Documentation for possible science experiments with the sensor plug-ins and low-cost, open source apparatus

searchQuick Apprise: SEVEN #GoogleSummerOfCode #FOSSASIA

Post author:Jigyasa Grover
Post published:August 18, 2015
Post category:FOSSASIA

The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

After the chief tasks of search functionality and automated build were done with, the next undertaking included working on finer details and embellishments.

Embedding Jenkins automated build status icon in GitHub markdown file
Relative widget re-sizing by using ‘World extent x‘ and ‘World extent y‘ co-ordinates instead of hard coded co-ordinates
Modifying the Accordion Widget by addition of ‘Search Bar‘ at the top
Checking for duplicates in the ‘Browse Files‘ menu, thus reducing the CPU consumption
Equalizing the sizes of all the windows to bring uniformity
Addition of ‘Scroll Pane‘ in accordion search result display list
Multi-line search result display by extending the Expander Title Morph and use of new line character in labels (otherwise not supported by default)
Truncating file content to first n characters for neater look in Expander Title

Latest Screenshot of Accordion Widget:

UPCOMING:

Removal of OK & CANCEL buttons (present by default in Pluggable Dialog Window) from Accordion Widget
Implementing of Search via the result window as well
Relative re-sizing of background images (Image Morphs)

Knitapps at the 7th Central American Free Software Congress ECSL 2015

Post author:tian2992
Post published:August 18, 2015
Post category:FOSSASIA

On August, 9th, in San Pedro Sula, Honduras, I presented at the seventh Central American Free Software Congress a talk on Knitting Machines, Knitapps, Free Software and Free Manufacture.

I had the opportunity to present on the main auditorium of Unitec, a private, technical university. The audience of the congress was compromised mostly of professionals and students from Central America. Local and National media also covered the event.

Exception handler in KnitLib

Post author:shiluka
Post published:August 14, 2015
Post category:FOSSASIA

An exception is an error that happens during the execution of a program. It is important to have exception handler in KnitLib to handle and deal with errors automatically. Many standard libraries define their own exceptions to report errors that may occur in functions they define. Depending on the kind of error in knitlib (“communication error”, “pattern not found error”, etc.. ). The exception handler module in the knitlib can handle the exception and the knitlib can be continued afterwards with the previously saved data.

Define exceptions as classes

Exception can be defined as classes which do any other class can do, but are usually kept simple, often only offering a number of attributes that allow information about the error to be extracted by handlers for the exception. When creating a library like KnitLib which can raise several distinct errors, a common practice is to create a base class for exceptions and subclass that to create specific exception classes for different error conditions.

Part of the Exception Handler Module, catch exceptions raise from the library

searchQuick Apprise: SIX #GoogleSummerOfCode #FOSSASIA

Post author:Jigyasa Grover
Post published:August 8, 2015
Post category:FOSSASIA

The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

The main task achieved was putting up the application up on Continuous Integration, Inria for automated build. It was indeed a beneficial idea as it helped me keep a check on the builds and work on issues.
Being a newbie, this work was cumbersome initially but with the help of my mentors and the #pharo community, I was able to accomplish it. To assist fellow Pharo-ers, I have compiled all the information regarding CI Automated Build for yout Pharo Application and published the same on my blog-spot. Kindly go through it for a complete understanding 🙂

Other tasks completed as of now include:

Putting up the project for automated build on https://ci.inria.fr/
Successful ‘stable’ and ‘development’ version builds
Accessing resource folder via MCGitHubRepository, Removal of manual download option
By default full screen system window open
Removing redundant code by creating open argument methods
Abolishment of hard-coded font family and font point size
Categorization of methods & classes
GUI Embellishment with background colors, borders etc.

Upcoming:

Dynamic widget re-sizing
Multi-line search result title
Putting up Help and About sections
Removal of old configurations

Importance of the test cases for the KnitLib

Post author:shiluka
Post published:August 6, 2015
Post category:FOSSASIA

Having test cases is very important especially for a library like KnitLib because using test cases; we can clearly test particular fields. In KnitLib, test cases show the information of how the KnitLib should be checked. Also test cases help for new contributors to understand about the KnitLib.

There are several test cases for the current KnitLib implementation such as tests on ayab communication, tests on ayab image, tests on command line interface, tests on KnitPat module and tests on knitting plugin.

For an example in ayab communication there are several important functions have been tested. Test on closing serial port communication, test on opening serial port with a baud rate of 115200 which ayab fits, tests on sending start message to the controller, tests on sending line of data via serial port and tests on reading line from serial communication. Most of these tests have been done using mock tests. Mock is a python library to test in python. Using mocks we can replace parts of our system with mock objects and have assertions about how they have been used. We can easily represent some complex objects without having to manually set up stubs as mock objects during a test.

It is very important to improve further test cases on the KnitLib because with the help of good test cases we can guarantee that the KnitLib’s features and functionalities should be working great.

Regards,

Shiluka.

searchQuick Apprise: FIVE #GoogleSummerOfCode #FOSSASIA

Post author:Jigyasa Grover
Post published:August 1, 2015
Post category:FOSSASIA

The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.

As the rudimentary structure of the application is sewn up, embellishment of GUI and rigorous testing are the major part of course of action.

On eMBee’s ( +Martin Bähr ) suggestion to build up an accordion widget to display the search results, various trials were conducted to design a similar one in Pharo.

The task of developing the accordion widget in Pharo was achieved using Expander Morphs. Looping through the search results array, a #newExpander: was added in each #newRow: of the modal built.

A challenging chore was to add a scroll-able content on the click of the desired search result expander. Sundry experiments with #newLabel: and #newText: in #newScrollPaneFor: {i.e. adding text model and labels in scroll pane} had no effect. Eventually, #newTextEditorFor: did the trick and the desired look was created.

Next on the cards is putting up sQuick for automated build on the CI Server, as suggested by +Sean DeNigris for its various advantages which include:

Improvement of product quality
Acceleration of compile and link processing
Elimination of redundant tasks
Minimization of ‘bad builds’
Have history of builds and releases in order to investigate issues
Save time and money – because of above listed reasons.

For simplicity, Build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities including things like:

compiling computer source code into binary code
packaging binary code
running automated tests
deploying to production systems
creating documentation and/or release notes

UPCOMING:

To achieve Build Automation for sQuick, I have already registered on CI and configured sQuick.
Next endeavor is to look into the red signal in the build evaluation.

Stay tuned for more….Post any queries, will be happy to help 🙂

More about sTeam’s command line interface

Post author:Trilok Tourani
Post published:July 31, 2015
Post category:FOSSASIA

This post will take you through some interesting work that I have been doing for my project under FOSSASIA. This project is being done under the google summer of code platform. I have been working on various code scripts as my project is all about improving the tools of the sTeam collaboration platform. But this particular script is a command line interface that I am thrilled to work on.

If you are not familiar with what sTeam is, you can look it up here, sTeam

Let me start with how sTeam originally works for any user. This picture will give you a clear view about it.

If you are new to the sTeam platform, this script will take you through the sTeam commands and the interface, also making sure, you have fun in the process. It lets the user play with sTeam and get to know more about how it works. One other interesting concept that we have tried to integrate here is that of MUDs(Multi user dungeons/dimensions). Some of you may already be familiar with the concept of MUDs( others, please look it up here MUD). We have tried to bring the MUD kind of experience to this sTeam interface (like I said, thrilling!).

I have seen people go through a lot of tutorials on git, and the commands(sometimes complex) through which it operates, and yet, people have difficulty learning it. What if it had a MUD type of interaction, which would just let you type “create file” “commit file” “get commit content” “upload file” “rename file” “goto repo”, etc. Wouldnt it be much easier that way? Well, sTeam is going through all the extensive tool development so that it can make a user-friendly interaction. Here are some screenshots of this interface,

This interface is under heavy development and plans to make sTeam more and more interesting for its users. If you have any questions on sTeam, please feel free to contact me, or join us on our daily scrum meetings on IRC (#steam-devel) or join #fossasia and ping us with a question.

If you are looking for a open source project and want to contribute to FOSSASIA, Please have a look at FOSSASIA labs.

Dockerizing sTeam

Post author:Jai Pradeesh
Post published:July 31, 2015
Post category:FOSSASIA

I am currently working with sTeam collaboration platform as a GSoC dev under FOSSASIA umbrella.

sTeam has a lot of depencencies. A lot! One major issue faced by developers was version conflict between dependencies. Docker seemed to solve this issue. Docker is a great image distribution model for server templates. It uses btrfs (a copy-on-write filesystem) to keep track of filesystem diff’s which can be committed and collaborated on with other users (like git). It also has a central repository of disk images that allow you to easily run different operating systems and shares the host kernel.

In this post, I will explain the workflow of containerizing sTeam with Docker.

Prepend sudo

Install docker on host system, start & enable the docker.service

dnf install docker
systemctl start docker
systemctl enable docker

Pull a base image from docker hub

Note: It is upto you which image to use. I am using Ubuntu as base image.

docker pull ubuntu:latest

List the images to verify the pull

docker images

.. should display ubuntu latest xxxxxxxxxxxx x months ago x MB

Build your own image

docker build -t="dolftax/steam"

Lets run bash to install sTeam itself and its dependencies

docker run -t -i dolftax/steam /bin/bash

Install the packages and its dependencies.

In my case, sTeam server. Installation steps –https://github.com/societyserver/sTeam/wiki/Installation-steps#manual

Grab latest container ID. The first one would be the recently closed container.

docker ps -a

Commit the changes so that you don’t lose the data when container exits

docker commit [container-id] dolftax/steam:v1

You should get a long hash as the success message

Note: v1 is a tag Don’t use latest tag. Don’t be tempted by it.

Create a docker hub account and login

docker login

.. which is self explanatory.

Push the image to docker hub (Before that, create a docker hub account anddocker login)

docker push dolftax/steam

Done!

.. after containerizing with docker, sTeam installation is as easy as

docker pull dolftax/steam:v1

Try containerizing your project and you would love it.

How to use Open Event framework to host your event website and app

Post author:championswimmer
Post published:July 20, 2015
Post category:Event Management Open Event
Post comments:0 Comments

So, we intended to write “Open Event” to allow event/conference organisers to be able to have their own website, and android app without having to code or build them. Our GSoC project is not yet complete, and we are adding new feartures everyday, but it is at a stage where, if you have a small event to host in your school or something, you can take a shot at it, to get versed with how the server works and how the app and website is generated.

The “Open Event” system consists of a server (code), where organisers make an event database, and add list and details of all speakers, sessions, sponsors, locations etc.

We currently have a dev and staging server set up, where organisers can create an account and try out the interface. Neither of these servers are production servers, and their databases keep getting reset when we change code, so use them only to learn how the server dashboard works for now, not to host your final event data.

Next, the organisers might want to have a webapp (code). The webapp is just a responsive, mobile friendly website that shows the details of the events in a easily readable format for the attendees. To create your own webapp, you need to fork this repository and adjust the parameters of the config.js to represent your app.
var config = { "title": "OpenEvent", // Title of your event.

“apiBaseGetUrl”: “http://open-event.herokuapp.com/get/api/v1/”, // Base URL of the orga-server from where data comes.

“eventId”: “3”, // The event-id of your event
.
“use_testApi”: false // Must set to false, or else uses testcase json files.
};

After changing the config.js, you can deploy the webapp on any webserver that supports hosting static files (example bitballoon.com), or you can host it via github by creating a gh-pages branch, like the example app.

Next, the organisers, can create and deploy an android app (code) for their event. There are some automated configuration options still left to be manipulated, but organisers need to change the BASE_URL variable, in the Urls.java file to point to the data server, and change the package name to their liking in build.gradle. The app can be built using the command ./gradlew build . We have a FDroid flavour, that uses Open Street Maps instead of Google Maps and is completely and purely FOSS.