djpetti / grobot Goto Github PK

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.

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.

This should be changed in the schematic. We should select a chip that is similar to what is on the dev board.

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.

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.

Here are some issues that I have discovered with the hardware design over the course of testing the system:

• The resistor for the water temp should not be 12k. 12k is optimal if you want to read in a 25 to 80C temperature range. For the water temp, we want a range of more like 0C to 65C. We should figure out the correct resistor for this and fix it.
• We need a way to put the PSoC into bootloader mode without having to physically press the button.

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.

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 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.

This is probably one of the more difficult sensors, but it has to be done eventually.

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 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:

• Checking temperature sensors for reasonable values.
• Checking air temperature and humidity for reasonable values.
• Checking water temperature for reasonable values.
• Checking water EC and pH for reasonable values (assuming there is water.)

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.

This card will be the main interface through which we manage actual plant growth. It should allow for the following:

• The user to add or remove a particular type of plant.
• The user to see, at-a-glance the status of a particular plant type.

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.

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:

• Each module initially starts with a permanent ID set to zero. The permanent ID must be stored in flash. You'll probably have to use the PSoC's fake EEPROM component to make this work.
• Modify the IMALIVE message so that it include the currently set permanent ID as one of the fields.
• When the uC receives a GETPERMID message, it should send back a GETPERMID message with the currently set permanent ID as the sole field.
• When the uC receives a SETPERMID message, it should read the first field as an unsigned 32-bit integer, and set that as the permanent ID. This should also trigger a write to flash.

This is not especially high-priority, but Polymer 2.0 is actually a thing, so we should probably transition to that eventually.

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.

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.

There is currently some discrepancy between the schematic and how everything is actually connected. We should probably fix that before moving on.

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.

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.

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:

• Requesting and interpreting raw data points from the backend, over the existing WebSocket connection.
• Allowing the user to arrange multiple graphs in a flexible "dashboard".
• Allowing the user to change the size, color, etc. of a particular graph.
• Allowing the user to change the scale of any graph axes.
• Allowing the user to plot multiple data streams on a single graph.
• Updating in realtime.
• Exporting a CSV, ideally.

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.

It would be nice to add logging capabilities to the MCUs, which could greatly facilitate debugging. Such a system should function as follows:

• Each MCU should log data when some sort of "debug" mode is enabled. Ideally, this should be something that can be enabled with a specialized command.
• MCUs should send log messages using the existing messaging interface, which should not be difficult.
• Prime should receive the log messages, and integrate them into the existing log file for the web interface.

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.

We need to be able to talk to the DHT11. The relevant code should be in the "psoc" branch.

DHT11 Datasheet

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.