Regarding the creation of RTOS tasks

[fangjir]

Why can't we merge stabilizerTask and sensorsTask into one task?
You can use semaphores to directly wake up the stabilizerTask, where you can call the functions of the sensor. What are the advantages of dividing into two tasks?

[knmcguire]

There are several reasons for this, modularity is one and assumptions is another. To read the sensor data at the same rate as the stabilizer loop also makes an assumption that the sensors runs at exactly the same rate as the stabilizer loop. By separating the sensor task from the stabilizer task, the imu is read out by their hearts desire and jump all that in a queue that the stabilizer loop acquires. Also at the same time it will send it in another queue for the estimator to make state estimation on as well. Remember that technically the deck tasks are sensor tasks too if they deal with decks with an added sensor.

In reality, sure, you can try to have the readout of the sensors and the stabilization task in one loop, and it will probably be fast enough it works, but that is the beauty of using these embedded OS's like freertos, you don't have to find out it's too slow since the task handling will care about it. The stabilizer task runs a lot including the state estimators and controllers and needs to be running as fast as possible all the time. I didn't design the firmware myself but I'd like it to be able to continuously run without being hindered, while it can look for new data once it is necessary, namely from a queue in this sense. Having all the tasks run in one thread, means that you have to care about the semaphores and interrupts and that is an extra load, but perhaps interesting to play around with if you'd like to dig into this kind of thing, but you might be reinventing the wheel here.

Hope that makes a bit of sense?