Hi all,
I want to ask if there's particular considerations to take in account about interrupts and stabilizator algorithm. I see that stabilizator task stay in delay and starts 500 times in a second. But since you are using RTOS(I don't know a lot about it) you have setted some kind of priority on stabilizator task like "no interrupts untill computations are not finished" or to not change task untill stabilizator task has not finished? and if you are in something like on peripheral transfer that can't be stopped(in the case you are not using dma) and stabilizator task is delayed that create some problems or this function is not that critical as i think?
About stabilizator data(pitch, roll, yaw), what is the frequency at you send packets of new values?
Thank you!
Stabilizator and data rate form controller
Re: Stabilizator and data rate form controller
Hi,
As far as I can remember we are not disabling interrupt anywhere in the code. The stablization task is high priority which means that it will run instead of all the other lower priority task. When it call a delay, it sleeps and will allow other tasks to run. The RTOS guarantees that the highest priority task that is not sleeping is running. Interrups are running in parallel and in some case will unlock a task (for example a task can start an I2C communication and lock on a semaphore, it will then go to sleep, when the I2C interrupts run it unlock the semaphore and the RTOS will wake-up and run the task).
The commander packet, that contains pitch/roll/yaw is sent at at least 20Hz from the ground (I think it is 50Hz in the client). The copter has a timeout, if no commander packet are sent for more than 1 seconds the motor stops.
As far as I can remember we are not disabling interrupt anywhere in the code. The stablization task is high priority which means that it will run instead of all the other lower priority task. When it call a delay, it sleeps and will allow other tasks to run. The RTOS guarantees that the highest priority task that is not sleeping is running. Interrups are running in parallel and in some case will unlock a task (for example a task can start an I2C communication and lock on a semaphore, it will then go to sleep, when the I2C interrupts run it unlock the semaphore and the RTOS will wake-up and run the task).
The commander packet, that contains pitch/roll/yaw is sent at at least 20Hz from the ground (I think it is 50Hz in the client). The copter has a timeout, if no commander packet are sent for more than 1 seconds the motor stops.