This past week, our team worked on fine tuning our design, firstly for the presentation slides due last Sunday, then further details based on questions that came up during the presentation and feedback that we received afterwards.
Looking at our current status in terms of progress and design improvements, the most significant risk that we have as of now is once again the mechanical operation of the swing trap door, as if this operation does not work, it takes away a large portion of our project goals, which advocates for a hands free recycle sorting system. Since we don’t have much experience with mechanical building, it has been a little difficult figuring out what exactly we need to make sure the door operates properly. However, to mitigate this risk, we have worked towards improving our design over the last few weeks with the help of our TA(Samuel) and Professor Fedder. We have multiple contingency plan designs such as a single open/close door or a non automatic but locked flap door rather than a swing door that while do not completely achieve our goal, can serve as a backup in case the current design doesn’t work out.
After ordering parts, researching, and further detailing the swing door (ex. looking at measurements, operation, etc.), a flaw we found with the design we had lastly settled on is the lack of support for the door itself, which was being held up solely by the servo in charge of turning the door. Since we had already ordered other parts including the acrylic for the door itself, our solution had to account for this. Specifically, while we thought adding an axle would fix our issue, a problem with this solution is that the door material might be too thin to drill a hole and insert an axle all the way through. Therefore, the solution we have currently decided upon is drilling a small hole into the side of the door in which a small dowel on which the door can rotate upon while still having some support. Since we haven’t started building yet and the change only builds upon our current design, there isn’t too much of a cost except for the addition of the dowel itself.
For the FSM, we implemented a detection algorithm (not YOLO which is only for classification) and did test runs. The code as well as logging of runtime could be found at the link under Aichen’s report. Overall, the runtime is much lower than what is expected of YOLO and we will do more test runs to set a threshold for declaring image change.
We also took in Samuel’s advice for setting a timeout and updated our design based on that. So right now, if no image change is detected at the waiting state for a certain period of time (set to be 5 seconds now), it will go back to the initial state.
Jetson has arrived this week; once the camera is also here, we are excited to set up continuous image capture and perform detection. We will then also verify if the camera is set up properly to capture the whole platform.
We also decided on a number for the confidence threshold, which is referring to the number given by YOLO algorithm to show how confident it is that the object is what it says it is. This was a question that was brought up after our design presentation. We wanted a number that would balance not contaminating the recycling, while also not throwing too many items out that could have been recycled. We decided that .85 is a number that would allow for a good balance of these considerations.
In terms of schedule, since we haven’t received our hardware and mechanical materials yet, we have not started to build. To account for this setback, we proactively simulated our hardware and fine tuned the design of the structure overall to make it easier to set up. We will be receiving a lot of things next week I expect, since we placed our orders this past week, so we look to start building this upcoming week. We are still behind schedule in terms of the ML as we were planning to start fine tuning this past week. We seem to still have some issues regarding debugging the training model, but we will take the next few weeks (before and after spring break) to really focus up on this aspect and get the code running and fine tuning started. After the code runs we don’t think it’ll be too much to train.
To summarize our schedule updates:
- Moved construction of hardware from the week of 2/20 to 2/27 (shortened the construction time since a lot of the work has been covered through simulation).
- Moved construction of mechanical parts to the week of 3/13.
- Moved report writing from the week of 2/27 to starting the week of 2/20 and fine tuning the week of 2/27.
- Stretched the debugging + training of the ML model until the end of the week 3/13 at the latest.