You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: raspberrypi/README.md
+38-2Lines changed: 38 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,8 @@ If you run the script, you do not have to do the following:
48
48
To run this, you want to first activate **EspManager.py**. This is basically the process that will communicate with the Raspberry Pi's. It does this by creating child processes, and each child
49
49
makes a TCP connection with a single ESP, and communicates with the parent back and forth with unnamed pipes. **ControllerPi.py** and **GmServerPi.py** will send relevant information to **EspManager.py**
50
50
through another socket connection. Here's a diagram to explain the purpose of each process a bit better (apologies for the poor quality).
Now to run the Raspberry Pi server, we will first run **EspManager.py**, move that to background, then run **GmServerPi.py**, move that to background, then run **ControllerPi.py**, move that to background,
54
55
and that will be all you need to do. Note that you **MUST** run it in this order, otherwise because of the order of socket connections it won't work properly.
@@ -84,26 +85,61 @@ ask your mentor for further details.
84
85
85
86
### EspManager.py
86
87
88
+
This takes in data about motor inputs for each robot and signals from the game manager (game start, robot ready check, game end), and sends the appropriate data to each robot.
89
+
90
+
To connect with each robot, it forks itself (basically like makes a clone of the program that also starts at the same code line where the fork was) based on however many robots there are. If there are 2 robots, for instnace, there will be 2 forks, and thus 2 child processes will be made.
91
+
92
+
May need to research pipes, forking, piping, and processes to understand this.
93
+
94
+
Then, when it receives a request for ready connection from GmServerPi.py, it relays that through pipes to its child processes, which then send a message to the robots asking if they're ready. If they are, they should return back their own success message successfully. Then if all robots returned success message, send that to the game manager file which then tells that to the website.
95
+
96
+
Also, for motor inputs, ControllerPi.py sends its ID alongside the motor inputs. EspManager checks the ID and sends it to the correct child process, which then sends those inputs to the esp32.
97
+
98
+
It also has shared memory shared with GmServerPi.py, which is where the current game timer is stored. Basically, when the game ends, it puts in the shared memory that the game is over. EspManager reads from this frequently, and when it sees the game is over, it can shut off communication with the robots, and prepare for reconnection.
99
+
87
100
### ControllerPi.py
88
101
102
+
This connects with the website's Controller file, and when the website sends inpts from the user, it directs those inputs to EspManager.py. Pretty straighforward, though it also checks if the input the user sends is the same input as before. If it is, then it doesn't send it, as that doesn't change anything.
103
+
89
104
### GmServerPi.py
90
105
106
+
This connects with the website's game manager file. It handles and responds to certain messages from the website. For example, if it receives a packet to check if robots are ready, it sends that request to espmanager, gets a response, and sends that response back up to the website.
107
+
108
+
When it receives game start command, it begeins running the game, waiting until the timer's up, and when it is it puts in shared memeory with GmServer that time is up, to let it know to disconnect the robots. Then it restarts with waiting fora game to start. It also sends the timer to the website, as it actually is what has the decreasing timer.
109
+
91
110
### ESPClient.py
92
111
112
+
This is just a class where each object represents a connection with an esp32, used as a helper function. It has functions like trying to connect to the esp, sending data, and receiging data, alongside error handling too.
93
113
94
114
# Camera
95
115
96
116
## cleanCode.py
97
117
118
+
This creates a page that's hosted on the raspberry pi at a ip address and port to stream the camera display to. It initializes with the camera and starts a server to host the stream on, and connects them to the stream.... somehow. Probably when it calls self.wfile.write(frame), where it writes the current frame of the camera.
119
+
98
120
## combinedCam.py
99
121
100
-
## apriltagLiveFeed.py
122
+
This is like the file above, but this time it makes it so if there's keyboard presses of WASD on the raspberry pi, it moves the camera lens to show a differnet place of the field. At least, I'm assuming that's the intention.
101
123
124
+
NOTE: THIS ONE MAY BE OUTDATED; CHECK WITH DAMIAN ON THIS.
102
125
126
+
## apriltagLiveFeed.py
127
+
128
+
This is basically exactly like the above, but now if you put an april tag in front of the camera, this code will detect that april tag. The code to detect the april tag will be useful likely, use this as reference when implementing the algorithm to send robots to charging stations. It may be outdated in the same way that combinedCam is outdated.
103
129
104
130
105
131
## backtracking.py
106
132
133
+
There isn't any file named this, I assume it's just backTest.py. This seems to first do the same as above, streaming it but also showing the april tag on the screen. Right now, it puts the movement instruction on the frame, so ideally the only thing that needs to be done is sending it.
134
+
135
+
It seems right now it's configured to send 2 pieces of data to the motor: first, the direction of movement (rotationg left, rotating right, moving backwards, moving forwards, stopping) as well has how much to rotate in each direciton. Now, main issue will be configuring that to become packets to send to the esp32. Have fun with that!
136
+
137
+
Also note that each car has 4 states. State 0 is rotating to face target, state 1 is moring towards target, state 2 is doing final rotation, and state 3 means finished arriving and rotating at charigng station.
138
+
107
139
## backupTag.py
108
140
141
+
This seems to be like a prototype of the one above? It uses a file that doesn't exist anymore (backtracking.py, though an archive of it is at https://github.com/UTDallasEPICS/Soccer-Robots/blob/1eee7dc0c4098b2c6e86b0c17d89b73867ff42a8/raspberrypi/scripts/archive/Backtracking.py.txt#L4). Even so, backupTag.py references a method in backtracking.py "get_direction", that I can't find in the backtracking.py archive file.
142
+
109
143
## carConnect.py
144
+
145
+
This is a file that was used to connect to the ESP32. Back when I made the ESPClient.py file I didn't know this one existed, but all it does for now is just connect and send a handshake, and that's it. Now though, it seems we don't need it since ESPClient.py and ESPManager.py does everything this would've already done.
0 commit comments