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

Updated code tab of web interface so that files can not be uploaded asynchronously and placed in the correct location

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

PandS at home mostly ready

See merge request dfall/dfall-system!16

Added hint to update web interface shell script for how to add write access to the group for all files in the /var/www/html folder

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

Added first attempt at a web interface. This was used for the IFAC video, but needs more work to be used of the home version of the pands