Architecture
The project leverages two ROS stacks (=set of packages).
| Name | Author | alias | License | Project Page |
|---|---|---|---|---|
crazyflie_ros |
Wolfgang Hoenig | whoenig | MIT | https://github.com/whoenig/crazyflie_ros |
sim_cf |
Franck Djeumou | wuwushrek | https://github.com/wuwushrek/sim_cf |
Driver between ROS and the custom Crazyflie communication protocol (CRTP: Crazyflie Real-Time Protocol).
Implements a central server to which real/virtual Crazyflie can be connected. Each of them gets its namespace, in which:
- orders (including setting parameters) can be issued through services
- logs are made available through topics
Simulation stack for Crazyflies. Simulate the response of crazyflie to CRTP orders (the same that could be sent to a real one). It combines the emulation of the software and physic reponses.
- The physics engine is Gazebo.
- There are two choices for the software part:
- SITL (Software in the Loop): the computer runs the official crazyflie firmware
- HITL (Hardware in the Loop): the software behaviour is offloaded to a real crazyflie that is connected to the computer
Below diagroam describes how software stacks interact with each others:
- red: in a real experiment
- blue: during a simulation
I couldn't help but explain my design with a (admittedly limited) boat analogy:
- the admiral gives the targets to reach: he is responsible for the general strategy. He doesn't care which boat go where, as long as the target zone are reached.
- the captain fill in these orders with a practical plan: each boat (drone) gets:
- a target
- a path to reach it
- the mate of a ship is in charge of following the path, and avoiding collisions
- the lookout gives localisation data to everyone that needs it
- the core is all the backbone infrastructure that make the rest work
The limits to that analogy being that all of this roles happen :
- in the same computer
- with perfectly shared information
- without communication delays
