Communication between crazyswarm and gazebo

[Andresf28]

We modify and add two scrips that will let us simulate crazyswarm's code in gazebo based in the CrazyS repo.

crazyswarm_py.py
This file has a new parser.argument that let us use the --gaz in terminal while running your python's trajectory script to launch drones in Gazebo. Before doing that, remember to run the .yaml file to select the number of drones that will be used in the fly and the .launch file in terminal to create the drone's world.

crazyflieGaz.py
This file contains the three fundamental methods for making your drones fly (Take off, go to and land). The above through nodes and topics which will be used by Gazebo while running the trajectory in your python script. Don't forget to check whether your script has all the arguments that the methods in this file require.

[jpreiss]

Thanks for the contribution! I think a lot of users are interested in this.

From skimming the code, it seems like the only supported commands are takeoff, goto, and land. Some code appears to be copied from crazyflieSim.py but not linked to Gazebo. For example, trajectory upload and low-level streaming setpoints.

It's also not clear how any of the simulation data from Gazebo would get back to the script. For example, I think most users will assume that the position() method reflects what they see in Gazebo, but that does not appear to be the case.

Unsupported methods should raise NotImplementedError rather than doing something confusing.

Regarding missing commands, I would be fine with merging a PR with raise NotImplementedError added as appropriate. @Andresf28 or other users can add the missing commands in future PRs as needed.

Regarding missing position(), I think it might be wise to implement that before merging. Then we can be sure the design is reasonable w.r.t. getting data back from the simulator.

[jpreiss]

Regarding the overall design: Another new simulator PR is #504, which is a ROS node that implements the Crazyswarm ROS API using the simulation logic of crazyflieSim.py. In comparison, this PR talks directly from the pycrazyswarm script to the Gazebo/RotorS ROS API.

We could also consider supporting Gazebo/RotorS with a design more like #504, with a ROS node that "translates" the Crazyswarm ROS API into the Gazebo/RotorS ROS API.

One advantage of the translation node is that it would be spawned by the launch file, so it could continue running through several scripts. This would save startup time of Gazebo (is it slow? I never used it). However, it would still need to be restarted whenever the user wants to reset the simulator to the crazyflies.yaml initial state.