CF Ignores some of the high-level commands

Discussions and questions about the Crazyflie Nano Quadcopter
tugayalperen
Beginner
Posts: 19
Joined: Mon May 14, 2018 8:33 am

CF Ignores some of the high-level commands

Post by tugayalperen » Fri May 17, 2019 8:21 am

Hi all,

I was doing repetative tests to make sure our Crazyflie 2.1's stability is okay. The test I was doing is simply using a script so much like test_high_level.py, with 2 CF takeoff-go 2m forward relatively-land and backwards and forwards again... The thing I faced is this, after 15-20 trials, one of the CFs ignores a command such that it does not takeoff, does not land or does not go forward. If I try again, everything works fine. Also I have no warning about link quality issue and I use 2 Crazyradio PA for 2 CFs. I am using crazyflie_ros btw.

I have tried with latest firmwares for stm32, nrf51, crazyradio PA in addition to release verisons of them. When they are flying, stability is perfectly okay. Only problem is that ignoring behaviour.



tobias
Bitcraze
Posts: 1911
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: CF Ignores some of the high-level commands

Post by tobias » Fri May 17, 2019 11:03 am

That is a bit strange. Could it be something with the battery level? Is it always between 15-20 trials or is it more random? What positioning system are you using? Thinking it could be some time related overflow or something like that.

tugayalperen
Beginner
Posts: 19
Joined: Mon May 14, 2018 8:33 am

Re: CF Ignores some of the high-level commands

Post by tugayalperen » Fri May 17, 2019 12:56 pm

Hi Tobias,

I am quite sure it is not battery level, I always measure it before and after flight and also the CF which ignores the command can perfectly listen the next one without any problem.

It is not always after many trials, sometimes it ignores the takeoff or the very first go_to command, but it is not very frequent. I would say it is random.

We are using Optitrack and vrpn-client as instructed, nothing fancy. I also monitor the external_position topic and Motive side, they seem okay to me.

If it is an overflow issue, what can I improve? Can it be related to external_position topic's frequency (it is not binded to Motive side frequency, which is 240 Hz). I also tried it with 120 Hz but I encountered with same problem. Should it be lower?

Thanks for helps,

tobias
Bitcraze
Posts: 1911
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: CF Ignores some of the high-level commands

Post by tobias » Mon May 20, 2019 12:52 pm

A tricky problem, it sounds like a communication problem, like packet loss or similar but that "shouldn't" happen. If you have any way to replicate it that would help a lot.

whoenig
Expert
Posts: 312
Joined: Mon Oct 27, 2014 2:55 am

Re: CF Ignores some of the high-level commands

Post by whoenig » Mon May 20, 2019 5:07 pm

See also https://github.com/whoenig/crazyflie_ros/issues/140. @tobias: In crazyflie_ros, we resend the command until an acknowledgement is received, but not until we get the answer generated here: https://github.com/bitcraze/crazyflie-f ... #L292-L295. In the firmware, what could cause an acknowledge to be send (NRF), but the packet not being processed on the STM?

tugayalperen
Beginner
Posts: 19
Joined: Mon May 14, 2018 8:33 am

Re: CF Ignores some of the high-level commands

Post by tugayalperen » Mon May 20, 2019 7:19 pm

To produce that loss, most critical points are sending many go_to commands one after another (you can think like dividing a trajectory into small linear parts and sending go_to commands accordingly) and using more than one radio for multiple crazyflies i.e. one crazyradio PA for one crazyflie. The situation exists on both cf 2.0 and 2.1. I understand that repeating high-level go_to commands is meaningless since every one them repeats itself until it gets an acknowledge response, yet repeating them solves the problem. By the way, do not think that ignoring behaviour is limited to go_to, it can occur at takeoff or land also.

tobias
Bitcraze
Posts: 1911
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: CF Ignores some of the high-level commands

Post by tobias » Tue May 21, 2019 9:46 am

I have not used the ros driver that much but I know there is a broadcast functionality. I'm guessing you are not using this?

There is no acknowledgement that a packet has been processed by the STM, only that it has been received by the NRF, so potentially something could get lost there, but I doubt it. I will try to make a test for this.

tugayalperen
Beginner
Posts: 19
Joined: Mon May 14, 2018 8:33 am

Re: CF Ignores some of the high-level commands

Post by tugayalperen » Tue May 21, 2019 10:45 am

No, apparently I am not using broadcast messages, instead I am using high-level functions. I am curious about your tests then, thanks.

marcus
Bitcraze
Posts: 599
Joined: Mon Jan 28, 2013 7:02 pm
Location: Sweden
Contact:

Re: CF Ignores some of the high-level commands

Post by marcus » Wed May 22, 2019 8:46 am

I've started looking into the missing packages a bit. After looking at the USB communication a few weeks ago we have some scripts that uses the LINK ECHO port (code here). The port will echo back what ever data is sent to it.

When running the test above yesterday I had lots of issues and was loosing packages and geting duplicates. Turns out there was another Crazyflie in our office on the same channel that was causing issues. When only having one Crazyflie on the same channel the test works perfectly :roll:

I'll do a bit more testing this today and see if I can find something.

arnaud
Bitcraze
Posts: 2122
Joined: Tue Feb 06, 2007 12:36 pm

Re: CF Ignores some of the high-level commands

Post by arnaud » Tue Jun 11, 2019 7:33 am

I solved a bug last week that could lose packet if the packets where not read fast enough by CRTP ports: https://github.com/bitcraze/crazyflie-f ... issues/434. There is not a queue of 16 packets for each ports (only 1 previously) and the Crazyflie will crash if one of these queue overflows.

With this fix and using the fixed USB I cannot get the echo script that Marcus sent to fail anymore, so it seems that we do not have loss packet anymore in the STM32.

Post Reply