跑控制演算法究竟是裸奔（跑在中斷里）好還是操作系統好？

01-08

現在有些控制演算法跑在操作系統（比如開源飛控px4）下，用線程實現，這樣實時性和裸奔比怎麼樣？ps:我自己覺得控制演算法用裸奔中斷實現最好，多線程實時性不好，畢竟控制器要求的還是一個「快」字，儘可能較小延遲。請大神來探討一下。

當然是盡量在裸機上編程更好，越簡單越不容易出錯么。

但是現實中，處理器或者單片機不能只是計算控制演算法，它還要和各種外設交換數據，在這個過程中，是需要有等待外設就緒的時間的。

比如我算完了控制輸出量，我要用dac把這個量輸出出去，而這個dac是spi介面的，我的單片機又沒有spi外設，只能用gpio模擬這個時序，我在data設定好了之後，還要等待一些時間等其穩定了，再送出clock的上升沿，然後再等待，保證clock的脈衝有足夠脈寬。在這等待的時間裡，就有文章可做了。寫個for循環，讓cpu空轉，這一段時間就浪費了，還增加了功耗。

這時候就可以讓cpu去幹些其他事情了。不太複雜的話可以自己寫調度機制，如果複雜了，何不使用ucos ii這樣自帶進程調度的微操作系統？比自己寫調度要省事可靠，功能還多。

注意一定要實時操作系統，對於基於模型的控制演算法，沒人希望因為控制率是不定的，而導致演算法離散化不成立吧？

在實現控制系統（而不僅是控制演算法）的時候，不能只想著控制率的那一畝三分地，還要考慮配合工作的硬體以及其他輔助功能。當系統夠複雜的時候，你會看到操作系統的好處的

調節器的控制演算法肯定是跑在中斷里好，可以最大限度減小中斷響應延遲，而且這個延遲在設計時就已經確定，幾乎完全由所用硬體決定；不像操作系統，還要有調度，操作系統的唯一好處是可以提高硬體資源利用率，實現多任務，但是純硬實時的應用中，需要更重視響應延遲和節拍，很多時候利用率和延遲這兩方面在不同應用中需要做取捨。

中斷處理應該只做和硬體直接打交道的、可以非常快處理完畢的事情。飛控演算法屬於任務邏輯，又不簡單，因此跑在RTOS中作為高優先順序task中比較好。而用RTOS，多個任務設計靈活得多。

至於時延，就看中斷造成的時延，與傳輸協議的時延（如uart，pwm，can，s-bus），執行機構（如舵機、電調）的時延相比有多少了。

我基於FreeRTOS試做的飛行控制系統上，測試系統從指令到響應的總時延中無法分辨因為採用task而非中斷造成的時延（估計幾十微秒？），主要是傳輸與作動的時延（幾毫秒）。畢竟我所控制的最內環角速度環的閉環帶寬也不超過5Hz。

能實現線程、多線程、多任務、多優先順序blabla的系統框架，也不是天上掉下來的，也不是刻在晶元架構里的，而是一句話一句話寫出來的。

因此，不管你在系統框架下怎麼寫，理論上都能寫出一個功能一樣但是更簡潔效果更好的出來——最不濟也能寫個一模一樣的出來——因為一模一樣的已經寫出來了——但是更好的那個憑我們的編程功力不敢說能不能寫出來。

現成的系統框架，比起自己搭一個系統框架，一般來說會犧牲一些靈活性，犧牲一些快速性，提高一些易用性，提高一些普適性，提高一些魯棒性。

「若止印三二張，未為簡易；若印數十百千本，則極為神速」——《夢溪筆談》

當然是操作系統里。有人會告訴你操作系統慢，沒錯，但是那是操作系統的問題，不是你的問題。當然你可以自己造一個操作系統，然後再將控制系統置入。

具體應用場景下，控制效果會告訴你怎麼來做硬體與軟體的妥協的。

你是Mr Liu？

對實時性要求高的控制系統，最好還是裸機跑控制演算法，當然也可借鑒操作系統進程的概念，設計兩個進程，一個進程放在中斷里，執行和伺服控制相關的，另一個作為常規進程，負責和上層通信！