Hello
I send data to my app during flight using parameters ( I know it is not the best method but it is the simplest )
Sometimes for some reason parameters are not sent correctly. So I use the callbacks - cf.param.add_update_callback(...)
to make sure parameters are updated. But it can be a bit slow and inefficient, since it is reading back the whole variable.
I recently saw this commit that implements confirmation for update in the CRTP packet. Is it implemented on the Python library side? If I send a parameter using the Python lib, do I get some feedback whether it was updated correctly (or will it raise exception for failure)?
thanks!
how to make sure param is updated correctly
Re: how to make sure param is updated correctly
Hi,
First of all setting real-time parameters can be a good solution as long as there is a single value to set: etting a parameter only sends one packet so it is as efficient as implementing your own custom CRTP packet.
When setting parameter, the theory is that the radio link should be perfect and so sending the set parameter packet guarantees that eventually the packet is going to be set. In that sense, there is no need for a confirmation when setting a parameter from CRTP and the commit you are linking allows to get notified when the Crazyflie firmware sets a parameter by itself, this is required to make sure the PC is updated about the new parameter value.
In recent crazyflie python lib and firmware (ie. less than ~3 years old) we have the 'safelink' protocol used on the radio link that guarantees no packet loss.
So, unless there is a bug, there should not be any problem setting parameters. I assume you are using a recent version of both the firmware and the lib. To make sure, you can update the full firmware (radio and stm) using the Crazyflie client, this will ensure safelink is activated (I am not sure it is there out of factory). How fast are you setting the parameters and can you find a pattern for when it is failing?
First of all setting real-time parameters can be a good solution as long as there is a single value to set: etting a parameter only sends one packet so it is as efficient as implementing your own custom CRTP packet.
When setting parameter, the theory is that the radio link should be perfect and so sending the set parameter packet guarantees that eventually the packet is going to be set. In that sense, there is no need for a confirmation when setting a parameter from CRTP and the commit you are linking allows to get notified when the Crazyflie firmware sets a parameter by itself, this is required to make sure the PC is updated about the new parameter value.
In recent crazyflie python lib and firmware (ie. less than ~3 years old) we have the 'safelink' protocol used on the radio link that guarantees no packet loss.
So, unless there is a bug, there should not be any problem setting parameters. I assume you are using a recent version of both the firmware and the lib. To make sure, you can update the full firmware (radio and stm) using the Crazyflie client, this will ensure safelink is activated (I am not sure it is there out of factory). How fast are you setting the parameters and can you find a pattern for when it is failing?
Re: how to make sure param is updated correctly
Thanks for the detailed reply.
I am trying to set 2 parameters at about 4-5 hz. (so 8-10 updates /sec)
I will try to look into custom CRTP packet , it seemed intimidating at first. Would love to know it there is a tutorial or example somewhere.
I am trying to set 2 parameters at about 4-5 hz. (so 8-10 updates /sec)
I will try to look into custom CRTP packet , it seemed intimidating at first. Would love to know it there is a tutorial or example somewhere.
Re: how to make sure param is updated correctly
2 parameters set at 4-5Hz should not be any problem.
- Have you updated your firmware to the latest version (including the nRF51 firmware, the best is to upgrade to 2020.9 using the Crazyflie client)?
- Do you setup a lot of log blocks or have anything else that creates a lot of radio traffic or load the CPU a lot?
As for using CRTP, it is not very hard, but there is a little bit of address allocation work since you need to define and take a CRTP port for your app, and then you can send packet and register a callback on this port. We have been talking about making an app communication channel to avoid dedicating a full port to it (the are in quite limited supply) and to make a dedicated API. I have created a ticket on the crazyflie fiwmware github and I am looking at it right now, I will update this thread when it is done
.
- Have you updated your firmware to the latest version (including the nRF51 firmware, the best is to upgrade to 2020.9 using the Crazyflie client)?
- Do you setup a lot of log blocks or have anything else that creates a lot of radio traffic or load the CPU a lot?
As for using CRTP, it is not very hard, but there is a little bit of address allocation work since you need to define and take a CRTP port for your app, and then you can send packet and register a callback on this port. We have been talking about making an app communication channel to avoid dedicating a full port to it (the are in quite limited supply) and to make a dedicated API. I have created a ticket on the crazyflie fiwmware github and I am looking at it right now, I will update this thread when it is done
.Re: how to make sure param is updated correctly
I added an "app channel" API that allows to send and receive raw packets of up to 31 bytes: https://github.com/bitcraze/crazyflie-f ... python-lib
There is function both in the firmware and in the python lib to use this channel.
I am still interested to know a bit more about the problem you are seeing with the params though, there should bet no reason transmitting raw crtp packet will work any better than the params. So if it does, there is a bug somewhere in the param implementation.
There is function both in the firmware and in the python lib to use this channel.
I am still interested to know a bit more about the problem you are seeing with the params though, there should bet no reason transmitting raw crtp packet will work any better than the params. So if it does, there is a bug somewhere in the param implementation.