Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

Difference between revisions of "OLP SOC Ideas Page"

From wiki.openlighting.org

Jump to: navigation, search
m (OLE ideas)
 
(42 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2012 Google Summer of Code 2012] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2012 timeline.
+
This page lists some ideas for [https://summerofcode.withgoogle.com/ Google Summer of Code 2016] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2016 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself. You can also see what projects [https://www.openlighting.org/openlightingproject/get-involved/gsoc/ past students] did.
  
 +
Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].
  
==Port to Windows Platforms ==
+
=Open Lighting Architecture Ideas=
 +
Ideas for [https://www.openlighting.org/ola/ OLA].
 +
== Adding RDM support to the "new" Web UI ==
  
This is the most requested 'feature' and would significantly expand the reach of the project. The current, supported method of running OLA on Windows is using VMWare  ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these Notes]]), but was postponed due to lack of resources.
+
This project would include:
 +
* Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
 +
* Adding support to render the generic JSON returned by the back-end
 +
* Adding support for Ack Timer packets in the RDM flow
 +
* Adding support for additional parameter IDs or (PIDS).
 +
'''Skills Required''': HTML, Javascript, C++ <br/>
 +
'''Estimated Difficulty''': Medium
 +
 
 +
== Adding support for more RDM PIDS to the Web UI(s) ==
 +
 
 +
Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.
 +
 
 +
This project would include:
 +
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
 +
* Adding support for Ack Timer packets in the RDM flow
 +
* Adding support for additional parameter ids or (PIDS).
 +
'''Skills Required''': HTML, Javascript, C++ <br/>
 +
'''Estimated Difficulty''': Medium
 +
 
 +
== Raspberry Pi UI ==
 +
 
 +
The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.
 +
 
 +
This project would include:
 +
* Designing, writing and testing the new UI
 +
<br/>
 +
'''Skills Required''': Python ? <br/>
 +
'''Estimated Difficulty''': Easy
 +
 
 +
== RESTful API ==
 +
 
 +
The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.
  
 
This project would include:
 
This project would include:
* Refactoring the base classes under [http://code.google.com/p/linux-lighting/source/browse/#git%2Fcommon%2Fnetwork common/network] to use the Windows network & event management APIs and ensuring that all unit tests pass.
+
* Writing and testing the new API
* Cleaning up various parts of the code which use POSIX APIs (see http://code.google.com/p/linux-lighting/issues/detail?id=139 for an example)
+
* Modifying our current Web apps to use the new web API
 +
<br/>
 +
'''Skills Required''': C++, Javascript, HTML, JSON <br/>
 +
'''Estimated Difficulty''': Easy
 +
 
 +
== Web Based Configuration of Preferences ==
  
A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.
+
User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed.  This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.
  
'''Skills Required''': C++, Windows Network Programming <br/>
 
'''Estimated Difficulty''': Hard
 
  
 +
 +
'''Skills Required''': C++, Javascript, HTML  <br/>
 +
'''Estimated Difficulty''': Easy
  
 
== Asynchronous Web Notification of RDM Messages ==  
 
== Asynchronous Web Notification of RDM Messages ==  
Line 22: Line 62:
 
The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].
 
The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].
  
'''Skills Required''': C++, Network Programming, Javascript, HTML, Google Closure<br/>
+
 
 +
'''Skills Required''': C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure<br/>
 
'''Estimated Difficulty''': Medium
 
'''Estimated Difficulty''': Medium
  
 +
==Port to Android==
 +
 +
Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.
  
== Web Based Configuration of Preferences ==
+
This project would include:
 +
* Building OLA as a Android Application
 +
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.
 +
* Writing a frontend in Java to demonstrate the capabilities of OLA.
 +
 
 +
 
 +
'''Skills Required''': C++, Java, Android <br/>
 +
'''Estimated Difficulty''': Hard
 +
 
 +
==Continue Porting to Windows ==
 +
 
 +
This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare  ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA.  Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.
 +
 
 +
Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.
 +
 
 +
A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.
 +
 
 +
<br/>
 +
 
 +
'''Skills Required''': C++, Windows Hardware Programming<br/>
 +
'''Estimated Difficulty''': Hard
 +
 
 +
== Patcher v2 ==
 +
 
 +
Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.
 +
 
 +
See [[issue:280|issue 280]] for some additional features and thoughts.
 +
 
 +
'''Skills Required''': C++, Javascript, HTML<br/>
 +
'''Estimated Difficulty''': Hard
 +
 
 +
 
 +
=Open Lighting Embedded (OLE) Ideas=
 +
Ideas for [https://www.openlighting.org/ole/ OLE].
 +
 
 +
== DMX in mode ==
  
User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, exit the text files and restart if settings are to be changed.  This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.
+
OLE currently only supports DMX out from the ports, add support for DMX input too.
 +
See [[ja-rule-issue:99|issue 99]] for some additional thoughts. You'd also need to make the additional changes to OLA to support DMX input via Ja Rule.
  
'''Skills Required''': C++, Javascript, HTML  <br/>
+
'''Skills Required''': Embedded C, C++<br/>
'''Estimated Difficulty''': Easy
+
'''Estimated Difficulty''': Hard
  
 +
== Second Port Support ==
  
== Web Based RDM Tests & Integration with the RDM Index ==
+
OLE currently only supports DMX/RDM out from the first port, add support on the second too.
 +
See [[ja-rule-issue:251|issue 251]] for some additional thoughts. You'd also need to make the additional changes to OLA to support the second port. [[ja-rule-issue:226|Issue 226]] details the plan to detect if the unit is a one or two port device. It would also be good to make use of DMX input on both ports as mentioned above.
  
The [[RDM Responder Testing][Automated RDM Responder Tests]] have been very popular in the industry and are used by many manufacturers to test their products prior to release. At the moment the tests are run from the command line and rely on the test engineers to write scripts to post process the test output. Building a web UI for the tests would make them easier to use for the manufacturers and give us the ability to provide more control over how the tests are run.
+
'''Skills Required''': Embedded C, C++<br/>
 +
'''Estimated Difficulty''': Medium
  
The second part of this project covers the [http://rdm.openlighting.org/ RDM Product Index], a website that collects information on [[RDM]] enabled products and make it freely available. The work would be to expand the [http://code.google.com/p/linux-lighting/source/browse/tools/rdm/model_collector.py model_collector.py] script to automatically upload new responder data to the site, and build a system for a human to sanity check the new data before publishing it.
+
== Sniffer mode ==
  
 +
It would be very useful to be able to use OLE as a DMX/RDM sniffer.
 +
See [[ja-rule-issue:103|issue 103]] for some additional thoughts. You may also need to make additional changes to OLA to support the sniffer mode.
  
'''Skills Required''': Python, HTML, Javascript <br/>
+
'''Skills Required''': Embedded C, C++<br/>
'''Estimated Difficulty''': Easy
+
'''Estimated Difficulty''': Hard

Latest revision as of 06:50, 18 February 2016

This page lists some ideas for Google Summer of Code 2016 projects for the Open Lighting Project. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2016 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the Open Lighting List introducing yourself. You can also see what projects past students did.

Please also read our GSOC Application Guide.

Open Lighting Architecture Ideas

Ideas for OLA.

Adding RDM support to the "new" Web UI

This project would include:

  • Adding support for RDM discovery to list devices and sub-devices in the UI and extending the existing supporting code in the web server back-end where necessary
  • Adding support to render the generic JSON returned by the back-end
  • Adding support for Ack Timer packets in the RDM flow
  • Adding support for additional parameter IDs or (PIDS).

Skills Required: HTML, Javascript, C++
Estimated Difficulty: Medium

Adding support for more RDM PIDS to the Web UI(s)

Our current "old" Web UI lacks support for a lot of the really cool parameters and features that RDM is capable of (our "new" Web UI currently lacks all RDM support, but see the idea above for that). The main task of this project would to add support for RDM sub-devices and Ack Timer.

This project would include:

  • Adding support for RDM sub-devices in the UI and supporting code in the web server back-end
  • Adding support for Ack Timer packets in the RDM flow
  • Adding support for additional parameter ids or (PIDS).

Skills Required: HTML, Javascript, C++
Estimated Difficulty: Medium

Raspberry Pi UI

The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.

This project would include:

  • Designing, writing and testing the new UI


Skills Required: Python ?
Estimated Difficulty: Easy

RESTful API

The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.

This project would include:

  • Writing and testing the new API
  • Modifying our current Web apps to use the new web API


Skills Required: C++, Javascript, HTML, JSON
Estimated Difficulty: Easy

Web Based Configuration of Preferences

User Preferences for OLA are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.


Skills Required: C++, Javascript, HTML
Estimated Difficulty: Easy

Asynchronous Web Notification of RDM Messages

Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. RDM enabled lighting devices can generate events such as Over Temperature and Lamp Faulty so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with libmicrohttpd to add WebSocket support (see the email thread).

The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The OLA UI is built with Google Closure.


Skills Required: C++, Network Programming, Javascript, HTML, AngularJS and JQuery or Google Closure
Estimated Difficulty: Medium

Port to Android

Android is an obvious target for OLA. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see OLA on Android. Bug #222 covers this work.

This project would include:

  • Building OLA as a Android Application
  • Adding a Java client or wrapping the C++ client with a Java library.
  • Writing a frontend in Java to demonstrate the capabilities of OLA.


Skills Required: C++, Java, Android
Estimated Difficulty: Hard

Continue Porting to Windows

This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare (instructions). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see these notes), but was postponed due to lack of resources.

Lukase has got the core and network functionality working on Windows as part of GSOC 2014, but support for hardware interfaces is still missing, as well as one or two network plugins.

A Windows port would enable lighting controller applications like QLC and D::Light to move to OLA entirely, and not have to maintain their own plugins.


Skills Required: C++, Windows Hardware Programming
Estimated Difficulty: Hard

Patcher v2

Patcher v2 is one of the next big projects for OLA it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.

See issue 280 for some additional features and thoughts.

Skills Required: C++, Javascript, HTML
Estimated Difficulty: Hard


Open Lighting Embedded (OLE) Ideas

Ideas for OLE.

DMX in mode

OLE currently only supports DMX out from the ports, add support for DMX input too. See issue 99 for some additional thoughts. You'd also need to make the additional changes to OLA to support DMX input via Ja Rule.

Skills Required: Embedded C, C++
Estimated Difficulty: Hard

Second Port Support

OLE currently only supports DMX/RDM out from the first port, add support on the second too. See issue 251 for some additional thoughts. You'd also need to make the additional changes to OLA to support the second port. Issue 226 details the plan to detect if the unit is a one or two port device. It would also be good to make use of DMX input on both ports as mentioned above.

Skills Required: Embedded C, C++
Estimated Difficulty: Medium

Sniffer mode

It would be very useful to be able to use OLE as a DMX/RDM sniffer. See issue 103 for some additional thoughts. You may also need to make additional changes to OLA to support the sniffer mode.

Skills Required: Embedded C, C++
Estimated Difficulty: Hard