(a) What design criteria must your project meet? What is the desired functionality?

 

In terms of design, our project had the following criteria:

• Low cost, high efficiency

• Relatively robust given budget limitations

• Have or replicate a system which resembles stove knobs

• Be able to detect the position of the stove knobs

• Be able to convey information back and forth between our robot and a remote application

• Be able to calculate how much a knob needed to be turned in order for the respective burner to be turned off

• Be able to turn the correct knob by the angle which was calculated so that the knob can reach the off position

​

The desired functionality would be a system which sends detected information about stove knob positions to a user-run remote application, calculates how much each stove needs to be turned in order to reach an off position through the remote application, allows the user to select specific knobs to turn off at the click of a button, and actually uses hardware to turn off the correct knob.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

(b) Describe the design you chose.

 

The design we ended up choosing involved using two DC motors to turn gears which resembled stove knobs. These motors were connected to a microcontroller. A separate script would send simulated image data regarding the current position of the knobs to a python application on a remote machine using MQTT messaging. The application involved a GUI so that the user could easily determine and manipulate the state of each knob. This application would run computer vision code and then inverse kinematics code on the image data it received in order to determine how much the knobs needed to be turned to reach an off position. The application would then send back information to the microcontroller (using MQTT messaging) about how much each knob needed to be turned to reach an off position. The microcontroller would then command the DC motors to run a certain amount based on the information it received so the actual knob would reach an off position.

 

​

(c) What design choices did you make when you formulated your design? What trade-offs did you have to make?

 

When formulating our design, we made several vital design decisions. The first decision we made was to model the stove knobs using gears rather than using actual stove knobs. We had initially planned to attach a gear to JP’s stove knob and rotate the gear using a gear system in order to move the knob. However, we did not want to ruin a group member’s stove by hot gluing hardware to it, so we created a model instead. This was a trade-off for us since it meant that the robot we made couldn’t directly be applied to an actual stove without making minor hardware modifications first. In other words, although our model was accurate, it was not exactly the same as an actual stove so there may have been inconsistencies between the way the model works and the way a real stove works.

 

Another design choice we made was to use computer vision in order to determine whether a stove was on/off. Initially, we also thought that we might be able to use thermal sensing, but we realized that thermal sensing functionality was out of our budget. As a result, we implemented computer vision which was a trade-off since it’s less accurate than thermal sensing. This is because computer vision can be ruined by noise in an image or by movement of the camera. However, we are able to get more accurate knob orientations from the image data.

 

We also made the design choice of using a simulated image stream rather than live pictures from an actual camera. This is because, once again, a dedicated camera was out of our budget and it was inconvenient to attach our phones to the system since it’s very easy for phones to move unless they are hot glued (which was again, infeasible). Instead, we sent images that were taken beforehand to our application through a script which would simulate an image stream. This was a trade-off that we had to make in order to successfully enact computer vision. In this case, we had to sacrifice some practicality of our project because a full-fledged StoveBot would need to detect stove knob images in real time rather than sending pre-taken images. Realistically, this is not a big tradeoff because in a real-world system, it would still be impractical to have a 24/7 video stream of a stove when the stove may only be in use 1% of the time. So our compromise of having an image stream send pictures every N seconds was more than enough to model how a real-life system would behave. Regardless, our compromise still allowed us to demonstrate the functionality of our project.

 

Other design choices include using MQTT for IoT messaging, using PyQT to create a GUI, using OpenCV for the computer vision aspect, running the computer vision code on the remote machine as opposed to the microcontroller, and using an ESP32 for the microcontroller. All of these design choices were influenced by cost, familiarity, convenience, or a combination of them.

​

​

 

​

​

​

​

​

​

​

​

​

​

​

(d) How do these design choices impact how well the project meets design criteria that would be encountered in a real engineering application, such as robustness, durability, and efficiency?

 

Creating a model for our stove knobs decreased the robustness of our project because it made it so that our project was not exactly the same as an actual stove. Using computer vision as opposed to thermal sensing also decreased robustness since there is more room for error in computer vision (movement of camera, noise in image, etc.). That being said, computer vision may have increased durability since parts are not exposed to heat; exposure to heat could lead to deterioration of parts, so using computer vision also has its ups. We are also able to calculate and determine orientation data from the knobs using computer vision. Using a simulated image stream decreased robustness but improved efficiency. Robustness decreased since a real StoveBot would not use simulated images, but efficiency was increased since it’s easier and quicker to use simulated, pre-taken images. All the aforementioned choices involved a decrease in robustness because all of them were part of trade-offs. On the other hand, choosing to run the code on the remote machine as opposed to the microcontroller increased efficiency since the remote machine is capable of running programs significantly faster than a microcontroller. In this case, the design choice only benefited us because no trade-offs were involved. Using MQTT also boosted the efficiency of our system because it is a lightweight protocol which is ideal for anything related to IoT and was very similar to ROS, something we had used previously in the course. The design choices of using OpenCV, using an ESP32, and using a simulated image stream helped us keep our costs low.