Group 02 – Project Report – Week 9

Mechanical

This week we have mounted all the components for the stick system together so that everything is aligned properly. This has taken a while since small changes had to be done continuously for everything to fit perfectly. Still there are some parts that are not optimal, but these will change soon.

Since I [Markus] was alone mounting all the parts together I forgot to take pictures of each step, but the full board with all the components can be seen in the computer chapter.

Also, the mounting was, as mentioned, a time demanding process, so there hasn’t been too much else that has been worked on parallel to this. Over the weekend I plan to further ready the board with legs, mounting the plexiglass plate, and adjusting the bridge.

Electrical

This week the electrical engineering students have managed to mount all the necessary components to facilitate the testing of the movement of the computer’s stick. By connecting all the wires of the motors and encoder to the Arduino, we were able to move the stick around the board, just as it was planned at the beginning. We still haven’t received the band we ordered online, so we had to improvise with by tying a wire to a smaller band so we could start some preliminary testing to determine whether our design truly worked.

We hope we will have all the other components by next week, so we can truly start integrating all of it into a single, coherent system, without any improvised parts that are prone to failure.

Computer

This week in software, we encountered a strange bug with our FPS implementation wherein it would seemingly display the incorrect FPS on the RP4. On the RP3, it appeared our FPS counter was a reliable way to measure performance, as the numbers it calculated aligned with expectations and observations made; a stream directly from the webcam would yield about 50 FPS, using HSV would yield about 40ish FPS, and so on. On the RP4, it displays around 30 FPS no matter what. We believe our implementation is theoretically sound, so we have not yet been able to identify and fix this issue, and as this is not an urgent issue, we have decided to postpone it until we have more time to look into it, or alternatively inquire with Steven at some point soon.

Last week it was also stated we were planning on implementing the interface between the RP4 and Arduino, and this has progressed well. Writing to and reading from the serial port has been implemented on both sides of the interface (in Python on the RP4, and in C on the Arduino), and testing indicates this works as expected; by writing in the serial window of the Arduino IDE, the same characters appear in the console window of the Python program, and vice versa. However, if we write directly from the serial window in the Arduino IDE, the characters will end up fragmented or rearranged. We believe this is because both the serial window of the Arduino IDE, as well as the console each “eat” some of the characters, causing each of the windows to get some of the characters from the original message. This won’t be an issue in the proper implementation of the program, as the message will not be manually written in a console window, but rather directly sent over the serial link by a certain protocol.

As we are still waiting for parts that are necessary before we can start properly testing and evolving our software, we have been assisting within other disciplines. Sometimes you just have to be a potato in a multidisciplinary team.

After Markus 3D printed and assembled parts to make sure that everything fits, we spent some time painting all the multicoloured parts. Some of the parts could not be disassembled so we had to invent some creative solutions.