Skip to content

Oracle + Fix of simulation#33

Merged
FlavioFoxes merged 65 commits into
mainfrom
oracle
Apr 10, 2026
Merged

Oracle + Fix of simulation#33
FlavioFoxes merged 65 commits into
mainfrom
oracle

Conversation

@FlavioFoxes
Copy link
Copy Markdown
Member

Questa PR contiene sia l'invio delle informazioni dell'oracolo, sia il fix della simulazione.
Riguardo l'oracolo:

  • informazioni del mondo vengono mandate via socket
  • immagini tramite shm

Riguardo il fix della simulazione, è cambiato proprio il design del simulatore. I cambiamenti sono i seguenti:

  • PRIMA: due thread principali, uno per la simulazione (SimulationThread), uno per l'invio/ricezione delle info per i robot (RobotManager). I due thread non erano sincronizzati, quindi la simulazione avanzava secondo il suo clock senza aspettare i comandi dei robot
  • ADESSO: un solo thread che gestisce entrambi. La simulazione, prima di avanzare di uno step dt, aspetta che tutti i robot abbiano ricevuto il rispettivo comando. Visto che in mezzo c'è anche booster motion (che è una black-box), nel caso un robot non ricevesse un comando entro un certo timeout di tempo, viene reinviato il messaggio a quel robot. Il message passing è gestito comunque tramite socket bloccante: quando lo step di simulazione avanza, per ciascun robot viene inviato lo stato del mondo; una volta inviato lo stato a tutti i robot, si attende che ciascun robot riceva i propri comandi.

FlavioFoxes and others added 30 commits January 25, 2026 18:46
The oracle is modeled as a sensor attached to each robot. It must contains all the information simulator can provide, bypassing sensoring computation (e.g. position of the ball can be provided directly from the simulator, instead of doing ball detection from camera images, ...)
Added variables are necessary due to how the main.cpp and application.cpp files are
This is due to the fact that the bridge probably will run also on the robot. On the robot we are not interested on the timer, it is useful just for the simulation. So moving it outside the bridge guarantees an easier integration of the bridge in the real robot
Adding just the ball_position to the message genereates a EAGAIN or EWOULDBLOCK error. So adding a tcp-like message when sending information helps to prevent this (on the other side of the socket, i.e. the simbridge), there is a corresponding receiving function that manage correctly this type of message
Didn't end up using it in the end,
but why waste a good (?) function
So the robot can save its color name for sending to the framework
Needed to make use of the forward declaration of Team
in the next commit.
Had to solve one forward decaration earlier, why not another one
Paving the way for what's coming next (Team using the same code)
Still paving the way for the future (team subnets)
Most of this will be reverted in the enxt commit b/c I actually needed
a single /16 net, but I'm not deleting all that I self-learned about
docker nets just like that

Still, this is completely stable btw
Revert most of the previous commit and make a single network
for all the containers to connect to with static IPs.

GC is ok and teammates hear each other in 5v5.
@FlavioFoxes FlavioFoxes merged commit dab555c into main Apr 10, 2026
2 checks passed
@FlavioFoxes FlavioFoxes deleted the oracle branch April 14, 2026 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants