玩嗨OpenHarmony：基于OpenHarmony的仿生四足狗開發分享

• 主控MCU：Hi3861模組

• 關節位控電機：9g舵機 ---> MG90S;

• 舵機驅動管理：PCA9685PW;

• IMU傳感器：MPU6050;

• 電機供電：DC-DC BUCK電路 ---> MP2236

• 移動電源：航模聚合物鋰電池 ---> 2S-35C

1. 機械結構部分采用SolidWorks 2020設計，通過FDM式3D打印制造。其主要設計內容包括軀體與單腿。單腿機構采用平面四連桿構成并聯腿，擁有3自由度，設計思路是盡量減輕腿部重量，并且使三個電機安裝的位置緊湊集中。軀體采用模塊分立結構設計，方便維護更換及升級；

2. 電控硬件部分采用立創EDA專業版設計。關于12路舵機驅動主要由PCA9685PW管理，Hi3861物聯網模組主控，供電部分采用了一個DC-DC BUCK型降路壓電路，支持最大電流6A，保證電機及控制電路供電充足；

3. 軟件部分采用Clion作為編輯器，linux環境下編譯。在實現主單腿正逆解、足端擺線軌跡規劃的基礎上，實現了四足機器狗的Trot小跑步態運動，姿態逆解控制等；

4. 機器人的遠程控制App基于Android開發，與四足機器狗之間采用了UDP協議實現無線通信。

為了能夠使機器人在三維空間中能夠自由運動，首先，確定了機器人整體設計有12個自由度。

腿部結構：

考慮到機器人后續的運動性能和續航，該機器人腿部結構的設計思路是，盡量減輕了腿部重量與保證單腿上三個電機的安裝位置緊湊。故大腿小腿的的結構采用了并聯腿結構。該并聯腿的機構原理屬于借鑒參考了其他開源項目，并不是完全創新。

軀體結構：

在設計機器人軀體是，依照的是模塊化思路，將整個軀體分解為由頂層板、底層板、左側板、右側板、前側板、后側板六部分拼接而成，然后再依次在各板塊上進行安裝接口與外形設計。

接口安排：

四條單腿的電機安裝接口分別在左側板與右側板上，而控制板的接口在頂層板上，移動電源設計放置在機器人腹內，四足機器人頂層板的前后側部分挖空方便理線，頂層板尾部設計有天線接口，底層板前側設計了一處舵機接口。接口的方式幾乎均為鏤空，另一好處可以節省材料。

結構制造：

由于本人制造手段目前限制于僅FDM式3D打印機，故結構設計過程中盡量避免的平行與底面的懸空結構，故該機器人的各零部件在打印時幾乎不需要支撐結構，即方便后處理步驟與節省材料。

主控MCU：

這個不用多說，已固定為Hi3861模組。其外圍電路數據手冊即教學視頻都有，非常簡單。僅需要注意模組天線部分背部不要布線或挖空。

串口通訊：

采用了CH340系列引腳最少的CH340N，配合Type-C接口。個人目前比較喜歡Type-C，雖然不太好焊，但對我來講沒什么問題。

舵機驅動：

由于舵機數量多達12個及以上，采用PCA9685PW屬常規操作了。目前也就發現一款LU9685，其沒找到沒太好的替代芯片。

供電電路：

以一顆舵機額定運行需要5V，200mA來算，加上MCU模組及其他芯片需500mA左右來算，正常運作將近需要2.9A.故LDO無法滿足，需DC-DC BUCK型降壓電路將2S鋰電池降壓到5V輸出。MP2236支持寬電壓輸入，最高電壓18V，最大電流6A。

整體思路：

四足機器人基本的運動控制幾乎都是在實現單腿正逆解的基礎上實現的。

單腿正逆解：

了解到有DH建模法、幾何法等方法可以實現，個人此次采用的是幾何法實現。（因為DH建模時因為arcsin出現了很多計算上的BUG)

姿態逆解：

姿態逆解即在單腿逆解基礎上，通過單腿把整個軀體當做并聯機構來控制，其實也就設計單腿和軀體的坐標系變換，理解相對運動即可。

步態規劃：

步態規劃要控制的一個是足端軌跡，一個是單個步態周期中各腿的運動。首先可理解的是各腿的運動軌跡，可均采用一種規劃，本項目中采用的是擺線來規劃。隨后主要控制的便是一個步態周期，各單腿的抬起落下，即擺動相與支撐相。本項目中僅演示了Trot步態，即對角小跑步態。對于足端軌跡是實時解算的，對角兩腿向前擺動時，另外對角兩腿同步向后支撐，即控制的機器狗的整體移動。包括后續的轉彎，左右平移皆是一個原理。

整體思路：

遇到問題：

檢測過程：

• 拆除WS2812B燈珠后，串口即能輸出正常信息；

• 拔下MPU6050模塊后，串口即能輸出正常信息。

疑似原因：

Hi3861模組燒錄時，特定引腳不能外接設備。

當我一開始發現輸出亂碼，慣性上會首先思考MCU的焊接是否良好、串口通訊的電路是否正常、芯片供電是否正常、EN按鍵是否正常等問題。后來能順利解決問題也是在檢查上面所有問題后歪打正著，意外拆掉那顆WS2812燈珠后才發現復位正常了。

解決方案：

• 拆去連接IO2引腳的WS2812B燈珠；

• 拔下連接IO7、IO8引腳的MPU6050模塊。

開發過程中卡殼，先檢查硬件問題，再檢查軟件問題：

硬件問題一般比軟件問題更麻煩一些，畢竟可能遇到需要重買材料，重新制板等時間成本較大的修補措施。

硬件問題檢查： 一般采用控制變量法把所有的嫌疑因素逐個排除。比如，先考慮各器件的焊接是否正常（可采用萬用表蜂鳴檔檢測）。如果有MCU的電路先檢查MCU及其外圍電路，是否能夠燒錄程序。因為之后可通過寫各種Demo小程序來快速測試其他硬件資源是否正常。

檢查MCU及其外圍電路是否正常，可以先觀察焊接上是否有虛焊，連錫等情況。如果均無問題可接著測供電電壓是否正常。同時需注意，用電端燒毀一般是電壓問題，供電端燒毀一般是電流過大。

軟件問題調試： 如果有報錯信息，就去閱讀報錯信息來調試代碼。如果語法錯誤就比較容易解決。如果遇到比如LED驅動不亮，先檢查封裝或LED焊反沒，檢查原理圖上LED是引腳電平拉高還是拉低點亮。如果遇到采用IIC通訊的OLED屏幕無法點亮，先寫簡單的程序測通，比如先使屏幕點亮，再試著點亮一個點，再點亮一條線，畫出一個方塊，寫下一個字符。各種功能齊全后在組合調試出自己想要的效果。

而且單片機開發調試時不應該光敲代碼，中間需要穿插燒錄到單片機看是否能夠實現效果。問題多的話盡量分階段解決，而不是匯總到最后一起解決，不然很可能會出現找不到哪里出錯的。

優質的問題獲得優質的回答：

提問者要多思考，如何闡述清楚自己的問題，考慮是否方便回答者能簡潔地回答自己的問題，比如對方只用回答是還是不是。

比如自己的代碼編譯報錯，如果問為什么自己的代碼跑不起來，為什么自己的LED燈不亮了，這無疑很難獲得自己想要的答案。因為開發的時候碰到的Bug會有千萬種，但是正確的跑通道路卻只有一條。如果代碼報錯，自己首先要去檢查所報錯的代碼段，細化大概在哪一行出現了問題，個人先去通過搜索、調試等手段嘗試能否解決。

雖然有時太具體的問題也不太好回答，比如有人問自己想用Hi3861模組開發一款能夠監測室內溫濕度并實現澆水的智能澆花器。這類問題涉及的內容就比較多，也不好獲得自己想要的回答。調整一下的話，比如可以在問題最后加上，哪款溫濕度傳感器比較推薦，澆水用哪款電機比較合適等之類細化一些的問題。

做項目，要一邊開發一邊學習：

想做一個項目，不像之前我們所接觸的教育那樣，先把一個領域全方面熟悉摸透后再去做。畢竟想摸清某個領域都是很不容易的。要明確知道自己的需求，自己想要實現什么，大概可以怎么樣去實現，然后再去學習。需要用什么去學什么，需要用多少就學多少，除非自己對某方面非常感興趣。這樣才有可能快速地去完成自己的需求和實現想法。

做項目也是多做才可以更熟練，入門的話可以先跟著資料齊全，文檔清晰的優秀開源作品復刻。做了幾個后，隨后就會慢慢摸索出自己如果想要實現新項目的開展思路。