14.10.2024 – 20.10.2024
“Don’t count the days, make the days count.”
-Muhammad Ali
Group Summary
Dearly beloved,
With all exams now being forgotten in the past, we got back to our usual working schedule this week. Our prototype now has got its motors installed, plus an added belt so that each motor has its own belt instead of one common. On Monday we began testing out the raspberry pi by running some of our code, this was unfortunately when we realized that it does in fact not have nearly enough power to run the computer vision code. Instead of running on a stable 30-60 fps which the camera is supposed to, it was closer to running on one frame every five seconds. Meanwhile our mechanical engineers have enjoyed themselves with some FEM analysis this week.
Individual Summaries
Eirik (Data):
This week has been full of the good ol’ “two steps forwards, and three back” on my part. The external camera that we are going to use on our system refuses to collaborate with my laptop, which is just simply brilliant, given that I am the sole individual on our group creating code for the camera to run on. After Vetle got the camera running on his computer, we tested the code from his machine. The camera did what it was supposed to and identified people in the frame without a hitch.
Then we set up the Raspberry Pi to test out the code there as well, which is when we saw that the Pi has nowhere near enough power to 1)Capture 30-60 fps and 2) Analyze every single frame to figure out where people are standing. To resolve this problem there were two obvious ways to go; find a more powerful unit to run the code or optimize the code to run smoothly.
The best way to optimize the code to run on weaker machines is to utilize multi-threading. However, I am still in doubt about how much of a difference multi-threading will make due to the lack of performance already. Even if it works well, the code will then again utilize a lot more processing power, making less processing power available for other tasks to use. The only way to find out is to try.
Robin (Data):
Week 9. I now understand why Microsoft skipped windows 9, as this week have been nothing but trouble for me, with cameras not functioning, PATHS not working to find python, visual studio code errors, Anaconda going completely haywire and stopped functioning for good etc. After trying several fixes, using hours upon hours to no avail, I ended up uninstalling everything to start all over. So, I guess you could say there’s a happy ending to this story, as I now have everything up and functioning! But at the cost of time and tears.
To say something more positive, I got my own raspberry pi 5, which I have set up the coding environment in so we have 2 “pi’s” we can work on to increase productivity.
I have also done more research into GIT so it’s easier to work on the same project by creating branches.
All in all, it’s been a week in the trenches, but dawn is upon us and the future is bright!
Fredrik (Data):
This week I tried to implement the point-counting system into the moving algorithm code. Making it all work cohesively, I first tried to do it using threading which I tried before hoping this time it would work but ended up not working so I scrapped it and moved on to a different solution.
I then decided to move the point counting function into the algorithm which works fine, the only downside being that you can only get points when the target has stopped moving. But I think it would have ended up that way with threading anyway.
I then wanted to fix something in the point counting code, where it was on a while loop until the sensor went off. Changing it to be still for a set time, where I chose 2 seconds, and then go back to moving the target even if you didn’t hit the target. So, after some quick googling and a small test to see how time.time( ) worked, I got the code to work as intended.
Googling in question:
Vetle (Electrical):
I have continued working on the circuit schematic and looking for components for the PCB. The design has a 5V voltage regulator now that can provide up to 8A. This voltage regulator is needed to power two servo motors (MG996R) that will be used to move the turret around. These servo motors have a 2.5A stall current at 6V, but I will be running them at 5V since it is easier to find voltage regulators at 5V that can provide a high current output. I have yet to choose all the component values and figure out how I should enable it, the datasheet does not specify a maximum voltage for the enable pin so I think it should work at the supply voltage that will be 24V.
The operating voltage for the MG996R is 4.8V to 7.2V, so it is within spec. I also need to add logic level converter to send the PWM signals between the Raspberry Pi and the servo motors. I have yet to choose some connectors and add the logic level converter. For the infrared receiver on the moving target, I am looking at the Vishay TSOP4840 or the TSOP6240TT. The TSOP4840 will make it easier to prototype since it is a through hole component while the TSOP6240TT is a surface mounted component.
Kadir (Mechanical):
The past week I have done some redrawing of the horizontal dolly, to adapt to the new 2 belt system.
Me and Hans Did some FEM testing on our system. Worked with a SF of 2.
Hans (Mechanical):
This week, I have been working on conversion from 1 belt drive to 2 belt drive.
Also updated the 3D drawings of upper and lower wheels to match the wheels that we were able to procure.
Kadir and I also started doing FEM analyses of the systems parts and as a whole.
