- Description
- Roadmap
- Questions (for end user)
- General Development Practices
- Configuration
- Troubleshooting
This application seeks to be the best way to scan ELISA plates and record measurements.
It’s able to scan a plate and record the RGB values of each individual vial while compensating for differences in lighting and camera.
The application should be able to detect the plate without reading from external sources. It would be a good idea to show the user taking the photo that the plate has been detected so as to avoid taking a blurry photo and seeing skewed results.
The application should be able to take some image of the plate and identify each of the individual vials on the plate.
It should record the RGB values in some standardized format.
The application should (ideally) be able to normalize the color values of the plate to be able to obtain an accurate reading of the color values.
It would be useful to the researchers to provide an interface through the application to view normalized pictures of plates and view the RGB readings as labels of some sort corresponding to each vial through the application.
It would also be useful to store this information in a human-interpretable table, likely in .csv format, and to be able to back up and/or export this information.
This information can be provided through an accompanying web application and mobile application that will allow users to take a photo or upload an image, then receive a response - either that the image was malformed and we could not detect it, or the successful results presented from the analysis of the plate.
- How would you like the information displayed?
We should prepare several suggestions and diagrams for this when initially
meeting with the researcher. How they view the data for the readings is just
as important as their ability to record the readings through our application;
if they are not able to view the results, they have gotten nothing!
Response: so far, whatever we are able to accomplish and present in terms of data visualization will be neat for the researcher to see; after we develop a clear front-end produce to show them, they will likely provide further feedback on this design upon which we can iterate.
- What information do you need? e.g. RGB values, original image of the plate, normalized image of the plate
- Will you be able to use the same smartphone for each reading?
- Could this smartphone be an Android smartphone? The researcher has an iPhone, but we can hopefully compile the application for a cross-platform framework upon which we can scaffold the app.
- Will the lighting condition be consistent?
It’s much more difficult to obtain consistent readings if we cannot rely upon
consistent lighting conditions. Normalizing the lighting is an interesting
problem, but may fall outside of the scope of this project.
So far, we have logic to ensure that the background is dark in color, but whether the background is cool is unclear.
We’ll be using git, GitHub and Slack for our development.
- Never commit directly to master.
Our flow will work approximately as follows:
- When we come together for our first weekly meeting, we’ll discuss what each individual on the team wants to contribute to the project and what they’d like to learn from it. This will determine the roles and assignments each team member will take on for the duration of the project.
- From these, we’ll collectively break these problems down into smaller parts. Each part will be defined as an ‘issue’ on GitHub that describes the problem in detail and some suggestions for paths to take to solve it. Each individual issue should take no more than 10 hours to complete, and it should be completed within a week. If there are multiple tasks that will take just an hour or two to complete, multiple tasks will be created for the week and all assigned to the individual responsible.
- When working on your issue(s) for the week, for each issue, create a branch
(
git checkout -b <branch-name>) with the branch name approximately matching the issue. - After the feature has been completed in the branch, do not push to master. Instead, head to GitHub and create a pull request to merge the branch into master. In the body of the request, describe what you accomplished and give a brief overview of how you solved the problem. Also provide comprehensive instructions for others to test your code or otherwise verify that it functions correctly.
- To merge into master, a pull request will require 2/3 of the other members of the team (added as ‘reviewers’ to the pull request) to approve the code. These can be obtained more quickly by kindly poking your team members on Slack. If they bring up any issues with the pull request, they should probably be fixed and re-checked before the branch is merged.
- Commit often.
(
git add <changed-files> ; ~git commit -m "relevant commit message to changes made"). Commit whenever you’ve written some code important enough to be described at a high level in a few words (as the commit message). Make sure these commit messages are informative so other developers on the team are well-informed of the work done when reviewing pull requests.
Further, if you have any issues with git or GitHub, whether it’s deleting your local branch and all of your work or accidentally pushing your dependency files to GitHub, don’t hesitate to reach out - we can work through it together.
- We’ll be communicating via Slack for everything not directly pertaining to the code written; this includes setting up meetings, checking in on progress, getting food, or any number of other things relevant to the project.
- I’ll have the Slackbot send a reminder to our channel for a mid-week checkin; please respond to this message with your progress for the week, including any potential blocks. This should be completed sometime on Wednesdays and is your best oppportunity to get help with build scripts, dependency errors, or whatever error might be occuring with your project.
- I will always be available on Slack in the evenings to help out - feel free to ask me any questions you may have at any time if you have questions, concerns, or want advice with regards to the project, Sandbox, Computer Science at Northeastern or anything else really.
- Though we are set to put together a project by the end of the semester, the most important part of this extracirricular activity is to enjoy it and learn from it! As such, if you’re frustrated with your role in the project, please check in with me and we can work together to find a new task for you for the week or change your role on the team to more closely match your interests.
How to configure this module, including common problems and how to address them.
We’ll start by configuring a virtual environment in which we can safely install dependencies.
Installing virtual environment: “`python -m pip install –upgrade –user pip setuptools virtualenv“`
Creating the virtual environment and activating it: “` $ python -m virtualenv ~/kivy_venv $ source ~/kivy_venv/bin/activate $ virtualenv <env_name> “`
Starting the virtual environment! “` $ source <env_name>/bin/activate “`
Installing all of the requirements(if there is a folder present): “`(<env_name>)$ pip install -r path/to/requirements.txt“`
If this is successful, an indication that you’re in the virtual environment kivy_venv should be present to the left fo your prompt.
Follow the instructions for your system as specified by kivy’s website. deviating from the instructions:
pip install kivy kivy_examples –pre –extra-index-url https://kivy.org/downloads/simple/
instructions say this may work on anaconda, but i don’t would not recommend using anaconda unless on windows (bloated, annoying to configure, not ‘unix-like’) “` conda install kivy -c conda-forge “`
Common issues and their solution, or places to look for help. Update this as you run into issues building the project and find solutions!