Welcome back! This week has been more testing of the system, fixing small bugs, calibrating different part of the system such as plant mover and plant information node. We have tested several part of the system. We are exited to make videoes and pictures of the whole system next week to show what we have done!

Shahin Ostadahmadi

Along with the team, we did several tests of the whole system over and over.

Nutrition controller

I completed the software side for the nutrition controller and prepared everything for testing. I connected all components, including pipes, valves, nutrition and water pumps, and sensors, and was ready to test. However, we faced an issue with the valves requiring a minimum pressure of 0.2 bar to function, which wasn’t feasible due to our nutrition box’s height limitations. After attempting to modify the valves and failing, I ordered new ones that don’t require a minimum pressure.

We were able to test parts of the system, but encountered another problem: the water input exceeded the outflow. Fortunately, we had a Non-contact Capacitive Liquid Level Sensor. I planned to use an AND-chip connected to the liquid level sensor and to the relay which controls the water pump, so when the water reaches a certain level, the pumps will shut down until the water is below the sensor. Ivan arrived at the perfect time! we tried to integrate the sensor and AND gate into the system. Despite multiple attempts, it didn’t work initially due to the sensor requiring an analog-to-digital converter (ADC). We used an old Arduino to convert the analog signal to digital, which resolved the issue. After four hours of testing, everything finally worked.

Library

I debugged almost the whole system for three hours to look for the wired behavior in our system when I was testing the nutrition controller. Finally, I found out that there was an issue with the Equipment which is a custom container that can hold Entities (Sensors, Actuators, and Logic controller). The class Equipment has interfaces such as:

• equipment.sensors: returns a list of the sensors in the equipment container
• equipment.actuators: returns a list of the actuators in the equipment container

It turns out that these interfaces returned the wrong objects! I fixed this issue a long time ago, but we had some git problems a while ago and I lost some of my commits, so this was one of the commits that I lost and did not think about it. Thanks to Ole and Oscar for debugging with me.

Gui

I refactored some of the implementations and made some changes to the “Mqtt test page”. It is simpler to communicate directly with part of the system with JSON formatted messages which makes it easier to test the system faster.

I also implemented a new page for fetching and displaying the last image from the plant prediction server. We can now see the picture and the result from the plant prediction module right away.

Snap-on command

I’ve updated the software with new classes designed for the prediction and stage determination of plants. The predicted class uses image manipulation by scanning the green pixels of the picture and creating a mask, and it seems to fit our purpose for now. The sequence of scanning the picture and visualizing it looks as the sequence diagram below:

Snap-on command has also the following API:

• The last annotated picture on IP/picture
• Streaming on IP/video_feed

Plant recognition by pixel manipulation

The filtering works fine for now, but in my opinion, we can rely on pixel manipulation in the future because too many uncertain aspects such as some plant light combinations in our system can reflect green pixels to the camera. However, this is a good method for us to automate some of the work of making a good dataset to train a machine learning algorithm such as U-NET, which requires masks for the pictures. Here are some of the testing pictures with different filtering methods provided by OpenCV(I will provide pictures from our system in the final blog):

Commits

https://github.com/hydroplantno/water-node/commit/8ddbd7b50dc70bbc0dc6dc1e719b945327ae980fConnect your Github account

https://github.com/hydroplantno/snap-on-command/commits/video_setting/shahin

https://github.com/hydroplantno/gui-node/commit/000c70ecba644ec317b7642623b9371e0aeb2e98Connect your Github account

https://github.com/hydroplantno/library/commit/1d7bc1a0087533f8bc519eaef0006752d66d2035Connect your Github account

Oscar Melby

Last week I wrote about restructuring master-controller a bit, this week I’ve tackled the autonomy part and fixed some more bugs which were introduced in the restructured version.

Job scheduling & handling

In the previous version I just sent job after job and waited for the receipt to be done or partially done. This was all fine and well, but wanted to have something a bit more clear, as when gathering receipts would just be a long list (up to 100) of receipts which would be looped through and to the delete the sent job.

Now I’ve made a class Job which consists of a list of Steps. Reason for this is we will do things such as stop waterflow for a given stage, and move the plant holder to another stage and then turn on water again. We would of course need to wait in between these “steps” as we need time for the water to empty. Each step therefore has a “wait”-value and deadline. “Wait”-value is the time we should wait before doing something else AFTER the step has finished. Deadline is the maximum time a step or job should take. If it is not done within this time, we should just delete it. This is done do prevent the system from halting every other action, and for reliability reasons. We might lose jobs, but this is unimportant since we scan the system and can pick up on the task again later on.

Each job goes through multiple states. First it is Queued then Pending and depending on what happens could either be Done or Killed after that. This keeps track of what is happening and makes job handling a lot easier to read.

There is also a difference between interval jobs (such as turning on and off the lights) and jobs which just gets added along the way (moving plantholders).

Did a lot of testing and debugging of this new implementation. There were not a lack of bugs. Here are couple:

• When starting up there would be a million jobs added, even though I checked for duplicates. After a while these jobs would delete themselves, but would take a long time.
• When a node reconnected their actuators and logic controllers would duplicate. This was due to our broker not sending the disconnect message fast enough, so we would not delete the entries just add them again.
• When (only) nutrition node disconnected every belonging entity would delete except for one. This was due to my misunderstanding of how Python dealt with for-loops as I didn’t think I would need to do a copy of the list in this scenario. Turns out I was wrong, when deleting in the list while looping it you would skip an index which caused the one entity to not delete.

Fixed all of these, but there are most probably more bugs just waiting to be discovered.

Nutrition node

Also worked with Shahin this week debugging some things and setup support for nutrition node on master-controller’s end.

Commits

Only members of the organization can view these commits.

https://github.com/hydroplantno/master-controller/commit/511d0b027136efe1936b7b0230f9bf281c356aab

https://github.com/hydroplantno/master-controller/commit/06fbfcbcfd9f7170b317f362dc2f26b2db80ebbf

https://github.com/hydroplantno/master-controller/commit/07c08d2f89353a79c11d880ea761ab2445f0b5fb

https://github.com/hydroplantno/master-controller/commit/92be0d4af811254b7139bb1c521fae16c683181b

https://github.com/hydroplantno/master-controller/commit/cd95cac0061e18269d5d4886c74950af0924eb28

https://github.com/hydroplantno/master-controller/commit/c07426cea20cfb42bec1e3fbb218147772e7502c

Aditi Deshpande

Last week, I uploaded my UNET code on GitHub with the dataset correction, the utilization functions, the training, and the UNET classes themselves with pytorch. Here is the commit:

https://github.com/hydroplantno/ML/commit/ba4f0c490fe7e2836026c764f10be9822b75e154Connect your Github account

This week, I talked to Shahin and we concluded that we could take a break from machine learning for now as it is a huge subject with a lot to learn, and we don’t have enough time for it. Instead, we could make it easy for us by just counting the total number of green pixels in a picture taken, dividing it by the total amount of pixels, and multiplying by 100 so we get the percentage. Out of that percentage, we decide if the plant is ready to move on to the next stage or should remain where it is. So we programmed this and it worked pretty well. Shahin has talked about this further. We got the picture visualized on the GUI command as well and the picture highlighted the amount of green.

I need to fix the amount of steps the stepper motor is taking between each place as it is a bit off each time. This also connects to the fact the plant information node needs to be calibrated from the plant mover node. I need to find a way to register the amount of steps. I will try to work on this, but I have a busy week next week, we’ll see how much I can get done.

Theo Magnor

This week I have done further testing and debugging of the plant-mover, its functions are now more refined, and it can now handle a situation that it previously couldn’t. I’m referring to when the plant-mover gets ordered to move a row from its current location to row n.

Sending receipt to master-controller and some more testing still remains in order to call the plant-mover finished. I also want to create a new diagram that captures some of the logic that has not been visualized yet.

This week’s commit:
https://github.com/hydroplantno/plant-mover-node/commit/f81a55e7a291320921c56649db06eb140e8fd51eConnect your Github account

Ivan Bergmann Maronsson

This week I disassembled the water-node board, so that all of its components could be sett up into their new node. this includes all the sensors, relays, pumps, and wiring. Only the nutrition pumps have been sett up, while the other electrical components are sett aside while we wait for the water node PCB to arrive.

Speaking about the PCB, me and Shahin have ordered my PCB design for water node, and all of its components. The components should arrive in the coming week, where I am able to solder the board and implement the PCB I have designed into the system.

I also explained to Aditi and Theo how to use the PISO switch register, so that they were able to test their code witch the switches already on the plant mover.

I also helped Shahin test Non-contact Capacitive Liquid Level Sensor, where in the end a solution was found so that we could test the system using that specific sensor. We also wired up all of the water valves, to a external 12V source linked through a couple of relays, and Arduinos, We used 2 Arduinos for testing purposes, but the plan is still to use only 1 Arduino for the water node.

The plan for the up coming week is to sett up all the components on the new node. Solder a PCB and fixing the wiring chaos I created when I disassembled the “original” water-node. And most likely more testing.