You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a csv of the path shown above sequence_000.zip
It has: Timestamp (100ms interval), x,y,z (absolute) and r, g, b
I managed to use Crazyflie's official python lib's fadeColor for RGB and send_position_setpoint for xyz
With 1 radio, it works pretty well for 1 drone, however with more it flies a bit more wobbly and will not work for more than 4 drones (bandwidth issue)
Currently trying to use more radios (didn't help in first attempt)
I was told Crazyswarm has better communication efficiency, is it the
the pycrazyswarm in particular https://crazyswarm.readthedocs.io/en/latest/api.html
or is it Trajectories the same as the latest official lib? (in terms of efficiency/performance)
To better understand the problem, in what way could Crazyswarm handle 15+ CFs per radio compared to official python lib that could do only 3-4 per radio?
From my limited understanding, instead of blasting coordinates at every 100ms or faster, you pre-program certain trajectories (which we have no fine control over the time)
And activate them on-demand, thus greatly lowering the frequency / amount of communication required.
Or are there some fancy optimisation in the protocol level?
Could the goTo or go_to command also achieve 15+ CF per radio?
send_position_setpoint at 10hz can only go up to 3-4 CF per radio
The text was updated successfully, but these errors were encountered:
NicksonYap
changed the title
What made Trajectories more capable to control the CF?
What made Trajectories capable to control more CF?
May 8, 2019
You are correct that most of the improvement comes from pre-loading trajectories and then executing everything without the need of much communication. In the Crazyswarm, the radio is mostly used to broadcast pose/position information from the motion capture system. If you use the lighthouse or LPS localization systems, this would not be needed.
In principle, it is possible to improve the encoding for setpoints as well, but this would require modifications in the firmware and the client applications.
So if you use motion capture, I think one might be able to achieve around 8 CFs/radio if you also want to send position commands (and the position commands get encoded in a smarter way). If you use LPS/lighthouse, you should be able to get 15+ CFs/radio (if the positions commands get encoded in a smarter way). Without code changes, I think around 4 CFs/radio are realistic.
Hi
I some have waypoints generated from Blender

Here's a csv of the path shown above
sequence_000.zip
It has: Timestamp (100ms interval), x,y,z (absolute) and r, g, b
I managed to use Crazyflie's official python lib's fadeColor for RGB and send_position_setpoint for xyz
With 1 radio, it works pretty well for 1 drone, however with more it flies a bit more wobbly and will not work for more than 4 drones (bandwidth issue)
Currently trying to use more radios (didn't help in first attempt)
I was told Crazyswarm has better communication efficiency, is it the
the pycrazyswarm in particular https://crazyswarm.readthedocs.io/en/latest/api.html
or is it Trajectories the same as the latest official lib? (in terms of efficiency/performance)
To better understand the problem, in what way could Crazyswarm handle 15+ CFs per radio compared to official python lib that could do only 3-4 per radio?
From my limited understanding, instead of blasting coordinates at every 100ms or faster, you pre-program certain trajectories (which we have no fine control over the time)
And activate them on-demand, thus greatly lowering the frequency / amount of communication required.
Or are there some fancy optimisation in the protocol level?
Could the goTo or go_to command also achieve 15+ CF per radio?
send_position_setpoint at 10hz can only go up to 3-4 CF per radio
The text was updated successfully, but these errors were encountered: