Assert failed at radiolink.c:164

Post Reply
Posts: 1
Joined: Tue Apr 20, 2021 9:23 am

Assert failed at radiolink.c:164

Post by Sven »

I am currently using the crazyflie for my work on computationally efficient Moving Horizon Estimation. For this purpose, I have implemented my algorithm alongside the other estimators and connected it within the rest of the firmware following the same approach as the EKF. During debugging and testing on the drone, I regularly encounter problems with the radiolink, specifically a failed assert at .//src/hal/src/radiolink.c:164. Despite my best efforts I can't seem to pinpoint the source of the issue, it only appears sporadically after 2-30s of the code running fine, and it sometimes disappears again in new iterations of my code.

From my understanding, the assert fails if the 'crtpPacketDelivery' queue is full, so I tried to double its size (5->10) with only limited success (same file, line 49).

My suspicion is, that the queue fills up due to timing problems when my code runs for a bit longer at a time, but I was expecting freeRTOS to handle this based on task priorities. However, it doesn't seem to be a case of overloading the system (Task dumps show my estimator task at 5-10% load, leaving over 60% idle time, which is similar to the EKF).

Does anyone have an idea what might be causing the problem, and what could be done to solve it?
Posts: 2465
Joined: Tue Feb 06, 2007 12:36 pm

Re: Assert failed at radiolink.c:164

Post by arnaud »

FreeRTOS does handle tasks based on priority, but the estimator is set as pretty high priority since it is the most important code in a flying platform, so it can starve the rest of the system. I am not sure this is what is happening there however, you should be hitting the watchdog in that case: the watchdog timer is reset by the IDLE task which can only run if nothing else needs CPU time in the system. So as long as the watchdog is not kicking-in and resetting the Crazyflie, the system still has some CPU margin left.

Have you implemented anything that touches the communication or are you sending any particular packets at high-rate to the Crazyflie? I have been able to trigger this assert very reliably by adding a delay in the CRTP echo service and by sending a lot of echo packet over the radio: because of the delay, the packets accumulates in the RX queue and this assert is triggered. We have a ticket about implementing a solution for that, the solution is to implement flow-control between the STM and the nRF radio chip: ... issues/703.

The reason the flow control is not implemented yet though is that it is a quite big change that require careful design, and that it should not be a problem in normal operation of the Crazyflie: all our current CRTP ports consumes the packets faster than they can be sent over radio.

So, my first though, is to check that you are not stalling any CRTP RX port or sending packets at high-rate.
Post Reply