Subsystem Build & Test
Table of Contents
Team Vision for Subsystem Level Build & Test Phase
Frame ConstructionTo fit the grinder, compost input, holding bin, and reactor bin, the frame needed to be adjusted. After deconstruction of the original Robocomposter 1.0's grinder and bin placement, there was a need to reconstruct to properly place each piece. Problems occurred however due to improper documentation of the previous build so much of the new reconstruction took time on understanding how the grinder must be placed so that every piece would fit.
After moving each piece around the first iteration of the construction has been built. The grinder now sits upon two brackets which are now 3 inches lower than before to better match with the holding bin. The holding bin is now locked in with two L-brackets which leaves room for the motor. The reactor bin was shifted down by about 3 inches leaving no more room for a 5 gallon bin, which was the original plan. Here are pictures of the result.
GrinderThe grinder fabrication has been completed during this phase and testing completed. To finish the fabrication, a face place was made based off of designs in MSDI. Additionally, new bolts were purchased for the motor and threaded so that the motor could be safely secured to the grinder mount.
With the fabrication completed, the grinder could go into testing phase. The motor was attached to an Arduino and testing began.
The auger motor mount was completed during this phase. With this, the auger motor could be attached as seen in the photo below.
Arduino UpdateThe Arduino in it previous case was not able to receive a asynchronous stop from the Raspberry Pi. Due to the newest changes, whenever a new command is sent to the Arduino the motors will stop what they are doing. This allows for more safety on the users end.
The Arduino now has a better implementation of the jam command which was found during grinder testing. When a JAM command is received, the Arduino will send signals to grinder motor to reverse its grinders for 0.5 seconds and then resume grinding for 0.8 seconds. Doing this helps the motor to more easily grind tough material that is causing the grinder to jam.
GUI RPICreated a development environment on a Testing Raspberry Pi.
- The master Raspberry Pi has the same hardware as the
target Raspberry Pi.
- The master Raspberry Pi has updated software compared to the target Raspberry Pi.
- Plans to update the target Raspberry Pi software will be looked into.
- The OS (Raspbian) needs to be updated on the target RPI.
- QtCreator and Qt libraries need to be added to the target RPI.
- Code developed on the Master RPI gets copied onto the Target RPI once completed.
- Plans to move Development environment onto better PC
(Windows, Linux, etc) were considered.
- Issues arose with cross compilation.
- Complexity of development environment increases.
- Complexity of software on target increases.
- Knowledge base to implement such a solution is lacking.
Created prototype Graphical User Interface
- A mock GUI was created to demonstrate Qt’s
functionality and appearance.
- The mock GUI was not created with any modularity.
- The mock GUI would not be maintainable in the long run.
- The mock GUI can be quickly created visually.
- However the additional code that needs to be integrated with the GUI takes longer.
- Time was taken to learn the Qt framework to create an
easier to maintain code base
- Multiple prototypes were made to learn specific aspects of the framework.
- Enough knowledge was gathered to create a modular User Interface.
- More research is required to integrate additional code base (Serial, data processing, etc.).
- A working phase 1 GUI was made on the master RPI.
- This version aims to provide all the User Interface pages that the customer will see
- This version does not yet implement the extra code base to communicate with the motors and Arduino.
- UI was divided into single classes.
- UI are not final: design, style, color and accessibility will change on demand.
- Integration Testing
- An integration test was performed using the Lilliput Touchscreen.
- The GUI application works and the touchscreen is responsive.
- New issues were discovered with the touchscreen which need to be resolved.
- Resolve issues with the touchscreen
- Research Lilliput touchscreen drivers (Best case).
- Look into dealing with the issues in software (Expected case).
- Create drivers for the Lilliput touchscreen (Worst case).
- Resolve dependencies that the GUI application
requires on the target RPI
- Find additional software required to run GUI on the target RPI.
- Find minimum software required to run GUI on the target RPI.
- Look into having GUI launch at startup and block user from the OS environment.
- Work on additional code for the GUI application
- Develop RPI side serial interface code.
- Develop RPI side data processing code.
- Clean up Arduino side serial interface code.
- Look into doing some data processing on the Arduino (pro/con)
Test Results Summary
GrinderThe grinder during testing showed that during a certain amount of torque, an internal slip clutch engages which limits the amount of power output; the current, from the slip clutch, is then limited. In experiments, the max current found was 7.668 A shown in the following picture. The video of the occurrence is is Here.
The grinder however after adjusting disk grinding locations preformed a lot better. The quality of the wood chips was medium, with certain concerning pieces which may affect auger performance.
AugerThe auger test provided some insight on the type of problems we will face moving wood chips through the robocomposter. Troubles arose from when the wood chips were squeezed between the auger pushing upwards and the PVC pipe that separates the compost going up from the compost in the bin. This ultimately caused the Auger to fail and stop working. The video of the occurrence is is Here.
Risk and Problem Tracking
Functional Demo MaterialsInclude links to:
- Presentation and/or handouts
- Notes from review
- Action Items