Looking into the future: API Architecture

[exofunctor]

As we move away from Matrice drones, we will have to make our control platform more modular. This entails only sending generic messages from Unity, and doing the decoding on the onboard computer (or the microcontroller).

This is more in line with ISAACS version 1. The steps needed are the following:

1. Allow the user to input a drone type (string) through the unity interface, and select its properties through a menu similar to the one we currently have for drone instances.
2. Generate a new class whose name is the drone type, and whose properties are the ones selected by the API user.
3. Implement a network architecture that exchanges messages between Unity and manifolds (see ISAACS v1 for details), and remove our M100/M210/M600 scripts.
4. Implement a wrapper that receives these messages, and converts them to ROS commands. It's up to the API user to specify these commands for their drone model (although we can have some default "profiles", such as for the M600).

[PeruDayani]

Just one comment when we do this: we should consider the potential tradeoffs if any of requiring another server running a ROS node, implementing a node that has to run on the drone or find a way to do that in unity.