Hello,
implementing some new features in the stabilizerTask, I made the following observation:
As soon as I attach the Loco Positioning Deck I get an assert message tracing back to line 379 of uart_syslink.c. Detaching the deck the firmware keeps on running as desired.
Do you have some advice how to handle this issue? Would it be recommendable to transfer my code to another task, trying to solve this issue by means of task priorities? In fact some parts of the code - related to waypoint planning - are not time-critical but there is some amount of data which had to be passed between this task and the stabilizer task which is the reason why I tried to avoid this so far implementing my algorithm in - maybe not as effective as desired - an iterative fasion.
One minor question I am just curious about: What is the purpose of the compressState/compressSetpoint functions, are they just for processing Logging data?
Any advice would be appreciated! So far, have a nice weekend
Klaus
uart_syslink assert
Re: uart_syslink assert
Hey again,
I just read on your page https://github.com/bitcraze/crazyflie-f ... -565082332 that the firmware from December 2019 solved the UWB/LPS Deck issue - which might be related to my problem.
However, in our lab we are working with a local version dating back to early 2019. Could you provide information what was the solution such that I could modify our version.
Maybe I have to think of synchronizing our development branch with the current firmware as far as possible.
I just read on your page https://github.com/bitcraze/crazyflie-f ... -565082332 that the firmware from December 2019 solved the UWB/LPS Deck issue - which might be related to my problem.
However, in our lab we are working with a local version dating back to early 2019. Could you provide information what was the solution such that I could modify our version.
Maybe I have to think of synchronizing our development branch with the current firmware as far as possible.
-
kristoffer
- Bitcraze
- Posts: 630
- Joined: Tue Jun 30, 2015 7:47 am
Re: uart_syslink assert
The change we did was to break out the kalman filter into a separate task. It used to run as a part of the stabilizer loop and in some cases the processing took too long. Since the stabilizer task runs on high priority (5) it did delay other tasks, for instance reading from a UART.
The changes are fairly well encapsulated in The https://github.com/bitcraze/crazyflie-f ... issues/495.
The changes are fairly well encapsulated in The https://github.com/bitcraze/crazyflie-f ... issues/495.
The compressed data types were introduced by the Crazy swarm project. They are sending massive amounts of position data to the members of a swarm and wanted to optimize the bandwidth use over radio.One minor question I am just curious about: What is the purpose of the compressState/compressSetpoint functions, are they just for processing Logging data?
Re: uart_syslink assert
Hello Kristoffer,
thank you very much for your comments. In fact I was a bit quick in posting before reading your update messages concerning the firmware. In addition, since my team is fairly new to the topic, we made some mistake setting up our git repository so we got decoupled from your updates.
We have fixed this issue, also this caused two days of work to get our modifications aligned with your current status however, I have some trouble concerning debugging.
I will post this under a new topic, since this is not relating to this problem.
Compress Data: This is interesting also for us, since we are aiming on a truly decentralized swarm system and one of my students is currently making first progress in developing broadcasting with the nrf51822. However, it seems to be a longer, thougher way than I anticipated.
thank you very much for your comments. In fact I was a bit quick in posting before reading your update messages concerning the firmware. In addition, since my team is fairly new to the topic, we made some mistake setting up our git repository so we got decoupled from your updates.
We have fixed this issue, also this caused two days of work to get our modifications aligned with your current status however, I have some trouble concerning debugging.
I will post this under a new topic, since this is not relating to this problem.
Compress Data: This is interesting also for us, since we are aiming on a truly decentralized swarm system and one of my students is currently making first progress in developing broadcasting with the nrf51822. However, it seems to be a longer, thougher way than I anticipated.
Re: uart_syslink assert
Hello,
I just want to refer to my second post concerning firmware crashes when debugging. I supposed the problems would be decoupled but it seems the uart issues using Flow Deck v2 and LPS deck simultaneously seem to be even more critical in the new firmware - at least for Crazyflie 2.0 and using the debugger.
Any solution for this issue would be highly appreciated. One of our research objectives crucially relies on the ability to have both decks attached to at least some crazyflies in a swarm.
I just want to refer to my second post concerning firmware crashes when debugging. I supposed the problems would be decoupled but it seems the uart issues using Flow Deck v2 and LPS deck simultaneously seem to be even more critical in the new firmware - at least for Crazyflie 2.0 and using the debugger.
Any solution for this issue would be highly appreciated. One of our research objectives crucially relies on the ability to have both decks attached to at least some crazyflies in a swarm.
Re: uart_syslink assert
It seems like this issue is now being handled in other threads, so lets discuss on there.