We now have a parameter set_value that sets the parameter value on the crazyflie. Currently it is blocked until the crazyflie not only received the full toc but also has downloaded all the values, as it technically doesn't send the parameter directly, but the parameter set that has been downloaded in the cflib.
Technically we could set the parameter after the TOC has been received, as that is faster since TOC can be cached but the values can not. The chance is only that there is a change that the value downloaded on the cflib can be overwritten while it is has been downloaded which could cause issues if not handled properly.
Have a block of the set_value, that checks if the setting is happening simultaneously or if it has been set by the cflib upon startup (such that it ignores the value of the crazyflie and sets the cflib one, or whoever we think has higher authorization)
Have a function that is between set_value and set_value_raw, which is basically set_value_raw but it wait until the toc such that you don't have assume the type.
This might improve the appeared connection speed for swarms significantly.
We now have a parameter set_value that sets the parameter value on the crazyflie. Currently it is blocked until the crazyflie not only received the full toc but also has downloaded all the values, as it technically doesn't send the parameter directly, but the parameter set that has been downloaded in the cflib.
Technically we could set the parameter after the TOC has been received, as that is faster since TOC can be cached but the values can not. The chance is only that there is a change that the value downloaded on the cflib can be overwritten while it is has been downloaded which could cause issues if not handled properly.
This is the set_value for params:
https://github.com/bitcraze/crazyflie-lib-python/blob/be04130ac89acdbe7bd3b26684eb95db753ee564/cflib/crazyflie/param.py#L332-L367
Either two ways we can solve this:
This might improve the appeared connection speed for swarms significantly.