added some comments in the StudentController yaml to indicate that the mass should be closer to 32g for the at home set up and the frequency should be 50Hz for the at home setup.

Upgrade the crazyradio cflib to release 0.1.10 (13 Mar 2020) from the crazyflie-lib-python repository on the bitcraze github

VERSION NUMBER UPDATE: to reflect updating of firmware with a generic package handler, and adding of a web interface

Adjust the size of the ViconData and CFOnboardEstimate queues to avoid processing old data (this may be the reason that the CF flys too high on first take-off when using CF onboard estimates

Added the Crazyflie.db database back to the repository with a default configuration of agent 1 controlling CF01 in a generously size box

Web interface now working for launching both the master and agent. VERY IMPORTANT is the command added to the web interface install script that the www-data user must be added to the plugdev group so that nodes launched by the web interface have permission to access the CrazyRadio USB dongle

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.

Corrected delaration of a quadrotor simulation in the CrazyRadioEmulator node, required editing the CMakeList

Started with adding a quad simultor to the CrazyRadio emulator node so that the code can be tested in simulation for flying based on onboard estimate data

Added Kalman filter reset to the CrazyRadio python node anytime the flying state changes from motors off to something else

Updated the flying agent client node so that can easily choose between mocap data or onboard estimate data, or both, by using the yaml parameters. Needs testing. Next step is to update the CrazyRadio emulator to simulate a quad so that these updates to the flying agent client can be tested in simulation

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.

Corrected small error in the Student controller for confirming with the new Control Command message definition. Cleaned up a few small things at the same time.

Updated the Crazyflie firmware to correctly parse the new package type that was implement in the previous commit to the CrazyRadio node. Needs testing, but before testing, the next step is to make the flying agent client easily choose between Vicon or the CF state estimate

Fixed some small BUUUUUGGGGGGGSSSS so that the student controller service now compiles, mainly missing semi-colons from Jeremys edits because he is not able to compile on his machine to find these BUGGGGGSSS

Updated the Crazyradio node in prepartion for the new generic control command package type that is sent to the Crazyflie and also to log the state estimate back from the Crazyflie. All the Controllers are also updated and tested to compile with this new package type as the response. Needs to be tested in simulation. Next steps are to: 1) adjust the Crazyflie firmware to parse the package correctly, and 2) make the flying agent client easily choose between Vicon or the CF state estimate

Removed computeMotorPolyBackwards from StudentControllerService.cpp and instead included it in the GetParametersAndNamespaces.h and .cpp files with a new name newtons2cmd_for_crazyflie. Put some example yaml parameters in for students and commented in StudentControllerService.cpp where they should define class variables. Added a get debug values service.

NOTE: This required the CF_COMMAND_TYPE_ constants to be changed,
      see Constants.h.
      Hence, for the crazyflie firmware to be compatible with the
      ROS node software, both must be either before this version
      or after.

For the system config GUI, this commit comments out some debugging print out statements that fills the terminal with unecessary information

Added the first working files for Qualisys integration. Next steps for Qualisys integration are to adjust the System Config GUI and mocap naming conventions so that the user can seemlessly choose between Vicon and Qualisys.

VERSION NUMBER UPDATE: to reflect the upgrade to add a CS1 controller and other small GUI improvements

Updated the csone picker remote template and tuning controllers to correctly respond to the is first controller call flag

Added a flag in the controller call so that the flying agent client node notifies the controller being call of whether this is the first call or not. The default controller and student controller correctly respond to this flag, while the other controllers need to be updated to take it into account