All Positioning System Support

[yfaws]

Hi!

As you mentioned in FAQ section of documentation,"Crazyswarm2 is designed to support other localization methods (lighthouse, or on-board only localization) from the start." I want to use UWB and lighthouse localization system using crazyswarm2. I have some questions about it.
Does current Crazyswarm2 Python api support receiving CFs poses ? I reviewed the code, but I could not see such feature if I did not misunderstand.And, if I did not misunderstand, whwn do you plan to implement this feature?

Thanks..

[whoenig]

We have not implemented logging yet, which is the missing feature to stream the poses to the PC. However, you should already be able to fly with UWB and Lighthouse (we only tested the latter).

@knmcguire is implementing logging in the cflib-backend within the next few weeks or so. For the C++ backend, it might take a bit longer to get this support, as proper (physics)-simulation is currently higher up on our priority list.

[yfaws]

Thanks for answer.

While using crazyswarm(USC repo), I tried to use uwb and couldn't get good enough performance with more than 4 drones.
According to my observation, it was due to very frequent preemption by motion capture thread. Then I used directly crazyflie_ros repo which you have developed. It performed much better than crazyswarm in uwb and ligthhouse positionning system.
Just for little suggestion.

[knmcguire]

Both lighthouse and loco positioning are pure onboard estimation positioning system, so nothing of those two systems goes through the crazyradio to the computer and back. So it is unlikely that crazyswarm1 had anything to do with that. Perhaps the locopositioning system you used was maybe set in a different mode?

[knmcguire]

any questions about the loco pos and lighthouse system and the quality of it should be asked on the bitcraze discussion page: https:/discussions.bitcraze.io/ as they are the main developer of those.

[whoenig]

In Crazyswarm2, there is no "motion capture thread" anymore. Anything related to the mocap is a separate package. If you fly without motion capture, you simply do not run nodes from this separate package.

In Crazyswarm1, there was a "motion capture thread", but this was disabled when setting motion_capture to None, so as Kimberly said it shouldn't have had much of a performance impact.