1. 項(xiàng)目概述與核心痛點(diǎn)先說說為什么我要手搓這個(gè)PID實(shí)時(shí)調(diào)參可視化控件。搞過電機(jī)控制、無人機(jī)姿態(tài)解算、平衡小車、溫控系統(tǒng)這些項(xiàng)目的朋友應(yīng)該都體會過PID參數(shù)整定的痛苦改一次參數(shù)編譯燒錄看串口打印的波形再改再燒錄來回折騰半小時(shí)結(jié)果曲線還是亂飄。用串口助手加Excel畫曲線數(shù)據(jù)量一大就卡而且完全沒法實(shí)時(shí)交互。買商業(yè)上位機(jī)一套動(dòng)不動(dòng)幾千塊還未必適配自己的通信協(xié)議。所以我決定用Qt和C自己寫一個(gè)PID實(shí)時(shí)調(diào)參可視化控件把“改參數(shù)”和“看曲線”這兩件事做到同一個(gè)界面里參數(shù)一拖動(dòng)波形立刻反饋像調(diào)均衡器一樣直觀。這個(gè)控件屬于嵌入式上位機(jī)開發(fā)領(lǐng)域核心解決的是PID調(diào)試效率問題適合做嵌入式控制、機(jī)器人、自動(dòng)化設(shè)備的開發(fā)者直接拿去用也適合想系統(tǒng)學(xué)習(xí)Qt繪圖和C信號槽機(jī)制的初學(xué)者反復(fù)琢磨。先把最終效果擺在前面主界面左側(cè)是一排PID參數(shù)滑桿和數(shù)值輸入框右側(cè)是QCustomPlot繪制的實(shí)時(shí)響應(yīng)曲線支持位置式PID和增量式PID兩種模式切換曲線可以隨時(shí)暫停、縮放、導(dǎo)出數(shù)據(jù)。串口或網(wǎng)絡(luò)數(shù)據(jù)進(jìn)來后控件內(nèi)部完成PID閉環(huán)計(jì)算同時(shí)把設(shè)定值、實(shí)際值、輸出值三條曲線直接畫出來。調(diào)參的時(shí)候拖一下Kp滑桿100毫秒內(nèi)就能看到響應(yīng)曲線的變化趨勢不用反復(fù)編譯燒錄效率提升是肉眼可見的。全文會從整體架構(gòu)設(shè)計(jì)、PID算法核心實(shí)現(xiàn)、可視化方案選型、參數(shù)交互刷新機(jī)制這幾個(gè)維度展開最后附上源碼結(jié)構(gòu)和常見問題排查。整個(gè)項(xiàng)目用Qt 5.15.2 QCustomPlot 2.1.1 MSVC 2019編譯器全部源碼在文末給出大家照著搭建環(huán)境就能跑起來。2. 整體架構(gòu)設(shè)計(jì)與方案選型2.1 模塊劃分為什么是四層結(jié)構(gòu)寫這種上位機(jī)控件最忌諱的就是把所有代碼堆到一個(gè)MainWindow里。我第一版就是那么干的結(jié)果加了三個(gè)功能之后信號槽亂成一團(tuán)改一個(gè)按鈕事件都要翻半天代碼。后來重構(gòu)成了四個(gè)獨(dú)立模塊各司其職代碼清晰度提升了一個(gè)量級。整個(gè)控件拆成四層數(shù)據(jù)通信層負(fù)責(zé)串口/網(wǎng)絡(luò)數(shù)據(jù)收發(fā)解析協(xié)議幀PID算法層純C實(shí)現(xiàn)的PID計(jì)算核心不依賴Qt方便移植到單片機(jī)上可視化層基于QCustomPlot的繪圖組件負(fù)責(zé)曲線繪制、坐標(biāo)軸管理、縮放交互界面交互層主窗口、參數(shù)控件布局、調(diào)參事件的注冊與分發(fā)這幾層之間的通信全部通過Qt的信號槽機(jī)制完成。數(shù)據(jù)通信層收到被控對象的反饋值通過feedbackReceived(double value)信號發(fā)出去PID算法層拿到之后計(jì)算出控制量可視化層訂閱反饋值和輸出值信號去繪圖界面層負(fù)責(zé)把用戶拖動(dòng)的參數(shù)實(shí)時(shí)寫入PID對象。各層之間耦合度很低我后面把這套算法核心移植到STM32工程里幾乎沒改邏輯只把Qt類型換成了標(biāo)準(zhǔn)C類型。數(shù)據(jù)流設(shè)計(jì)這塊我多說一句。串口收上來的數(shù)據(jù)是QByteArray經(jīng)過協(xié)議解析后變成double類型的反饋值這個(gè)值同時(shí)要做兩件事一是喂給PID算法做閉環(huán)計(jì)算二是推給繪圖區(qū)畫實(shí)際值曲線。PID計(jì)算出來的輸出量也要畫出來方便觀察控制量有沒有飽和同時(shí)通過串口下發(fā)到執(zhí)行器。整個(gè)過程用一個(gè)QTimer驅(qū)動(dòng)默認(rèn)定時(shí)周期10毫秒也就是100Hz的采樣率對大多數(shù)電機(jī)和溫度控制場景夠用了。2.2 可視化方案選型QCustomPlot到底值不值得用繪圖方案我對比過三個(gè)Qt Charts自帶的QChart、QCustomPlot、以及直接從零用QPainter畫。QChart是官方模塊集成方便但它的曲線性能在實(shí)時(shí)高頻刷新下掉幀比較嚴(yán)重尤其是同時(shí)開多條曲線和抗鋸齒的時(shí)候。QPainter手繪靈活性最高但坐標(biāo)軸縮放、圖例、網(wǎng)格這些全要自己實(shí)現(xiàn)工作量不小。QCustomPlot算是中間態(tài)底層用QPainter繪制但封裝好了坐標(biāo)軸管理、圖層管理、縮放拖拽這些功能性能和靈活性都夠用。實(shí)際用下來QCustomPlot性能表現(xiàn)不錯(cuò)。我測試過60FPS刷新率、3條曲線、每幀追加1000個(gè)數(shù)據(jù)點(diǎn)在i5處理器上CPU占用率大約15%到20%完全可接受。關(guān)鍵是它的setData接口設(shè)計(jì)得好追加數(shù)據(jù)時(shí)不會觸發(fā)全量重繪replot()只重繪變化區(qū)域這對實(shí)時(shí)波形顯示至關(guān)重要。我選擇QCustomPlot 2.1.1版本還有一個(gè)原因它支持在replot()時(shí)傳入QCPLayout::lpQueuedRefresh參數(shù)可以合并短時(shí)間內(nèi)的多次重繪請求到一次刷新避免界面卡頓。這個(gè)特性在參數(shù)實(shí)時(shí)調(diào)參時(shí)會非常有用——拖動(dòng)滑桿會產(chǎn)生大量信號如果每次都觸發(fā)重繪界面會肉眼可見地掉幀但開啟QueuedRefresh之后重繪會被合并到下一幀統(tǒng)一執(zhí)行流暢度改善很明顯。2.3 通信協(xié)議設(shè)計(jì)怎么讓數(shù)據(jù)穩(wěn)定不丟幀通信協(xié)議是這類上位機(jī)的命門。一開始我圖省事直接發(fā)ASCII字符串比如P:10.5 T:25.3\n解析起來確實(shí)簡單但問題在于IEEE 754浮點(diǎn)數(shù)轉(zhuǎn)字符串會損失精度而且字符串解析在高速數(shù)據(jù)流下CPU開銷不小極端情況下還會因?yàn)榫彌_區(qū)分幀導(dǎo)致解析錯(cuò)亂。后來改成二進(jìn)制協(xié)議幀格式固定為幀頭2字節(jié)0xAA 0x55數(shù)據(jù)ID1字節(jié)標(biāo)識數(shù)據(jù)類型比如0x01表示PID參數(shù)下發(fā)0x02表示反饋值上傳0x03表示控制量回讀數(shù)據(jù)長度1字節(jié)有效負(fù)載字節(jié)數(shù)最大255有效負(fù)載N字節(jié)具體的業(yè)務(wù)數(shù)據(jù)校驗(yàn)和1字節(jié)從幀頭到有效負(fù)載末尾所有字節(jié)累加和取低8位接收端通過狀態(tài)機(jī)逐字節(jié)解析只有幀頭匹配才進(jìn)入數(shù)據(jù)接收狀態(tài)最后校驗(yàn)和正確才認(rèn)為一幀有效。這套協(xié)議我從串口到TCP都復(fù)用移植成本幾乎為零。實(shí)際測試時(shí)115200波特率、1kHz上報(bào)頻率一晚上跑下來零丟幀穩(wěn)定性沒得說。寫協(xié)議類的時(shí)候記得加一個(gè)超時(shí)重置機(jī)制如果狀態(tài)機(jī)停留在接收狀態(tài)超過50毫秒沒收滿一幀強(qiáng)制復(fù)位回幀頭搜索狀態(tài)否則一幀丟半截后面的數(shù)據(jù)全都對不齊。3. PID算法核心實(shí)現(xiàn)與參數(shù)調(diào)整原理3.1 位置式PID和增量式PID該怎么選PID算法的C實(shí)現(xiàn)是這套控件的靈魂。我在控件里同時(shí)實(shí)現(xiàn)了位置式和增量式兩種模式因?yàn)椴煌膱?zhí)行機(jī)構(gòu)對輸出形式的要求完全不同。位置式PID的輸出直接對應(yīng)執(zhí)行器的絕對位置比如舵機(jī)的角度、加熱棒的PWM占空比它需要不斷累加歷史誤差所以存在積分飽和的風(fēng)險(xiǎn)。增量式PID的輸出是控制量的增量對應(yīng)執(zhí)行器例如步進(jìn)電機(jī)的脈沖增量它天然不含積分累加項(xiàng)不會有積分飽和問題但執(zhí)行器必須自帶積分能力比如步進(jìn)電機(jī)的當(dāng)前位置就是脈沖數(shù)的累加。實(shí)際項(xiàng)目里兩者我用過的經(jīng)驗(yàn)是溫度控制、液位控制這類輸出連續(xù)的場合位置式用得多機(jī)器人運(yùn)動(dòng)控制、云臺姿態(tài)控制這一類輸出最終接到電機(jī)驅(qū)動(dòng)器的場合增量式反而更方便。控件里用一個(gè)枚舉變量控制模式切換算法核心是同一個(gè)類只是根據(jù)模式?jīng)Q定返回絕對值還是增量值。位置式PID的離散化公式長這樣u(k) Kp * error(k) Ki * sum(error) Kd * (error(k) - error(k-1))增量式PID的輸出是Δu(k)它的核心思想是取相鄰兩個(gè)時(shí)刻位置式輸出的差值化簡之后得到一個(gè)只跟最近三次誤差有關(guān)的公式Δu(k) Kp * [error(k) - error(k-1)] Ki * error(k) Kd * [error(k) - 2*error(k-1) error(k-2)]這個(gè)公式推導(dǎo)的關(guān)鍵在于把sum(error)項(xiàng)消掉了所以增量式PID不需要記憶歷史誤差累加值內(nèi)存占用固定也不存在積分飽和。代碼里每周期只需要保存error、error_prev、error_prev2三個(gè)變量非常適合裸機(jī)環(huán)境跑。3.2 PID核心類的C實(shí)現(xiàn)細(xì)節(jié)PID核心類的頭文件我貼出來大家可以直接抄// pid_controller.h #pragma once #include mutex namespace pid_ns { enum class PIDMode { Positional, // 位置式 Incremental // 增量式 }; class PIDController { public: PIDController(); void setMode(PIDMode mode); void setParameters(double kp, double ki, double kd); void setTarget(double target); void setOutputLimit(double min, double max); void setIntegralLimit(double limit); void reset(); double feedback(double measureValue); private: double calculatePositional(double error); double calculateIncremental(double error); PIDMode mode_; double kp_, ki_, kd_; double target_; double integral_; double integralLimit_; double outputMin_, outputMax_; double lastError_; double lastOutput_; double lastOutputPrev_; // 增量式需要上一時(shí)刻輸出 double errorPrev_; // 增量式需要 double errorPrev2_; // 增量式需要 std::mutex paramMutex_; // 多線程保護(hù) }; }這里有個(gè)關(guān)鍵點(diǎn)參數(shù)和反饋值可能來自不同線程串口接收線程在調(diào)feedback()界面線程在調(diào)setParameters()不加鎖的話調(diào)參那一瞬間可能讀到撕裂的數(shù)據(jù)。我用了std::mutex鎖參數(shù)區(qū)代價(jià)是每次feedback()多一點(diǎn)鎖開銷但10kHz以內(nèi)完全沒感覺。feedback()函數(shù)內(nèi)部邏輯double PIDController::feedback(double feedbackValue) { double output 0.0; { std::lock_guardstd::mutex lock(paramMutex_); double error target_ - feedbackValue; if (mode_ PIDMode::Positional) { output calculatePositional(error); } else { output lastOutput_ calculateIncremental(error); } // 輸出限幅 if (output outputMax_) output outputMax_; if (output outputMin_) output outputMin_; lastOutput_ output; } return output; }注意增量式輸出最終也要做限幅雖然算法本身不會積分飽和但輸出量本身可能超出物理執(zhí)行機(jī)構(gòu)的能力范圍限幅之后才是真正寫給執(zhí)行器的值。3.3 抗積分飽和、微分濾波這些容易被忽略的細(xì)節(jié)很多人寫的PID能跑但跑得不穩(wěn)問題往往出在積分和微分這兩個(gè)環(huán)節(jié)的細(xì)節(jié)上。我這里做了三個(gè)優(yōu)化屬于實(shí)際工程里必須處理的坑。第一個(gè)是積分限幅。位置式PID的積分項(xiàng)會無限累加誤差一旦執(zhí)行器到極限了誤差還在持續(xù)累積等誤差反向時(shí)積分項(xiàng)還需要很長時(shí)間才能“吐”回來這就是積分飽和。解決方法是給積分器加一個(gè)上限我用setIntegralLimit(double limit)接口默認(rèn)限幅為輸出限幅的一半。實(shí)際參數(shù)整定時(shí)這個(gè)值設(shè)得不好系統(tǒng)會有明顯的超調(diào)和振蕩。第二個(gè)是微分項(xiàng)的噪聲放大器問題。純微分環(huán)節(jié)對高頻噪聲極其敏感反饋值稍微抖一點(diǎn)微分項(xiàng)就會輸出巨大的波動(dòng)嚴(yán)重時(shí)整個(gè)系統(tǒng)都在抖。標(biāo)準(zhǔn)的做法是給微分項(xiàng)加一階低通濾波。我在代碼里是這么處理的// 微分項(xiàng)帶一階低通濾波截止頻率約等于采樣頻率/2π double derivative (error - lastError_) / dt_; derivativeFiltered_ derivativeFiltered_ dt_ / (dt_ filterTimeConstant_) * (derivative - derivativeFiltered_);filterTimeConstant_一般取采樣周期的五到十倍既能濾掉高頻抖動(dòng)又不會讓微分作用太遲鈍。第三個(gè)是梯形積分。標(biāo)準(zhǔn)的位置式PID中積分項(xiàng)累加的是當(dāng)前誤差本身但如果誤差在一段時(shí)間內(nèi)近似線性變化用梯形面積代替矩形面積會更準(zhǔn)確。代碼里我改成integral_ (error lastError_) * dt_ / 2.0積分精度提升不小特別是系統(tǒng)進(jìn)入穩(wěn)態(tài)附近時(shí)梯形積分能有效減少靜差。3.4 雙環(huán)PID怎么在控件里表達(dá)熱搜詞里有“PID雙環(huán)控制”這個(gè)控件雖然默認(rèn)只開了一個(gè)PID實(shí)例但架構(gòu)上做了支持多實(shí)例的設(shè)計(jì)。每個(gè)PID實(shí)例用name_標(biāo)識串口協(xié)議頭部的數(shù)據(jù)ID區(qū)分不同環(huán)。典型的例子是無人機(jī)懸停內(nèi)環(huán)是角速度環(huán)外環(huán)是角度環(huán)外環(huán)的輸出作為內(nèi)環(huán)的設(shè)定值。我實(shí)測過一種接法外環(huán)角度PID的輸出直接連到內(nèi)環(huán)角速度PID的setTarget()接口內(nèi)環(huán)反饋值來自陀螺儀。這種級聯(lián)結(jié)構(gòu)在控件里只需要?jiǎng)?chuàng)建兩個(gè)PIDController對象然后在數(shù)據(jù)回調(diào)函數(shù)里手動(dòng)串起來double angleFeedback parseAngle(byteArray); double angleOutput outerPid.feedback(angleFeedback); innerPid.setTarget(angleOutput); double angularVelocityFeedback parseGyro(byteArray); double innerOutput innerPid.feedback(angularVelocityFeedback); sendControl(innerOutput);畫曲線時(shí)可以給兩個(gè)PID分別配置顏色這樣一眼就能看出每個(gè)環(huán)的響應(yīng)情況。雙環(huán)的參數(shù)整定原則是先內(nèi)環(huán)后外環(huán)內(nèi)環(huán)整好了再閉上外環(huán)不然兩個(gè)環(huán)同時(shí)調(diào)出了問題根本分不清是哪個(gè)環(huán)引起的。4. 可視化模塊實(shí)現(xiàn)從數(shù)據(jù)到波形4.1 QCustomPlot初始化與圖層配置可視化層是整個(gè)控件最直觀的部分也是體驗(yàn)最好的部分。QCustomPlot的初始化有幾個(gè)關(guān)鍵配置直接決定了后續(xù)的繪制性能和交互手感。首先創(chuàng)建三個(gè)繪圖通道設(shè)定值曲線綠色、實(shí)際值曲線藍(lán)色、輸出值曲線紅色。每條曲線對應(yīng)一個(gè)QCPGraph對象通過addGraph()添加。坐標(biāo)軸的策略是X軸時(shí)間軸固定向上滾動(dòng)Y軸根據(jù)數(shù)據(jù)范圍自動(dòng)縮放。初始化代碼關(guān)鍵部分// 創(chuàng)建繪圖控件 customPlot_ new QCustomPlot(this); customPlot_-setBackground(QColor(30, 30, 30)); // 深色背景長時(shí)間盯著不累眼 // 配置X軸時(shí)間軸 customPlot_-xAxis-setLabel(時(shí)間 (s)); customPlot_-xAxis-setRange(0, 10); // 默認(rèn)顯示10秒窗口 customPlot_-xAxis-setAutoTickStep(true); // 配置Y軸 customPlot_-yAxis-setLabel(數(shù)值); customPlot_-yAxis-setAutoTickStep(true); // 添加三條曲線 customPlot_-addGraph(); customPlot_-graph(0)-setPen(QPen(QColor(0, 255, 0), 2)); // 設(shè)定值綠色 customPlot_-addGraph(); customPlot_-graph(1)-setPen(QPen(QColor(0, 160, 255), 2)); // 實(shí)際值藍(lán)色 customPlot_-addGraph(); customPlot_-graph(2)-setPen(QPen(QColor(255, 80, 80), 2)); // 輸出值紅色 // 開啟圖例 customPlot_-legend-setVisible(true); customPlot_-axisRect()-insetLayout()-setInsetAlignment(0, Qt::AlignTop | Qt::AlignRight);這里有一個(gè)容易踩的坑QCustomPlot默認(rèn)開啟鼠標(biāo)滾輪縮放和左鍵拖拽但PID實(shí)時(shí)波形場景下我們希望X軸始終跟隨最新數(shù)據(jù)Y軸自動(dòng)適配滾動(dòng)窗口不需要用戶手動(dòng)平移。所以我在初始化之后顯式關(guān)閉了X軸的交互只保留Y軸縮放customPlot_-xAxis-setSelectable(QCPAxisSelection::spNone); customPlot_-xAxis-setScaleRatio(customPlot_-yAxis, 1.0); // 鎖定XY縮放比例 customPlot_-xAxis-setRangeZoomEnabled(false);這樣用戶拖拽縮放時(shí)只影響數(shù)據(jù)的顯示幅度不會破壞時(shí)間軸滾動(dòng)邏輯。4.2 實(shí)時(shí)數(shù)據(jù)滾動(dòng)窗口的實(shí)現(xiàn)方案實(shí)時(shí)波形最核心的機(jī)制是“滾動(dòng)窗口”——新數(shù)據(jù)不斷到達(dá)老數(shù)據(jù)逐漸從視野里消失。實(shí)現(xiàn)方式有兩種定長環(huán)形緩沖和不定長追加。定長環(huán)形緩沖適合長期運(yùn)行的場景內(nèi)存占用固定但實(shí)現(xiàn)復(fù)雜不定長追加簡單直接但跑幾個(gè)小時(shí)內(nèi)存會膨脹。我在這套控件里用的是環(huán)形緩沖思路預(yù)分配一個(gè)大小為N的點(diǎn)數(shù)組用環(huán)形索引記錄寫入位置。實(shí)際繪圖時(shí)從當(dāng)前索引開始按順序取出最多N個(gè)點(diǎn)送給QCustomPlot。QCustomPlot內(nèi)部有自己的數(shù)據(jù)結(jié)構(gòu)這個(gè)環(huán)形緩沖只是作為數(shù)據(jù)源防止歷史點(diǎn)無限累積。實(shí)際操作中我把重點(diǎn)放在setData的性能優(yōu)化上。QCustomPlot的setData接收兩個(gè)QVector 參數(shù)如果每次刷新都重新創(chuàng)建QVector并逐個(gè)push_back在1kHz采樣率下會有不小的開銷。正確的做法是復(fù)用兩個(gè)QVector改用指針填充// 預(yù)分配容量避免反復(fù)擴(kuò)容 QVectordouble xData(dataSize_); QVectordouble yData(dataSize_); while (running_) { // ... 從環(huán)形緩沖拷貝最新dataSize_個(gè)點(diǎn) for (int i 0; i dataSize_; i) { int idx (ringStart_ i) % ringSize_; xData[i] ringTime_[idx]; yData[i] ringValue_[idx]; } customPlot_-graph(1)-setData(xData, yData); customPlot_-replot(); }由于QVector的operator[]是直接修改內(nèi)存對應(yīng)位置不觸發(fā)擴(kuò)容所以高頻調(diào)用下消耗很穩(wěn)定。我在6000點(diǎn)窗口、60Hz刷新下單幀setData的耗時(shí)大約在微秒級主要開銷還是在replot()的光柵化階段。還有一個(gè)小技巧連續(xù)追加數(shù)據(jù)的時(shí)候用graph-data()-add()會比setData()更高效。add()方法允許傳入多個(gè)點(diǎn)內(nèi)部一次性完成內(nèi)存分配和插入避免了每次QVector拷貝的損耗。我把兩種方式封在了一個(gè)方法里根據(jù)數(shù)據(jù)量自動(dòng)選擇void plotAppend(int graphIndex, double x, double y) { if (replotting_) return; // 防止重入 QCPGraphDataContainer* dataContainer customPlot_-graph(graphIndex)-data(); dataContainer-add(QCPGraphData(x, y)); }4.3 時(shí)域曲線到底要不要做頻域分析熱搜詞里有“qt時(shí)域圖轉(zhuǎn)換為頻域圖”和“qt qcustomplot kissfft時(shí)域到頻域波形”我在這個(gè)控件的第三版里增加了一個(gè)輔助窗口用KissFFT庫把時(shí)域波形實(shí)時(shí)轉(zhuǎn)換到頻域?qū)ｉT用來觀察系統(tǒng)的振蕩頻率和諧波成分。為什么要做頻域PID調(diào)試時(shí)時(shí)域波形能看到超調(diào)、靜差、響應(yīng)時(shí)間這些指標(biāo)但系統(tǒng)的振蕩頻率、是否存在高頻諧振點(diǎn)光靠時(shí)域波形不容易判斷。舉個(gè)實(shí)際案例我用一個(gè)電機(jī)平臺測試時(shí)時(shí)域波形看起來是平穩(wěn)的但電機(jī)聲音里一直有滋滋聲切到頻域一看500Hz附近有個(gè)明顯的峰值——那是機(jī)械傳動(dòng)部分的諧振頻率PID參數(shù)在這個(gè)頻段產(chǎn)生了激勵(lì)放大。如果只看時(shí)域這個(gè)隱患很難發(fā)現(xiàn)。KissFFT是業(yè)界常用的輕量級FFT庫純C實(shí)現(xiàn)不需要額外安裝直接把它拖進(jìn)工程里編譯就行。核心調(diào)用片段#include kiss_fft.h // 幀大小為1024窗函數(shù)用漢寧窗 kiss_fft_cfg cfg kiss_fft_alloc(1024, 0, nullptr, nullptr); std::vectorkiss_fft_cpx fin(1024), fout(1024); for (int i 0; i 1024; i) { fin[i].r timeSignal_[i] * hanningWindow_[i]; fin[i].i 0.0; } kiss_fft(cfg, fin.data(), fout.data()); // 計(jì)算幅度譜 for (int i 0; i 512; i) { double mag 2.0 * std::sqrt(fout[i].r * fout[i].r fout[i].i * fout[i].i) / 1024.0; freqs_[i] mag; }頻域曲線繪制在第二個(gè)QCustomPlot實(shí)例里X軸是頻率HzY軸是幅度dB或線性。用漢寧窗是因?yàn)樗苡行б种祁l譜泄漏不加窗的話邊界不連續(xù)會在頻譜上拖出長長的旁瓣干擾真實(shí)頻率成分的判斷。FFT幀重疊率我默認(rèn)取50%這樣頻域刷新率能達(dá)到時(shí)域的一半觀察動(dòng)態(tài)頻譜變化已經(jīng)夠了。5. 實(shí)時(shí)調(diào)參交互與刷新機(jī)制5.1 參數(shù)控件組的設(shè)計(jì)滑桿和輸入框怎么聯(lián)動(dòng)實(shí)時(shí)調(diào)參的核心訴求是“改參數(shù)立竿見影”所以交互控件的設(shè)計(jì)直接影響調(diào)試體驗(yàn)。我為Kp、Ki、Kd、目標(biāo)值分別做了一組關(guān)聯(lián)控件每組由一個(gè)QSlider、一個(gè)QSpinBox或QDoubleSpinBox和一個(gè)QLabel組成。QSlider用于快速粗調(diào)QDoubleSpinBox用于精確值輸入兩者通過信號槽同步。這個(gè)聯(lián)動(dòng)邏輯有點(diǎn)繞有一點(diǎn)需要特別注意滑桿和數(shù)值框互相更新值時(shí)會形成循環(huán)信號不加控制會死循環(huán)。我的解決方案是加一個(gè)bool syncing_標(biāo)志void ParamsWidget::onSliderChanged(int value) { if (syncing_) return; syncing_ true; double mapped mapSliderToRange(value); // 滑桿值映射到實(shí)際參數(shù)范圍 spinBox_-setValue(mapped); emit paramChanged(name_, mapped); syncing_ false; } void ParamsWidget::onSpinBoxChanged(double value) { if (syncing_) return; syncing_ true; int sliderPos mapRangeToSlider(value); slider_-setValue(sliderPos); emit paramChanged(name_, value); syncing_ false; }syncing_標(biāo)志的作用是當(dāng)程序主動(dòng)去設(shè)置控件值時(shí)不再觸發(fā)反向更新只讓用戶直接操作的那一次進(jìn)入信號鏈傳給PID核心。這個(gè)是界面交互設(shè)計(jì)中特別容易踩的坑我第一版沒加標(biāo)志滑桿動(dòng)一下界面卡死控制臺刷屏刷得停不下來。5.2 參數(shù)變更到PID對象的實(shí)時(shí)下發(fā)鏈路參數(shù)從界面控件傳到PID核心類的完整信號鏈路是QSlider的valueChanged信號或者QDoubleSpinBox的valueChanged信號發(fā)送到MainWindowMainWindow再調(diào)用pidController的setParameters()。由于PIDController內(nèi)部有互斥鎖保護(hù)這里不需要額外加QMetaObject::invokeMethod之類的跨線程處理。這里我加了一個(gè)EMAFilter指數(shù)滑動(dòng)平均濾波主要是為了防止滑桿拖得太快導(dǎo)致參數(shù)跳變太猛烈。真實(shí)的物理對象比如溫度、電機(jī)對參數(shù)突變是有慣性的Kp突變了50%系統(tǒng)可能直接飛車。所以我把用戶拖動(dòng)的參數(shù)值先做EMA平滑再寫入PID對象代碼如下void MainWindow::onParamChanged(QString name, double value) { if (name Kp) { kpFilter_.update(value); pidController_-setParameters(kpFilter_.value(), ki_, kd_); } // ... }在動(dòng)手“實(shí)時(shí)調(diào)參”之前務(wù)必要確認(rèn)處理邏輯里已經(jīng)有參數(shù)平滑或至少是遞減式限幅否則一些敏感被控對象很容易因?yàn)槭只鴵p壞執(zhí)行機(jī)構(gòu)。5.3 刷新頻率的選擇和拖拽降載策略刷新頻率是整個(gè)可視化系統(tǒng)最需要權(quán)衡的點(diǎn)。這里其實(shí)涉及兩種刷新頻率數(shù)據(jù)采樣頻率和界面刷新頻率我建議分開處理。數(shù)據(jù)采樣頻率由被控對象決定串口、采集卡或者模擬器控制一般是100Hz到1kHz。界面刷新頻率是人眼決定的60FPS左右已經(jīng)非常流暢再高沒有意義反而白白消耗CPU。所以我的做法是數(shù)據(jù)線程按自己的節(jié)奏采樣、計(jì)算PID界面?zhèn)绕鹨粋€(gè)QTimer固定30毫秒約33FPS觸發(fā)一次replot()。這個(gè)方案的好處是數(shù)據(jù)再多界面刷新率恒定不會因?yàn)閿?shù)據(jù)量大導(dǎo)致UI線程卡死。拖動(dòng)滑桿的時(shí)候還有一個(gè)小優(yōu)化。滑桿的valueChanged信號頻率非常高人拖動(dòng)一秒鐘可能觸發(fā)幾十次甚至上百次信號。如果每次信號都做PID參數(shù)寫入、重繪請求、界面刷新那CPU瞬間就爆炸了。我實(shí)現(xiàn)了一個(gè)重繪請求合并機(jī)制用QMetaObject::invokeMethod配合Qt::QueuedConnection把重繪操作丟給事件循環(huán)去排隊(duì)并且用一個(gè)bool pendingReplot_標(biāo)志保證同一時(shí)間只有一次重繪請求在隊(duì)列里。void MainWindow::requestReplot() { if (pendingReplot_) return; pendingReplot_ true; QMetaObject::invokeMethod(this, [this]() { customPlot_-replot(); pendingReplot_ false; }, Qt::QueuedConnection); }實(shí)測下來拖滑桿再快重繪也不會重復(fù)執(zhí)行界面始終保持在穩(wěn)定頻率。同樣串口數(shù)據(jù)接收線程也不會因?yàn)樾盘栵L(fēng)暴阻塞UI線程。5.4 數(shù)據(jù)導(dǎo)出和回放沒有回放功能的調(diào)參都是偽實(shí)時(shí)調(diào)試PID參數(shù)時(shí)有個(gè)很現(xiàn)實(shí)的需求某個(gè)參數(shù)組合導(dǎo)致波形異常但現(xiàn)象一閃而過想回去分析又做不到。我增加了“錄制/回放”功能把所有操作數(shù)據(jù)緩存到內(nèi)存支持暫停導(dǎo)出為CSV。導(dǎo)出格式非常簡單時(shí)間戳、設(shè)定值、實(shí)際值、PID輸出、當(dāng)前參數(shù)Kp/Ki/Kd五列數(shù)據(jù)Excel可以直接打開。回放模塊其實(shí)就是把導(dǎo)出的CSV重新讀進(jìn)來按時(shí)間軸推送給繪圖區(qū)交互上可以拖動(dòng)進(jìn)度條看任意時(shí)刻的曲線狀態(tài)。這個(gè)功能對分析系統(tǒng)從啟動(dòng)到穩(wěn)態(tài)的全過程幫助很大尤其是觀察啟動(dòng)超調(diào)量和穩(wěn)態(tài)靜差的變化趨勢。6. 實(shí)操環(huán)境搭建與源碼結(jié)構(gòu)導(dǎo)讀6.1 Qt開發(fā)環(huán)境配置指北如果你是從零開始搞這個(gè)項(xiàng)目環(huán)境是最容易卡住的地方也是最容易被各種帖子誤導(dǎo)的地方。熱搜詞里關(guān)于Qt安裝的困惑特別多我在這里把一套經(jīng)過驗(yàn)證的流程寫清楚。我用的組合是Qt 5.15.2 Qt Creator 4.14 MSVC 2019 CMake。Qt 5.15.2屬于LTS版本穩(wěn)定、資料多QCustomPlot配合它沒有任何兼容問題。不要急著上Qt 6雖然Qt 6性能更好但很多第三方庫的適配還不完美特別是QCustomPlot在Qt 6里需要重新編譯而且部分API有變動(dòng)新手容易踩坑。下載安裝時(shí)注意勾選MSVC 2019 64-bit組件以及Qt Charts和Qt SerialPort模塊。串口通信模塊雖然我最后做的是網(wǎng)絡(luò)版但調(diào)試階段用串口更方便模塊提前裝好沒壞處。編譯QCustomPlot時(shí)最簡單的做法是直接下載它的qcustomplot.cpp和qcustomplot.h兩個(gè)源文件丟進(jìn)你的工程一起編譯。如果你想用它的動(dòng)態(tài)庫版本需要在項(xiàng)目文件里鏈接qcustomplot的lib文件并配置包含目錄個(gè)人不建議直接源碼編譯最省心。配環(huán)境時(shí)還有一個(gè)高頻踩坑點(diǎn)Qt的MSVC套件需要對應(yīng)的Visual C Redistributable環(huán)境。如果你啟動(dòng)程序時(shí)遇到“The application was unable to start correctly”這類的報(bào)錯(cuò)大概率是缺少運(yùn)行庫。解決辦法是安裝對應(yīng)年份的Visual C Redistributable包這個(gè)屬于通用運(yùn)行庫安裝完基本能解決。6.2 項(xiàng)目文件夾結(jié)構(gòu)說明這個(gè)項(xiàng)目的源碼結(jié)構(gòu)大致長這樣pid_visualizer/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ ├── mainwindow.h / .cpp │ ├── pid_controller.h / .cpp │ ├── data_link.h / .cpp │ ├── plot_widget.h / .cpp │ ├── params_widget.h / .cpp │ └── fft_widget.h / .cpp ├── third_party/ │ ├── qcustomplot/ │ │ ├── qcustomplot.h │ │ └── qcustomplot.cpp │ └── kissfft/ │ ├── kiss_fft.h │ ├── kiss_fft.c │ └── tools/ └── resources/ ├── style.qss └── icons/這個(gè)結(jié)構(gòu)里我把算法、通信、繪圖、界面四部分拆得足夠開每個(gè)文件夾的職責(zé)非常清晰。不管你是改成自己項(xiàng)目還是參考學(xué)習(xí)都建議保持這種分層思想。6.3 CMake構(gòu)建腳本核心配置順帶說一下CMake配置現(xiàn)在Qt官方也在推CMake跨平臺特性比qmake好不少。核心內(nèi)容如下cmake_minimum_required(VERSION 3.16) project(pid_visualizer LANGUAGES CXX C) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) set(CMAKE_AUTOUIC ON) find_package(Qt5 REQUIRED COMPONENTS Widgets Charts SerialPort Network ) add_executable(pid_visualizer src/main.cpp src/mainwindow.cpp src/pid_controller.cpp src/data_link.cpp src/plot_widget.cpp src/params_widget.cpp src/fft_widget.cpp third_party/qcustomplot/qcustomplot.cpp third_party/kissfft/kiss_fft.c ) target_include_directories(pid_visualizer PRIVATE src/ third_party/qcustomplot/ third_party/kissfft/ ) target_link_libraries(pid_visualizer PRIVATE Qt5::Widgets Qt5::Charts Qt5::SerialPort Qt5::Network )這里面有個(gè)關(guān)鍵點(diǎn)kiss_fft.c是純C文件所以project()里必須啟用C語言支持否則CMake會報(bào)語言錯(cuò)誤。還有C標(biāo)準(zhǔn)要用17或以上QCustomPlot在C17編譯下沒有任何問題但如果你用老編譯器開的C11模式某些模板代碼可能需要調(diào)整。6.4 源碼閱讀順序建議如果你拿到源碼想趕緊看懂我建議按這個(gè)順序讀先看pid_controller.cpp了解PID算法的完整實(shí)現(xiàn)再看data_link.cpp搞懂?dāng)?shù)據(jù)從串口進(jìn)入系統(tǒng)之后的流轉(zhuǎn)路徑然后看plot_widget.cpp學(xué)習(xí)曲線繪制的核心邏輯最后翻mainwindow.cpp把所有模塊串起來理解整體架構(gòu)。不要一開始就盯mainwindow.cpp它涉及的信號槽太多信息量太大容易一頭霧水。按依賴關(guān)系從底層往上層看邏輯上更順體驗(yàn)也好得多。我自己的閱讀習(xí)慣是組件優(yōu)先、組合其次、入口最后這樣能快速建立每個(gè)類的心智模型。7. 常見問題與排查技巧實(shí)錄7.1 Qt安裝和運(yùn)行環(huán)境高頻報(bào)錯(cuò)很多跑Qt的項(xiàng)目都會碰上“windows no qt platform plugin could be initialized”這個(gè)報(bào)錯(cuò)。第一次看到這個(gè)提示大多數(shù)人會以為程序崩了其實(shí)問題在于Qt找不到platform插件通常有三個(gè)原因運(yùn)行目錄下沒有platforms文件夾或者里面缺qwindows.dllWindows下環(huán)境變量不對Qt的bin目錄沒有加入PATH程序從IDE外部啟動(dòng)時(shí)嵌入的資源編譯器找不到路徑我在這個(gè)項(xiàng)目里規(guī)避這個(gè)問題的方法是在main函數(shù)開頭顯式設(shè)置Qt插件搜索路徑并同時(shí)設(shè)置當(dāng)前工作目錄#include QApplication #include QDir int main(int argc, char *argv[]) { QApplication app(argc, argv); // 確保Qt插件路徑正確指向編譯輸出目錄 QString appDir QCoreApplication::applicationDirPath(); QCoreApplication::addLibraryPath(appDir /platforms); QDir::setCurrent(appDir); MainWindow w; w.show(); return app.exec(); }還有一種情況開發(fā)機(jī)上跑沒問題換一臺電腦就報(bào)錯(cuò)通常是目標(biāo)機(jī)上缺少M(fèi)SVC運(yùn)行庫。這個(gè)在前面提過裝一次這個(gè)問題就能根除。還有一個(gè)Linux用戶會碰到的報(bào)錯(cuò)qxcbconnection: failed to initialize xrandr。這個(gè)多半是缺libxcb相關(guān)庫Ubuntu下安裝libxcb-xinerama0、libxcb-randr0等包可以解決但不要試圖禁用xcb去繞平臺插件缺失導(dǎo)致功能不完整的坑反而更大。7.2 曲線繪制卡頓和數(shù)據(jù)丟幀怎么查實(shí)時(shí)曲線卡頓這是可視化控件最容易遇到的問題。出現(xiàn)卡頓我建議按下面的順序逐步排查第一步確認(rèn)數(shù)據(jù)接收線程本身沒有阻塞。在data_link的接收回調(diào)里加上時(shí)間戳打印看相鄰兩次回調(diào)的時(shí)間間隔是否穩(wěn)定。如果間隔本身在跳變說明瓶頸在底層通信不在繪圖。第二步檢查QCustomPlot的數(shù)據(jù)量是否過大。如果窗口中積累了上百萬個(gè)點(diǎn)replot()的光柵化時(shí)間會直線上升。矩形窗口的X軸范圍固定的情況下要限制存儲的點(diǎn)數(shù)。我的做法是窗口內(nèi)最多保存10000個(gè)點(diǎn)超出部分直接從起始位置丟棄。第三步看一下是否不小心在數(shù)據(jù)線程里調(diào)用了重繪函數(shù)。QCustomPlot不是線程安全的所有繪圖操作必須在UI線程執(zhí)行。如果數(shù)據(jù)線程直接調(diào)用replot()輕則卡頓重則隨機(jī)崩潰。正確的做法是發(fā)送信號到UI線程或者用QMetaObject::invokeMethod。丟幀問題則要從緩沖區(qū)排查。串口數(shù)據(jù)到達(dá)速度快于UI線程處理速度時(shí)如果串口緩沖區(qū)滿了新幀就會把舊幀頂?shù)?。解決思路是增大接收緩沖區(qū)的容量同時(shí)讓數(shù)據(jù)線程不等待UI線程直接塞入環(huán)形隊(duì)列// 串口緩沖區(qū)設(shè)置 serialPort_-setReadBufferSize(65536); // 數(shù)據(jù)接收回調(diào) void DataLink::onReadyRead() { QByteArray chunk serialPort_-readAll(); std::lock_guardstd::mutex lock(queueMutex_); dataQueue_.push(chunk); }UI線程用定時(shí)器定期從隊(duì)列里取數(shù)據(jù)解析這種生產(chǎn)-消費(fèi)模型在高頻數(shù)據(jù)流下最穩(wěn)定。7.3 調(diào)參時(shí)波形震蕩發(fā)散怎么定位原因這個(gè)屬于PID調(diào)試的經(jīng)典問題。波形發(fā)散有三種典型表現(xiàn)等幅振蕩、發(fā)散振蕩、緩慢爬升。這里我給大家整理了一個(gè)速查表現(xiàn)象可能原因解決方向高頻等幅振蕩Kp過大系統(tǒng)增益太高先降Kp再微調(diào)Kd增加阻尼低頻等幅振蕩Ki過大積分引入相位滯后降低Ki增加Kp補(bǔ)償發(fā)散振蕩Kp和Kd方向不對或者輸出飽和沒處理好檢查輸出限幅降低Kp響應(yīng)過慢靜差大Kp太小或Ki太小先加大Kp再逐步加Ki微分噪聲放大Kd過大或?yàn)V波時(shí)間常數(shù)太小增大微分濾波系數(shù)如果從時(shí)域上判斷不了振蕩頻率就用控件里的FFT輔助窗口看頻譜。頻譜峰值出現(xiàn)在低頻段優(yōu)先查積分項(xiàng)出現(xiàn)在高頻段優(yōu)先查比例項(xiàng)和微分噪聲。這一點(diǎn)在實(shí)際現(xiàn)場調(diào)試幫助很大。還有一個(gè)容易被忽略的點(diǎn)目標(biāo)值突變過大時(shí)PID輸出會瞬間沖到限幅值系統(tǒng)反而被推成震蕩。解決辦法是給目標(biāo)值增加斜坡限制讓設(shè)定值按固定速率爬升到最終目標(biāo)而不是直接階躍。我在控件里加了一個(gè)setpointRampRate_用目標(biāo)值斜坡限速函數(shù)解決啟動(dòng)瞬間的沖擊。7.4 數(shù)據(jù)通信的粘包半包場景用串口或TCP傳輸二進(jìn)制協(xié)議時(shí)粘包和半包是必然要處理的。半包就是一條完整幀的數(shù)據(jù)還沒收完接收端就嘗試解析粘包是接收端一次讀到了好幾條幀的數(shù)據(jù)不能簡單按一次讀取量當(dāng)成一條幀。我在狀態(tài)機(jī)解析層做了一塊獨(dú)立的緩沖區(qū)專治這兩種情況。每次收到數(shù)據(jù)先追加到接收緩沖區(qū)然后循環(huán)調(diào)用幀解析函數(shù)能解析出一幀就處理一幀直到緩沖區(qū)剩余數(shù)據(jù)不足一幀。幀解析函數(shù)返回成功、失敗或者需要更多數(shù)據(jù)三種狀態(tài)避免半包時(shí)提前消費(fèi)數(shù)據(jù)。ParseResult Parser::pushData(const QByteArray chunk) { buffer_.append(chunk); while (true) { int frameLen tryGetFrameLength(buffer_); if (frameLen 0) { // 幀頭不匹配丟棄一個(gè)字節(jié)繼續(xù)搜索 buffer_.remove(0, 1); if (buffer_.isEmpty()) return NeedMore; continue; } if (buffer_.size() frameLen) { return NeedMore; // 半包等數(shù)據(jù)齊 } QByteArray frame buffer_.left(frameLen); buffer_.remove(0, frameLen); if (verifyChecksum(frame)) { emit frameReady(frame); } else { // 校驗(yàn)失敗丟掉這一幀繼續(xù)找 continue; } } }這套解析器我實(shí)測了很長時(shí)間在9600bps到921600bps的串口速率下包括網(wǎng)絡(luò)TCP流都沒有出過解析錯(cuò)亂的情況。核心原則就一條解析狀態(tài)機(jī)不依賴接收包的邊界只依賴幀內(nèi)容本身的完整性。8. 源碼使用與二次開發(fā)擴(kuò)展8.1 怎么把控件集成到自己的項(xiàng)目源碼拿到手最簡單的用法是直接編譯運(yùn)行默認(rèn)demo界面里會有一個(gè)模擬被控對象在跑拖動(dòng)滑桿就能看到PID參數(shù)對響應(yīng)曲線的影響。這個(gè)模擬器是我特意實(shí)現(xiàn)的用來在沒有真實(shí)硬件的時(shí)候驗(yàn)證算法效果。真實(shí)項(xiàng)目集成的話你只需要替換數(shù)據(jù)通信層把DataLink類里的串口或網(wǎng)絡(luò)讀取換成你實(shí)際硬件的數(shù)據(jù)來源然后把解析出來的反饋值調(diào)feedback()接口把計(jì)算好的控制量下發(fā)到執(zhí)行機(jī)構(gòu)繪圖部分完全不用動(dòng)。模擬器里我用的是一階慣性環(huán)節(jié)加延遲的模型非常接近電機(jī)轉(zhuǎn)速和溫度控制的響應(yīng)特征// 模擬一階慣性系統(tǒng) double SimPlant::update(double control, double dt) { const double timeConstant 0.5; // 時(shí)間常數(shù)單位秒 const double pureDelay 0.05; // 純延遲模擬通信和響應(yīng)延遲 delayedControl_ delayBuffer_.size() 0 ? delayBuffer_.front() : control; // 一階慣性dy/dt (control - y) / T output_ (delayedControl_ - output_) * dt / timeConstant; return output_; }這個(gè)模型雖然簡單但演示PID整定完全夠用。如果你想測試更復(fù)雜的對象把它替換成二階系統(tǒng)或者你實(shí)物的傳遞函數(shù)模型就行控件整體架構(gòu)不需要改動(dòng)。8.2 擴(kuò)展方向多通道、腳本化整定、云端監(jiān)控控件的基礎(chǔ)功能已經(jīng)完整但擴(kuò)展空間仍然很大。我在第二版迭代時(shí)做了幾個(gè)實(shí)驗(yàn)性擴(kuò)展分享給大家參考。一個(gè)是多通道支持?，F(xiàn)在每個(gè)PID實(shí)例獨(dú)立顯示一組曲線但實(shí)際控制系統(tǒng)往往需要同時(shí)看多個(gè)通道的數(shù)據(jù)。把繪圖區(qū)改成網(wǎng)格布局可以同時(shí)顯示4個(gè)或9個(gè)波形窗口每個(gè)窗口綁定不同的數(shù)據(jù)通道。這個(gè)在電機(jī)多軸同步控制、多路溫控場景下特別實(shí)用。另一個(gè)是腳本化整定。用戶可以把一組PID參數(shù)保存為預(yù)設(shè)方案加載后一鍵應(yīng)用。對于需要頻繁切換工況的場景這比每次手動(dòng)拖動(dòng)滑桿高效得多。我在代碼里用QSettings存儲預(yù)設(shè)參數(shù)加載、保存、導(dǎo)入、導(dǎo)出都做好了接口二次開發(fā)直接調(diào)用即可。云端監(jiān)控方向可以把串口數(shù)據(jù)轉(zhuǎn)發(fā)到MQTT或者WebSocket結(jié)合瀏覽器端的圖表庫做遠(yuǎn)程調(diào)參。這個(gè)方案在野外設(shè)備調(diào)試時(shí)價(jià)值很大我做了基礎(chǔ)原型但因?yàn)樯婕熬W(wǎng)絡(luò)服務(wù)部署不在本篇文章展開后續(xù)可以單獨(dú)寫一篇。8.3 跑通源碼后的自我驗(yàn)收方法寫完代碼之后建議用以下方式驗(yàn)收自己的理解程度第一步用模擬器模式給系統(tǒng)設(shè)置一個(gè)階躍目標(biāo)值調(diào)出一組能快速穩(wěn)定無靜差的參數(shù)記錄你的整定過程和最終效果。第二步把Kp故意調(diào)得很大觀察系統(tǒng)出現(xiàn)等幅振蕩時(shí)FFT窗口頻率分布發(fā)生了什么變化是否和理論預(yù)期一致。第三步開啟電腦任務(wù)管理器觀察CPU占用狀況。我的控件在60Hz刷新、1kHz數(shù)據(jù)下CPU占用不超過30%。如果你測出來異常高說明刷新合并機(jī)制或數(shù)據(jù)過濾邏輯還有改進(jìn)空間。第四步嘗試把增量式PID的輸出接到模擬執(zhí)行器上驗(yàn)證限幅和抗積分飽和邏輯是否正常工作。這套驗(yàn)收流程能幫你確認(rèn)自己是真的理解了代碼而不是僅僅“跑起來”了事。9. 最后分享幾個(gè)實(shí)操中的小體會寫了這么多最后說幾句掏心窩的話。我在實(shí)際使用這套控件調(diào)電機(jī)轉(zhuǎn)速的過程中最深的一個(gè)體會是PID參數(shù)整定說到底是經(jīng)驗(yàn)的活但工具把“試錯(cuò)”成本降到足夠低之后“經(jīng)驗(yàn)積累”本身也會快很多。以前調(diào)個(gè)溫控系統(tǒng)一個(gè)參數(shù)預(yù)實(shí)驗(yàn)做完整個(gè)人都不想動(dòng)了現(xiàn)在拖幾個(gè)滑桿半小時(shí)內(nèi)就能摸透系統(tǒng)的脾氣。有一個(gè)小的使用習(xí)慣想分享給各位調(diào)參之前先固定采樣周期別一邊調(diào)參數(shù)一邊改采樣率。PID的三個(gè)參數(shù)是和采樣周期綁定的Kp乘以采樣周期之后系統(tǒng)的離散化行為才穩(wěn)定。很多人說“同樣的參數(shù)上板子就不對”一大半是因?yàn)椴蓸勇首兓恕Ａ硗饨缑嫔夏菐讉€(gè)參數(shù)滑桿的初始范圍不要拍腦袋設(shè)。先根據(jù)執(zhí)行機(jī)構(gòu)的能力估算輸出限幅再結(jié)合被控對象的經(jīng)驗(yàn)時(shí)間常數(shù)估計(jì)Kp的大致范圍把滑桿范圍設(shè)置到合理區(qū)間這個(gè)調(diào)參窗口用起來會順手很多不然參數(shù)稍微一偏曲線直接飛出屏幕。這套控件的完整源碼我已經(jīng)整理好了包含QCustomPlot和KissFFT的源碼直接打開.pro文件就能在Qt Creator里編譯運(yùn)行。有疑問的朋友歡迎在評論區(qū)交流我在實(shí)際調(diào)試中踩過的那些坑都會在這篇文章的評論區(qū)繼續(xù)補(bǔ)充。