This document lays out the details of the current state of the two GUIs that are written in Python.
As it stands, there are two versions of a GUI written in python instead of C++. These GUIs are creatively named **PycroCart**.
## PycroCart 1.0
The first version of the python GUI was developed by a member of sdmay23-45's team. The great thing about this GUI is that it works super well. Unfortunately, this GUI does not utilize the MicroCART infrastructure at all. Instead of communicating with the Backend, and then through an adapter, the GUI sends packets directly to the drone (via CRTP packets). The most noticeable performance difference between this PycroCart GUI and the C++ GUI is the reliability and consistency of the logging tab.
While this is a great benchmark for the potential performance of the GUI, it does not offer the same support for multiple vehicles or drones to be controlled from a central location (the GroundStation).
PycroCart 1.0 was largely based of off a version of a GUI made by Bitcraze who is the distributor of the Crazyflie drones. If you want more information on how the CRTP packets or cfclient works, here is a decent place to start: [cfclient git repo](https://github.com/bitcraze/crazyflie-clients-python/tree/80f6ef617ccd805afe190e9e0403b10cba928c94/src/cfclient)
## PycroCart 2.0
Based off of some suggestions from sdmay23, and from feedback on MP-4 from previous years, sdmay24-32 decided to attempt slotting the existing PycroCart GUI into the rest of the MicroCART framework. Hence, PycroCart 2.0 was born. We were under the impression, with our very limited understanding of the framework at the time, that this would be a relatively straight forward task. We hoped that we could simply move calls to the cfclient library, down to the adapter level, and then send commands to the adapter, instead of directly to the crazyflie. Long story short, it was not quit that simple.
As it stands, PycroCart 2.0 is hardly functioning. Unfortunately, cfclient is considerably baked into the functionality of PycroCart 1.0. This made the task far more tedious and difficult then we had anticipated at the beginning of the year. Functioning components of the GUI are, setting a parameter, getting a parameter, and connecting to a drone if the radio number is hardcoded into the python code. As a team, we quickly started to realized that this was not the best use of our time, so we decided to put this on the shelf for the second semester.
## Moving Forward
For teams that are looking to improve the performance of the GUI for students that are taking 488, as well as for yourselves; I think the most important thing to know is that there are multiple things your team can try, before you attempt to rewrite the GUI.
I am not going to say that you shouldn't try to get PycroCart 2.0 fully functioning. I am just going to give you this **WARNING: If you want to commit to developing a fully functioning GUI, be prepared to invest a lot of time.**
We have realized that there a several things that could have potentially substantial impacts on the performance of the C++ GUI that would require far less work then basically developing a GUI from scratch.
Such as:
**1. Plotting Packet**
- As we understand it, the current C++ GUI relies on continuously reading and writing to files that contain all of the data from the sensors on the drones.
- This puts a lot of strain on the GUI (fileio is not fast). Typically when you are developing a distributed system, you want the frontend to be doing as little of the heavy lifting as possible.
- Hence our team came up with the idea of creating a new packet type called a **plotting packet**.
- Instead of sending entire files and reading and writing from those files which contain hundreds of different data points, why not create a packet that only sends the data on the logging variables that we are actively trying to plot in real time.
