Simulation in ROS

[jpreiss]

Crazyswarm's simulation layer is great if your whole project can be expressed as a single pycrazyswarm script, but less useful if you want to use Crazyswarm as part of a nontrivial ROS setup. Instead, we would need a ROS node that publishes/subscribes to the same ROS topics and provides the same services as the Crazyswarm server, but instead of actually talking to the mocap and Crazyradio, it does something similar to pycrazyswarm's CrazyflieSim logic internally.

This seems like it would be a fairly easy project, any thoughts @whoenig?

[whoenig]

I think it is a good idea. Some thoughts:

Pros:

• Works in more standard ROS setups (like you said)
• Could be extended to interface with simulation for a subset of quadrotors (e.g., Gazebo + RotorS / CrazyS)

Cons:

• Potentially slower (especially if we do go the Gazebo route, which is slow even if physics is disabled for some quads)
• Simulation requires ROS (our current solution works without ROS for testing high-level scripts)

[jpreiss]

I should have clarified, I am not proposing this as a replacement for --sim. I was thinking more like a launch file command line arg for the crazyswarm server that causes it to run the simulation logic instead of connecting to the hardware.

[jpreiss]

If we port CrazyflieSim to C++ we wouldn't need any physics simulator. It only simulates an integrator. However, we would need to compile parts of the Crazyflie firwmare into the Crazyswarm server for things like piecewise polynomials and the onboard collision avoidance.

[whoenig]

I already have a solution for this, that works as follows: a user launches sim.launch rather than hover_swarm.launch. The 'simulator' is similar to the current one, i.e., there is no physics simulation and it is written in Python. It basically is a "mock" version of the crazyswarm_server, providing the same ROS topics and services (well, I only implemented a subset of it). Visualization is currently simply done in RVIZ (tf for positions and some special logic to visualize LEDs). The main use case for this was to allow distributed host computation, i.e., one ROS node per Crazyflie that does some more heavy computation. The only real drawback of this solution over the existing one are: a) requires ROS; b) probably slightly slower because of the sub/pub system. However, I think we offer both simulation methods at least for a while.

[jpreiss]

Yes, I think it's good to have the option to simulate with or without ROS. I would hope that the simulation core (the "flight modes" state machine, integration for streaming modes, and collision avoidance wrapper) could be shared between both modes.

[liamcollins]

@whoenig have you taken any steps towards implementing a sim.launch file? It would be of great use as I would like to integrate crazyswarm with a larger ROS ecosystem for other types of drones and run simulations along the way. I've got CrazyS up and running and was thinking about working on plugging it in to crazyswarm myself but it sounds like what you are proposing might be better/faster.

[whoenig]

I put what I had in a branch and created a draft PR, see #350. The description has one usage example. @jpreiss: the flight modes are shared in this code. I don't think this PR is complete (I only implemented features that I actually needed for the project), but the concept itself should be clearly visible. We can improve the branch until its ready to be merged. It worked pretty well for our research project (running computationally expensive things on the host and just communicating setpoints to the CFs).

[jpreiss]

Cool! The design in #350 is exactly what I had in mind. I will add minor comments to the PR.

[liamcollins]

I have another quick question on this - can you guys point me in the right direction to access pose data while running the sim?

I know rviz is doing it, just having some trouble figuring out where exactly to plug in. Would set enable_logging_pose: True help?

[marios-stam]

Hello, I modified branch dev-sim-ros and now the 3D model of the crazyflie can be depicted on simulation via Rviz through a Marker array. Should I commit my changes because I already see that there is an active PR regarding this branch?

[whoenig]

Neat! I don't think you have write access, but a PR is certainly welcome. The branch is just waiting for review from @jpreiss and can be merged afterwards.