Firmware crashes induced by Logging / Loco Deck (Computational overloads?)

Post Reply
Posts: 15
Joined: Mon Feb 25, 2019 10:35 pm

Firmware crashes induced by Logging / Loco Deck (Computational overloads?)

Post by keffi » Thu Aug 08, 2019 3:13 pm


I am relatively new to the crazyflie 2.0 quadcopter developement.

Currently I am trying to implement own algorithms for navigation and control. The plan is to use the crazyflie in the flight control courses as hardware plattform for the students and also to do some research on cooperative estimation and control in the foreseeable future.

Nevertheless, I replaced the estimator_kalman by a slightly different navigational algrotihm (error based kalman fitler combined with a strapdown navigational algorithm) and I am facing strange behaviours: A "small" filter containing a 9 dimensional state vector is already working fusing data from the flow deck 2 and the IMU. Now, I am facing some phenomena and I would be very grateful for any advices helping me to overcome these issues.

1) "Small" 9 State Filter with locodeck
I attached the locodeck and when starting the crazyflie the firmware (with the 9 state filter) crashes just after startup. This effect is directly linked to the incorporation of the loco deck, if it is detached, the behavior is normal again. I was able to solve this lowering the priority of the uwb task from 5 to 3. This seems to work again (I have to try it in the lab next week with the LPS installed) but I am not sure whether this solution might cause problems elsewhere. Its kind of annoying since the 9 state estimator already existing in the firmware seems not to have this problem. Nevertheless, I have to mention, my algorithm is currently running at an 1 ms interval and not the 10 ms of the existing implementation, so it might have more computational load. Are such issues the reason for running the firmware kalman filter at the 100 Hz rate?

2) Extension to 15 state filter seems to lead to an computational overload (even without locodeck)
However, I want to extend my algorithms to a 15 state version being able to estimate the sensor biases of the IMU in acc and omega. Now my problem is, as soon as I extend the filter, the firmware seems to run normally (just assuming from the normal LED blinking) but as soon as I try to connect via the crazyradio to receive log-data from my filter, the firmware crashes instantenously. I am very sure that I got rid of any programming mistakes since most critical parts are just parameterized versions from the 9 state filter which works as desired.
By means of the stlink-v2 debugger I am able to trace back the error to the uart_syslink.c line 379. It seems that the computational load running the stabilizer task with the new filter is already at a limit and then, when connecting to the radio, there is an "overload". I tried several things (lowering the priority of the logging task in the config.h / reducing the update rate RATE_MAIN_LOOP to RATE_500Hz since I am convinced, that 500 Hz should be enough for a flight controller to work properly, however I was not able to solve this problem - I also tried to just slow down my filter to 100 Hz in a similar manner it is done in the estimator_kalman.c).
Any advices would be highly appreciated. Since I plan to add additional algorithms in the future, the computational resources must be used in a reasonable manner.

3) Locodeck issues without filter-modifications
Some of my students try to make some modifications to the crtp_commander and the cflib in order to receive position information from other crazyflies to go for a decentralized formation control. Also in this project (introducing a so called "cooperative commander" on port 9) crashes in the firmware are appearing when the locodeck is attached, without the locodeck, there was no problem (same phenomenon as with the filter).
It seems to be related to the sequence of calling the crtp_init function and (by chance) we found a sequence which also works fine now. However, it seems that the locodeck is somehow destabilizing timing behaviors in the firmware and/or the current algorithms without any modifications already push the stm32f close to its computational limits.

It would be very helpful to get a better understanding how the locodecks affects the system in order to get a better insight how to avoid such issues. Finally, I want to stress, that the filter project an the formation control project are working on seperate versions taken from the original firmware, so there is absolutely no interference between these projects currently.

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

Re: Firmware crashes induced by Logging / Loco Deck (Computational overloads?)

Post by tobias » Fri Aug 09, 2019 1:27 pm

Thank you for well written problems. In summery, it sounds like some of the problems can be related to "Flow deck and Loco deck in TWR mode makes Loco deck hang" bug and there is a potential solution described there, but I don't think that is the root cause, just a way to relax the uwbTask. I think more of a bug in the dmw1000 driver state machine that we have been unable to find yet. There is also a high probability you are seeing all sorts of new bugs when you load the system. There is a way to take a snapshot load of the system in the console tab in the cfclient. Might be worth trying to get a feeling of how loaded the system is.

Post Reply