search

whoenig / uav_trajectories

Helper scripts and programs for trajectories
MIT License
85 stars 46 forks source link

What made Trajectories capable to control more CF? #2

Open NicksonYap opened 5 years ago

NicksonYap commented 5 years ago

Hi

I some have waypoints generated from Blender image

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

whoenig commented 5 years ago

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.