Fixed errors in CrazyRadio python script and tested to work with actual radio and Crazyflie 2.1 running the new dfall firmware

Properly integrated both the mocap and crazyradio emulators with the data flow of state estimate data coming from onboard a simulated Crazyflie. Also updated the student controller service to work with either mocap data or onboard estimate data. Next step is to test on the real quad.

Connected the CrazyRadioEmulator to its Quadrotor Simulator. Tested to be working, however, it is important that to not emulate both Mocap and Crazyradio at the same time. Next step is to add a visualization of the simulator to the System Config GUI.

Extended the FlyingVehicleState message definition to inlude a type, and velocities (both translational and angular). Update the Vicon and Qualisys publishers to fill in the type. Updated the CrazyRadio node to fill in this expanded FlyingVehicleState correctly, including adding a crazyflie name property to the CrazyRadioClient class. Removed all empty lines as end of message definitions.

Changed the CrazyflieData message to be called FlyingVehicleData and changed the names of its properties from occluded to isValid and from crazyflieName to vehicleName

Updated the Parameter Service node so that that yaml files are added to a map of Publishers and hence the sleep is only needed the first time an unknown yaml file is loaded. Changed the getParameterFloatVector function to be getParameterFloatVectorKnownLength. Added functionality to the GUI to hide and show the load YAML bar.

Finished implementing and connecting and testing the ControllerStatusBanner class into the flying agent GUI as a first step towards simultaneously making this cleaner and fixing the annoying GUI crash bug (other source of the bug could be the graphing in the CS1 controller tab)

Added ControllerStatusBanner class to the flying agent GUI as a first step towards simultaneously making this cleaner and fixing the annoying GUI crash bug (other source of the bug could be the graphing in the CS1 controller tab)

Small changes to active controller highlighting in the controller tabs part of the Flying Agent GUI in an attempt to remove the bug that causes the GUI to crash.

Made the maximum step duration 20 seconds for the CS1 controller. And changed the default values displayed in the fields

Added vertical banner to all GUI tabs indicating whether that controller is active not. Tested in simulation (there is a small chance this causes the GUI to occassionaly crash becuase of simultaneous setting of the properties of the banners). Tested in Simulation. Also fixed small mistake in the coordinator launch file

Connected the CS1 integrator buttons to the GUI and tested to be working in simulation. Needs testing on the real system

Added the remote controller tab widget to the GUI as a copy of the template controller. Next step is to connect it up

Added remote controller to GUI menu, enable and yaml buttons, and a tab. Compiles but needs testing. The tab itself still needs to be added

The test motors controller is now integrated to the flying agent client. The Default controller has the z integrator turned on, and the setpoint smoothing was slightly changed

Default controller compiles and is tested. Once remaining discrepancy is that the default controller switches into integrator mode too early

Finished implementing the Default controller (except for the integrator). Needs compiling and testing. (Also changed the ClientConfig.yaml to be FlyingAgentClientConfig.yaml)