-
Notifications
You must be signed in to change notification settings - Fork 9
Ansible Dawn Communication
This page will detail how Runtime communicates with Dawn. The code is contained primarily in Ansible.py, with relative protos stored in ansible-protos.
There are two forms of communication with Dawn: UDP and TCP. UDP is used for constant data transfer where it is not critical to not lose packets. TCP is used to send data where it is critical to not lose information. Communication with Dawn happens in three processes, which are spawned by runtime.py. These three processes are UDPSendClass, UDPRecvCLass, TCPClass. UDPSendClass spawns two threads, one for packaging and one for sending. UDPRecvClass does not spawn threads, and receives and unpackages in succession. TCPClass spawns two threads, one for sending and one for receiving.
See [Dawn Runtime Network Protocol] (https://github.com/pioneers/PieCentral/wiki/Dawn-Runtime-Network-Protocol) for specific networking details.
See Google Protobuf for information on how to use protobufs in python.
All processes are started by runtime.py via the spawn_process function. Initially, on startup, only the UDPRecvClass class is spawned. This is because runtime needs to learn the IP of Dawn, and can only do so after receiving one packet. After determining the IP of Dawn and it is stored into StateManager, BAD_EVENTS.NEW_IP is triggered which now spawns UDPSendClass and TCPClass. Only one Dawn instance can be connected at a time. Whenever Dawn disconnects, BAD_EVENTS.DAWN_DISCONNECTED is triggered which terminates all the processes and then respawns just UDPRecvClass. This is the same as the initial state, and it repeats the entire process.
This class runs as a single process. It receives the robot state (IDLE, AUTONOMOUS, TEELEOP, ESTOP), the team color, and gamepad data.. If there doesn't currently exist an IP stored (this is the first time receiving from Dawn), the IP will also be saved and the other two communication processes will be spun up. If the received state is different from the current state, a command will be sent to StateManager.py via the BadThingsQueue to switch student code state. If the team flag color has not been set, a command (SM_COMMANDS.SET_TEAM) will be sent to StateManager.py to set the team flag to the appropriate color. Then, it takes the unpackaged data containing the gamepad data, and sends it to StateManager.py.
This class runs as two threads in a single process. One process constantly receives data from StateManager, and packages up via protobufs all the sensor information, and the current robot state. It then stores the data into a
TwoBuffer object which is shared by both processes. The second process takes the packaged data from the TwoBuffer, and sends it to Dawn viw UDP.
This class runs as two threads in a single process, one to send and one to receive. Both use the same TCP connection. The sender sends console logs to Dawn, as well as acknowledges that runtime is ready for student code upload. The receiver receives the command that student code is going to be uploaded. Furthermore, when the TCP connection is broken (as caught by an except), this indicates that Dawn has disconnected and Ansible state is reset to idle.
© Pioneers In Engineering