Replies: 1 comment
-
Hi @eurkaaaa ! Yes, exactly the CPX a protocol located above the UART protocol. Im not sure exactly what you question is unfortunately. The CPX initialization is (cpxInit) is done in the driver for the deck that uses CPX. This is to enable the driver to run on the Crazyflie, and talk to the deck in question. Its hard to say why the position data became unstable. In your previous question you said that you had introduced a delay. This might be causing the instability. I think I need a bit more info on your use case and your issue to be able to help you better. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello, I'm a beginner of crazyflie. Firstly, I'm grateful for your reply of the issue which was consulted on January 21st. Let me describe the problem clearly.
There are four initialization functions in cpx-host-on-part 2 are cpxUARTTransportInit(); cpxInternalRouterInit(); cpxExternalRouterInit(); cpxInit(). And cpx-host-on-part 2 is initialized as a virtual deck, that is initialized at the system service layer.
In my understanding, cpx should be an upper-layer protocol, and its initialization should not be located in the underlying position, so we extracted these four functions into UserAPP and found that it seems to communicate.
However, when we plug in the flow deck, the data displayed on the flow deck became unstable.
Moreover, I don't understand the reason of the initialization part of cpx is located in the system service layer.
I am looking forward to your reply, thank u
Beta Was this translation helpful? Give feedback.
All reactions