djpetti / grobot Goto Github PK
View Code? Open in Web Editor NEWSoftware for the GroBot project.
License: MIT License
Software for the GroBot project.
License: MIT License
There is currently some discrepancy between the schematic and how everything is actually connected. We should probably fix that before moving on.
It would be nice to have another prototype grow module to test with. For someone interested in getting their hands dirty, I can give them the CAD necessary to build another one. This project should cost under $100, and I will reimburse RCOS members.
This is not especially high-priority, but Polymer 2.0 is actually a thing, so we should probably transition to that eventually.
This is a frontend task for someone who wishes to get really deep into JS.
One of the advantages of GroBot is that it has so many sensors. Ideally, I'd like a power user to be able to display graphs of arbitrary sensor readings over time. The front-end component of this task involves a flexible UI that has to support various things:
All of this should be done in a way that is intuitive, but still powerful. This seems like an ideal use for Polymer's "card"-based UI.
This should be changed in the schematic. We should select a chip that is similar to what is on the dev board.
It would be nice to add logging capabilities to the MCUs, which could greatly facilitate debugging. Such a system should function as follows:
This card will be the main interface through which we manage actual plant growth. It should allow for the following:
Note that this is actually really two tasks, which can be worked on separately. Someone can do the JS frontend work, and someone else can do the backend, which, in this case, is not trivial.
Until now, the MCU code has been suspiciously devoid of unit tests. This is because unit testing embedded code is difficult. However, it is possible.
Using ceedling in conjunction with the Fake Function Framework, it should be possible to create some simple unit tests that can run on the host computer.
Someone should go through the MCU code, identify points that can easily be unit-tested, write tests for them, and fix/report any uncovered bugs. Ideally, the tests should be run automatically from "deploy.py" as well.
We just need to write some code for this. To my knowledge, there's nothing physically wrong with the hardware. Both of the sensors are resistive, so this shouldn't be all too difficult.
This is probably one of the more difficult sensors, but it has to be done eventually.
Right now the process is a little... convoluted.
Ideally, this tool would be able to do things like run Closure, as well as doing all the Polymer stuff. It would produce output that is ready to be deployed in a production environment.
When you run the unit tests currently, you get a message like this from Polymer WCT:
warn: [polymer-project-config] "includeDependencies" config option has been renamed to "extraDependencies" and will no longer be supported in future versions
This should be fixed.
Currently, there are certain Redux actions that have side-effects other than updating the state. This makes testing difficult and debugging annoying. I will be removing them through the use of redux-saga.
Here are some issues that I have discovered with the hardware design over the course of testing the system:
We really need CI at some point, since we actually have a testing procedure. Someone just needs to sit down and make this work at some point.
I've (mostly) finished the schematics for the new base module hardware, however, these need to be verified, and the circuit board layout needs to be done.
This is a useful Wiki page for anyone interested.
The schematics for the grow module controller haven't even been started yet. That can be done as well.
This is a useful Wiki page for anyone interested. Right now it's more focused on the Base Module design, but some stuff is still relevant.
The persistent testing option is useful when trying to debug failing tests. However, to use it, you currently have to run polymer test -p
manually. It would be nice if there was an option for this from deploy.py
.
Permanent IDs are a special number that is stored in flash on the MCU in each module. They are not used for communication, but rather to identify modules across reboots so that settings, (e.g. what's growing in the module) can be preserved. I've already implemented the SBC side of this functionality, but the uC side still has yet to be done.
Specifications:
This is a pretty easy task.
It would be nice to have a basic POST sequence for the MCUs. This might include, but is not limited to:
Assuming the POST sequence fails, probably the best course of action to take is to notify Prime. You can create a special message type for this.
We need to be able to talk to the DHT11. The relevant code should be in the "psoc" branch.
This also shouldn't be too hard, and I have done some of the work.
A simple EC sensor can be recreated using a power plug and a few resistors. The prongs of the plug are immersed in the solution, and act as one side of a voltage divider. Then the MCU does some math to convert the read voltage into an EC estimate.
For calibration, a set of ionic solutions of known concentration should be used. I have used NaCl in the past, which works well, and is easy to make. The probe can be connected to an MCU dev board, inserted into the solutions, and the raw values from the ADC can be read and measured. Then, we can do some math to find the best values for the calibration constants.
The code for reading EC values already exists, so not much coding is involved in this task. However, the tester must understand how the existing code works. This, therefore, would make a good starting project for someone who wishes to gain familiarity with the MCU source code.
The modules are supposed to communicate via an I2C system which is fairly intricate, but has never been fully tested due to lack of hardware. Testing, however, would be fairly simple, one would need merely to buy two PSoC dev boards and wire them together properly. Aside from basic testing, the module discovery process should be specifically verified.
The action panel is one of the main parts of the web interface. It displays a quick overview of the system status, with priorities given for anything that requires user action.
Right now it's just a mockup.
Right now, the small amount of code that forms the body of the Saga is not tested, because it's kind of annoying to test. That should change, as any bugs there can easily break the whole application.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.