-
Everything was done as was suggested (software used, etc.);
-
Points of interest in the ball thrower designed: it was standart, basic. I decided to make a good version of simple thrower by determining throw angle, making good and rigid structure, connections etc. I didn’t go further with ball holder and adjustable angle designs because we would have no possibility to use those because of absense of any servo channels in our’s electronics;
-
Drilling and threading was done manualy cause of big queue to the drilling machine, thus the accyracy was bad which implied assembling in a bad way; Also, I have not done adjustable thrower and ball holder (partially because it was useless cause of absense of any servo channels on ours electronics) which would be more challenging with currect thrower design’s restrictions.
enum for Color and State enums
numpy for data structures
pyrealsense2 for the Realsense camera
cv2 for image processing
time for testing
pyserial for serial communication
struct for serial communication
os for finding the correct serial device
math for trigonometric functions and pi
websocket, json and multiprocessing for referee client
Game logic
The robot uses a state machine for game logic. It rotates until it sees a ball. If it sees one, it drives towards it, rotates around it until the ball and basket are aligned, and drives towards the ball with the thrower motor engaged. Each activity is a programmed as a state.
Code structure
motion.py deals with serial communication and calculating motor speeds
statemachine.py describes the states the robot can be in
referee.py handles referee commands
main.py is the main program, and also sets some configuration parameters
The rest of the files deal with image processing.
I think our code is separated well into modular parts. I followed the suggestions on the course home page regarding common pitfalls (https://ut-robotics.github.io/picr22-home/basketball_robot_guide/software/review_summary.html). The code isn’t very advanced and doesn’t pass all tasks but throws in balls quite consistently. Our team decided not to build a ball holder and therefore we didn’t program that logic.
I think we would have benefitted from something more advanced than a proportional controller, which we used in most of the robot’s states. We mostly kept the sample image processing code untouched, because it was quite complex. We tried implementing some kind of detection of the playing field’s boundaries but failed to create a working solution. The robot may get fouls for driving off the court if it sees balls there or for ramming into the baskets while orbiting or throwing.
Unfortunately there is quite a lot of code repetition to implement same logic for different baskets. I now realize how passing the basket color value as a parameter in state functions could have made the code cleaner.
Testing our quite limited codebase took more time than was expected beforehand and therefore more advanced functionality was left unimplemented.
Mainboard consists of:
-
STM32G441KB microcontroller
-
Programmer connector for connecting STLink programmer to the microcontroller.
-
USB connector for powering the microcontroller and for communicating with robot’s computer.
-
Three motor driver connected to two isolators to avoid short circuits on the motor’s side damaging the computer.
-
Three encoder connectors input and one PWM output for controlling the thrower
The mainboard is supplied with 16v on the motor drivers side with a reverse voltage protection for avoiding reverse voltage damaging the components. The motor drivers have 3 x 3 mm pads for each motor driver power outputs.
The wires and the mainboard was hidden under the computer. Refer to the picture in the Mechanics.
|
|
-
The PCB should had a bit more room on the mainboard side for the better soldering
-
5V linear converter was very fragile and when even a slight current fluctuation happened, it burned down and also burned down the isolators
-
Should have used different motor driver’s package for better soldering and better debugging - this was the main stumbling block which resulted in 1 motor driver failing to work
-
The entire mechanics was done by me;
-
I have learned Fusion 360, 3d printing, milling and other manufacturing technics (manual, during assembling);
-
I hate Fusion, there are other CAD systems I would like to work with next time (it also crashes frequently);
-
In general I am satisfied with my mechanics, the bot was moving quite smooth with no vibration, also the team noted through camera stability that alike the test robot, on the new one there was much less vibration. Also, possibly, I have designed the smallest bot during entire course, which is a good challenge to do for myself, cause my previous degree in aviation (we do like saving space and reducing weight much ;3 ).
Suggestions: I didn’t have any problems though heard that some ppl were not very happy when they were refused to be moved into the group where they had friends, the reason was that it is not allowed to have 5 members in a team, though there was one another team with 5 members in it… so in general - group formation needs to be improved_)
-
I worked on everything in the code except image processing, which I tinkered with very little.
-
My main takeaway from this course is that building a good robot requires that every aspect of the robot works well. All of the electronics depend on the mechanical part of the robot and the code must regard the physical and electronical part of the robot. Testing robot code is very time-consuming, because the program output happens in the physical world.
-
Next time I would like to be involved in more decisions regarding the other aspects of building a robot.
-
I liked the freedom the course offered. No step-by-step guide, but suggestions that let the student explore problems by themself.
-
For next year students I suggest attending the bootcamp. I didn’t, and wrapping my head around the sample code was very difficult at first. (I only started making any progress by week 6 or so…)
-
I suggest the instructors to keep hosting this course, because the practical skills taught by this course can’t be learned from a lecture and are very valuable. Making things in real life teaches a lot. Also, I was impressed how professionally and seamlessly the course was taught. Everything is well-documented and the supporting systems work well.
-
I worked with most parts of the code excluding orbiting. I also mounted the electronics for the final robot.
-
I learned that taking extra time to set up the proper framework from the beginning really helps make everything more efficient later down the line. I also learned that my habit of making variable names short is very detrimental for the legibility once working with larger code files.
-
I would have started testing the image processing code earlier, so that it could be implemented by the time of the competition.
-
I did not like that we needed to document everything we had done, but making these tasks mandatory by deadlines made it easy to recall what time was actually spent working. I did not find the presentations very useful. I liked that instructors advice was very relevant and useful. I did not encounter a problem that was unfixable even wit the help of instructors.
-
I suggest for next year students to start with everything early on. If encountering a problem with one function/task it might be useful to work on something else for a bit and come back to the problem with a fresh vision.
-
It would have been very helpful from the beginning to better understand the importantce/function of x-speed. Also would have been useful to get an explanation about the sample code motor speeds. I found it very difficult to understand in the beginning.
-
I worked with everything regarding electronics.
-
I learned to design a PCB and write and flash firmware.
-
Next time I would start earlier with the tasks.
-
The time consumption was much bigger than expected. The materials for building the robot weren’t systematically shown in the course webpage – this caused a lot of confusion at first and it was hard to start doing correct things.
Elias: Soldered adapter for robot battery connector. Worked image processor and compiling new code. (2h)
Andres: Worked image processor and compiling new code. (2h)
Anton: working work (1h)
Whole team: battery charging instruction (1h)
Andres: implementing omnimotion (1h)
Elias: implementing omnimotion (1h)
Anton: working work again (1h)
Andres: implementing motion, fixing import errors (2h)
Elias: implementing motion, fixing import errors (2h)
Anton: doing mechanics (1h)
Markus: assebling test robot electronics (1h)
Andres: creating more movement code, refactoring, image processing (1h)
Anton: fixing stuff on thrower (1h)
Andres: testing movement code, refactoring, image processing, state machine (2h)
Elias: testing movement code, refactoring, image processing, state machine (2h)
Anton: thrower parts manufacturing and assembling (2h)
Andres: state machine implementation (2h)
Elias: state machine implementation (2h)
Anton: presenting thrower (1h)
Andres: state machine implementation (2h)
Elias: state machine implementation (2h)
Anton: assembling of the test robot (1h)
Andres: fixing minor issues with test robot electronics (2h)
Elias: fixing minor issues with test robot electronics (2h)
Anton: assembling of the test robot (1h)
Markus: assebling test robot electronics, connecting thrower electronics (1.5h)
Andres: testing robot on field, implementing orbiting state, image processing (3h)
Anton: Mounts for wheels machining (3h)
Andres: Trying to qualify for the competition and fixing throw state (3h)
Elias: Trying to qualify for the competition and fixing throw state (3h)
Anton: Omni wheels design completed, test model fabricated and assembled with test bearing-roller (3h)
Elias: Fixing thrower distance data (2h)
Anton: Bottom part desing completed (2h)+
Elias: Fixing thrower distance data (2h)
Anton: Motor mount desing completed (2h)+
Elias: Thrower calculations finished (2h)
Andres: Created WebSocket client (3h)
Anton: Camera holder desing completed (2h)+
Elias: Participating in test competition (3h)
Andres: Participating in test competition (3h)
Anton: Upper plate desing completed (2h)+
Markus:: Fixed PCB schematics (4h)
Andres: Code refactoring (1.5h)+
Anton: Whole new robot design completed (2h)+
Markus: Designing PCB (6h)
Andres: Assembling old electronics on new chassis(3h)
Elias: Assembling old electronics on new chassis(3h)