SITL testing

[jpreiss]

I just learned about this project, but it's over a year old: https://github.com/wuwushrek/sim_cf

More discussion: https://forum.bitcraze.io/viewtopic.php?f=2&t=2929

Apparently the author(s) already implemented a fairly complete SITL (sofware in the loop) simulation with FreeRTOS running on x86, sensor emulation, and physics from Gazebo.

It would be very cool to use this for Crazyswarm testing. In theory, we could run all of our current unit tests with ROS, crazyflie_cpp, the firmware radio parsing, and firmware control in the loop. It seems like they have already achieved crazyflie_ros compatibility and possibly copied some code from crazyflie_ros and/or crazyswarm (see crazyflie.py, uav_trajectory.py and test_high_level.py for usage in https://github.com/wuwushrek/sim_cf/tree/master/crazyflie_gazebo/scripts).

It may not be that much work to use it in our tests. For example, we may be able to add crazyflieSITL.py alongside crazyflieSim.py and crazyflie.py.

Not proposing anything concrete yet, but interested in others' thoughts.

[EnricaSo]

Hi @jpreiss!

I am currently using sim_cf and Crazyswarm for my research: the first for sitl testing and the second for hitl testing.

However, the problem I often have is that the crazyflie_firmware used in sim_cf is a fork and it is not up to date with the bitcraze firmware. Same for crazyflie_ros.

It would be really good to somehow unify these projects, not only for testing, but also for developing and training new algorithms in simulation!

[ThomasCarstens]

Hello, to echo this. I explored sim_cf 10 days ago, I am currently using Crazyswarm in my work.
My interest isn't sitl or hitl, rather the visualisations of IMU data, and the ability to visualise the drone in gazebo (a "ghost" of the drone). So far I know that I cannot both execute the crazyswarm hover_swarm and spawn a ghost in gazebo - lib busy.
Where would I start?
(let me know if I should start a new topic)

[jpreiss]

@EnricaSo ah, I see. From our past experience at USC, maintaining a forked firmware is not desirable. So I guess bitcraze would need to accept the SITL support into the main firmware for this to be a viable long term plan.

It seems like SITL testing would be quite useful for any CF developer. If the code changes are not intrusive I think it would have a good chance at acceptance. But there might be a lot of design discussions.

[jpreiss]

@ThomasCarstens please start a new issue. By "lib busy" do you mean LIBUSB_ERROR_BUSY?