XiaoHu.ai开发日志(自2018年2月6日至2019年4月11日)
一年多來,一直在項目目錄下的update_log.txt里記錄開發日志,今天放到網上來,共?6189個字。
————XiaoHu.ai Standard 代號STD————
2/6 v0.1 項目啟動,第一行負責錄音的代碼被寫了出來
2/8 v0.2 語音助手可以識別正則表達式指令,整合turing獲得聊天功能
2/9 v0.36 更換數據庫架構為xml,編寫了標記技術可以識別輸入語句里變量的存在
2/10 v0.4 添加日程管理:日程添加,日程查詢,日程刪除。編到晚上嗓子疼
2/11 v0.52 #修復日程的兩個bug 搞了一上午和一下午添加了點歌功能
2/12 v0.58 上午嘗試通過微信控制 不斷出現離奇bug 數據庫被清空,花了半個小時重寫了一遍 于是趕忙改了回來,順便優化了一下數據庫下午做了用微信控制電腦的小腳本 開學裝班級電腦上 晚上加了語音輸入和打開office后自動按回車的設置
2/20 v0.7 重新寫了微信控制的代碼,整體良好,在等待用戶輸入這個功能上費了好長時間,因為微信接收消息是被動的。后來一個變量在當前模塊不生效,在其他模塊生效,索性(在當前模塊中調用另一模塊調用的當前模塊里的變量)
2/21 v0.78 用多進程解決了微信版不能檢查提醒的問題,修復了一堆reminding的bug
2/22 v0.9 小虎已經基本完成,又添加了用戶需求的五個功能:[打開,搜索的自定義;修復輸入指令不能輸入回車的bug;自動下載播放本機沒有的音樂;音量的調節;離我最近的提醒],為了操作網易云音樂下載了兩個大模塊,愣是把所有代碼用3個小時讀通了,把兩個模塊嫁接到了一起。Standard 1.0版本明天就要完成了,23日上午進行最后的完善和校驗,假期最后三天拍演示視頻
2/23 v1.0 Standard 又搞了好久把下載播放音樂的功能編完整了,大功告成~視頻我想等EVO完成后再拍,那樣更驚艷。
————總共1047行代碼————
————XiaoHu.ai Evolve 代號EVO————
?
3/11 開學了,開始小虎EVO版本的開發,大幅簡化播放音樂,添加提醒的過程
3/5-3/19進軍物聯網,第一次刷了raspbian和ha,可以查看燈的狀態但無法控制。于是兩個禮拜來一直刷hassbian和hass.io,結果發現系統都啟動不了,到了貴哥那里知道是供電,于是換了顯示器和電源。不知為啥hassbian和hassio可以啟動但沒有ha,所以又刷了raspbian,情況又和第一天一樣了。持續僵持,暫時休整。
4/5解決了持續快兩個月的大bug,刪除提醒刪除不干凈,于是機智地重寫了一遍,循環刪除,直到全刪除完了為止
4/6從姥姥家回家路上突發奇想,重新啟用科大訊飛api。科大訊飛的aiui自我步入EVO階段就一直想搞可惜它不支持python代碼,神奇的是回家一看發現它支持web post調用,于是申請了一個web應用,一個下午和晚上都忙于訊飛和小虎的對接。晚上再一次更新了數據庫的格式,刪除了一堆冗余的如runmode,runpath的tag,以及把之前一些tag的名字改成更易于理解的單詞,在變量命名上也與訊飛的json看齊,把之前的cmd“指令”改成intent“意圖”。又忙到了十一點..
4/7繼續忙于與訊飛的對接,訊飛的功能的確強大,使我精簡了一堆代碼,截至12點,小虎已經可以完成訊飛上95%的技能,達到小愛的75%水平。從此以后小虎的目標不是Jarvis而是小愛,小愛由于運行在手機上而有著得天獨厚的優勢,我想以后能不能把小虎的客戶端移植到手機上,保留電腦服務器端。不過那是下一個版本要做的事了。
4/21 4/9后給小虎定了10個小目標,兩個禮拜的現在已經基本完成了。多是一些重要優化,以及把放音樂的過程從調用win的media player改成了一個基于pygame的內置播放器,作為單獨進程執行,攻克了進程間共享變量的問題后就基本簡單了。新的播放器沒有窗口,在后臺運行,支持上一首、下一首、暫停、繼續等操作。
5/6期中考試后繼續搞XiaoHu,修復了幾個播放器的bug:在歌單中replay會播放第一首的bug;部分音樂網易沒有版權導致運行時報錯的解決方式;等等。XiaoHu距離物聯網的下一步已經很近了。
5/12 期末前最后一次編XiaoHu,加入了對訊飛API的超時處理,改了圖靈機器人無法處理的反饋。又用了一個小時的時間吧之前的爛代碼格式全部整理了一遍,XiaoHu的代碼現在除了注釋比較少之外基本能看。
4/9立下的十個目標都完成了。下一個是最后階段--HA。
————總共1218行代碼————
?
7/8 期末考完試開始編程,把期末前上廁所想到的“將HA安裝到win上”的想法實現,結果居然沒有報錯!無論是無線開關和夜燈都可以控制了。這是HA階段里程碑的一天。
7/14 新購置的傳感器到貨。添加了“自動化”功能,第一個自動化是通過檢測門窗傳感器達成開儲物間門時燈自動開啟,關門時燈自動關閉。一個bug讓我調了一上午,最后終于調好了。至此XiaoHu-HA階段的理論部分全部完成。剩下就是等月底搬家后大批量購置和建設自動化。由于XiaoHu的智能家居部分是全部模塊化的,所以月底就不用再多編什么代碼。
7/16 重新回到10space 上午做的XiaoHu的流程圖,下午在HA上搞了天氣組件,增加了簡報功能。修復了reminder的bug
7/17 做了一個與播放器原理相同的speaker,簡化了各個模塊的代碼。繼續修復提醒的bug
7/18 開始做電影的查詢和下載,通過編寫電影天堂和豆瓣的爬蟲實現下載、查詢的功能。我使用一個強大的模擬瀏覽器模塊selenium,這個模塊在我1月份開始學py做爬蟲時就聽說過,只是當時還是初學,對py了解不深,安裝都沒有成功。使用selenium可以讓我抓取一些動態網頁,或者是一些難爬的網頁。拿電影天堂為例,在主頁面輸入查詢電影名稱時,它會把電影字符串信息轉成一個ID,我通過Chrome的console試著找到轉換的規律,可并沒有找到。于是我使用selenium讓他模擬打開主頁面,再模擬輸入電影名稱,等轉到搜索頁面時,再把url轉給beautifulsoup,進行爬取。在XiaoHu播報電影查詢結果時,我發現了speaker的一個bug:由于它是連續播報,前一個語句還沒有播報1s,下一個就開始了,導致最后只放出來了最后一句話。7/23 經過調試我發現這是因為我給speaker設定的“同時只能有一個speaker存在”這是為了讓它在說話時可以隨意中斷。但它是異步的,沒有堵塞,就導致了這樣的情況。我、只好給它添加了“等待上一個speaker執行完”,解決了bug,卻犧牲了隨意中斷的能力。下一步我要做一個穩定的手機端client,貴哥建議我使用微信小程序。它使用js編程,有點像網頁。但由于我剛從py的順序結構程序轉過來,對js的事件驅動還不太適應。
7/24 我做了“機器人小程序”,通過使用圖靈機器人的API實現了自動聊天功能。對小程序有了了解,我計劃用py搭建一個服務器,使用http協議進行交互,搞了一晚上,最后發現http POST的方式只能一來一回,而這不符合XiaoHu的工作方式,只好把搭建好的服務器放棄了。我計劃使用socket將服務器與客戶端進行連接,達成一來多回的目的。
7/25 我計劃采用socket.io這一個已經充分封裝好的websocket模塊來通信。搞了一下午才找到合適的服務器,從django和flask中還是選了flask,最終使用flask-socketio,python-socketio和js-socketio分別是服務器和兩個客戶端,用js腳本先模仿微信小程序,指令從js端發出,通過服務器接收,由于服務器由python編寫,所以可以直接與XiaoHu源程序溝通,源程序調用py客戶端的send()方法,將反饋發給服務器,再由服務器轉發給前端。
7/27 上午11點就來到了10space,打算今天搞定小程序。到了之后就立刻開始wxsocketio的安裝,卻發現小程序的socketio無法與python的服務器和客戶端建立連接。無奈之下聽從貴哥的建議,使用node.js搭建服務器。下午搭建好了后發現可以與微信連接,卻不能與py客戶端連接。同時因為沒有了python的服務器,XiaoHu主程序無法獲取到指令。我的第一個方法是使用js的cmd模塊模擬win命令行調用XIaoHu主程序,再獲取程序所有的stdout。這種方法可以處理簡單的指令,但如果程序給的是“非一次性反饋”的話,它也會把所有的反饋湊在一起發給微信,這嚴重影響用戶體驗。而且由于主程序沒有連續運行,XiaoHu的上下文記憶功能受限,由于它的內置播放器是一個相對獨立的進程,如果主進程被迫“死掉”,播放器就會成為“僵尸進程”,不能關閉。我又想到給py客戶端添加接收功能,讓它從服務器獲取到指令信息。但另一個問題是這時的py客戶端由于不知名的原因,還無法與服務器進行連接。我上谷歌查了這種報錯的解決方案,github上說這個python-socketio庫早就停了更新,要使用另一個庫。我安裝了那另外一個庫,問題解決了。好不容易建立了通信,這時我又發現服務器又不能向客戶端發信息了。起初我以為是某個客戶端出了問題,但是經過排查發現都工作得很好。此時已快九點了。接了爸媽電話后又突然有了靈感,因為在25號的server-client模型中,每個發送操作都是需要廣播的,我想了一下,覺得客戶端的發送不需要廣播,反而是服務器需要用廣播把消息發給所有客戶端,于是我加了broadcast,一切正常了!到家,做了內網穿透,使得手機端小程序也可以參與通信。還修復了一些的bug。
————XiaoHu.ai Education 代號EDU————
?
10/5 開學后,XiaoHu轉型智能教室的構想逐漸成熟,docx設計計劃落地,前端設計草圖落地。
11/19 開始著手開發前端系統12/5 前端的HTML搭建基本完成,還剩下最大的一個問題是“div內換行問題”,我要讓我的文字在氣泡(承載了圖片的div)里換行,可是html內一個換行比我的氣泡都大,我用Line-height調整,又導致網頁的布局亂了,下周咨詢一下老師。
12/10 今天問了毛老師,他在div里加了一個p,用p把文字套起來后把line-height放在p里,成功了。好像是說line-height如果放在div內就會影響div的位置,放在p里文字的位置就會受限于div。前端設計完成了,開始搞網絡通信,使用XiaoHuEVO的server,client1,client2框架,因為有先前的經驗積累所以代碼移植過來后測試一次成功,周三把通信整個搞好。
12/13 今天把原EVO里的代碼都移了過來,去除了一些不會被用到的功能,完善了通信系統,可又遇到了新問題:即使這些python文件都放在一個目錄下,卻無法正常的互相引用。這是一個很奇怪的問題,因為在EVO的目錄下他們就可以正常引用。
12/15 今天查了一下import的相對引用和絕對引用,有了一些想法。我在根目錄下建立一個__init__.py,讓目錄成為一個大模塊,讓其余的py文件都成為它的子模塊,引用時通過母模塊調用子模塊,問題就解決了,這更類似于相對引用。我想了一下具體的用戶場景,覺得網頁在老師的手機上是不太方便操控的,而且絕不是最好的交互方式。而微信小程序也受限于其極短的生命周期不能作為前端。最后我選定了服務號,服務號在以前也作為小虎前端搞過,當時用的是itchatmp?,F在我再搜索Python服務號解決方案時已經多了很多新的庫,這才五個月啊。
12/16 我的第一個選擇是使用wechatpy搭配一個wsgi使用,功能還不錯但是不知道為什么我一引用XiaoHu其他的py文件就會無法引用,這 樣自然是無法使用的。還有一個選擇是django,明天試試。
12/17 django有些繁瑣且多余文件太多,在查找其他可行解決方式時我看到了werobot,一個非常精簡實用的python微信公眾號庫,測試也是一遍過。但是我引用XiaoHu的brain后就發現它卡住不能運行了。經過一番“print”斷點調試后我排除了werobot自身的問題。并把目光鎖定在了brain自身引用的一堆XiaoHu內部腳本上,我輪流添加了斷點,最終發現了問題所在:brain引用了socket.py,這個socket本來是在之前的server-client架構里使用的,現在已經不用了,而它的代碼里有一行向服務器申請連接的代碼"socket_send = SocketIO('127.0.0.1', 3000)" 然而我連服務器都沒有運行,它自然會陷入無限的重連中。我還沒有把這行放在"if name == main"中。我注釋掉了這行代碼,問題迎刃而解。然而在測試中我又發現它雖然可以接受消息并傳給brain,卻沒有向用戶返回消息。這肯定是brain的問題。我專門有一個reply變量存儲brain作出操作的返回值,而在每次操作后reply被賦值前會有一個speak方法,用來讓XiaoHu說出操作反饋。我把speak注釋掉,發現它成功的返回了返回值。現在我知道是speak堵塞的問題,我試著不運行robot,直接在brain里通過輸入給出命令,不使用werobot的時候就可以說話沒有堵塞。這就成了問題:我要使用werobot,又要讓它語音說出結果。到家后想出了解決辦法:把speak函數放到控制聲音的audio.py里面,然后使用socket連接brain和audio,brain要想要說話,就要發信息給audio,audio再播放。他們是兩個進程,就不會再有進程堵塞了。這個結構頗像由神經連起來的大腦和嘴巴。反正XiaoHu的brain以后會放在全天候運轉的服務器上,是肯定要和控制教室電腦客戶端聲音的audio分開的。這樣就完美解決了問題。服務號開發基本完成了(只用了三天),我 把XiaoHu的聊天功能開放給了同學們,于是整個晚上它都在說話,不得不說它還是很幽默的。
12/19 今天獲得了學校服務器的權限,我試著把XiaoHu服務器程序在服務器上運行起來,費了好大力氣把依賴庫安裝好,結果發現程序老是卡住,不知道為什么。python自帶的ide實在麻煩。
12/23 完善了人臉識別功能,全面換裝了百度v3版api,v3版本沒有了m:n多人識別,枚舉所有用戶來進行1:n識別太慢,不可行。最后的方案是先 使用face_detect檢測出圖片里所有人臉,分別框出輸出成臨時文件,然后對于只有一張人臉的文件,識別與之對應的用戶。百度給出的人臉 框太小了,導致識別身份時有時候會識別不出來,我強行增加了人臉框的大小,準確度就提高了。人臉模塊基本實現了,下一步就是等物聯 網部署后與攝像機的連接。
12/24 今天繼續調試服務器,先是在服務器系統上安裝了pycharm,用了這個ide后發現服務程序竟然可以運行了,十分神奇。于是用ngrok搞了個 內網穿透,綁定了微信服務號的服務器地址,XiaoHu就運行起來了。
“只要北大附的官網還能訪問,小虎就永遠存在?!?/p>
?
---------------------------------2 0 1 9----------------------------------------
2/1 之前想接入物聯網時出了離奇的bug,使得我的程序始終不能和網關建立連接,后來改了一下config,成功把網關又接入了XiaoHu,物聯網部 分沒有什么技術問題了。
2/5 修復了之前一直很苦惱的socket通信問題,原來是服務器的問題,服務器的腳本里應該填自身ip而不是127.0.0.1,怪不得本機調試沒有問題,一用遠程服務器就不行了,現在通信的bug也解決了。
2/6 今天,是XiaoHu一周年,但是要鴿了。
2/7~3-26 假期里訂購的攝像頭到貨,調試過程卻不是很順利,照著網上的hack教程做但是沒有起色,問了老師,也同樣無果。開學以來就一直在搞 服務器端和客戶端的連接問題,從學校服務器搞內網穿透,但是只能穿透一個端口,我需要80和3000。后來換了一個外網服務器,但是延遲太 高。在何天陽的幫助下借用了他的服務器,一度好使,不過由于他的一次事故導致原先的服務器壞掉,換了新的,卻不好使了,微信服務器驗證 總是失敗,我一度懷疑werobot的token驗證問題,并想換成php進行驗證。卡了很久,小虎的服務處于半宕機狀態。
3/27 放學后,我回閱覽室去找耳機,恰好碰上何天陽,跟他說了這個問題,他說是不是防火墻問題,因為他之前也在這個服務器上有這種情況,在 防火墻上打開那個端口就好了,我回去打開了80,php腳本就可以運行了。后來我想會不會python的驗證也是這種問題,一試,果然如此。依 次把80和3000端口打開,小虎復活了。
4/4 小虎現在還存在一個問題,那就是會有“答非所問”的情況,有時會把上個問題的答案放到下個問題去回答,而上個問題就沒有了回應,這在同時收到多個問題的情況下更易出現,。我分析了一下,我認為這種問題是由于第一個問題的答案被“堵塞”到了下一個問題,“堵塞”的原因則 是因為我給它設置的嚴苛的超時限制,超時限制是0.05s,50ms,這個時限是我在試圖增加它效率時給添加的,這對于它尚不穩定的服務來說未 免太短了。我把時限增加到了0.5s,同時為了使它能夠應付“連串問題”的情況,而不是收到多個問題后,哪個答案先返回就先說哪個,我在它 的數據包里增加了一個token,token基于當前時間,進行md5加密,可以保證沒有重復。這樣第一個問題在接收到正確token后才會回復答案。 這保證了回復的順序。
4/7 小虎在上個周末的服務很不穩定,重新調試了服務器,同步了兩端的文件,在pyclient上增加了斷線自動重連的設定。增加聊天記錄儲存,增加 以userid+timestamp的md5加密。
4/9 得到了希悅的clientid和clientsecret,這樣就可以用他的rest api,用request庫來發送get和post,post獲取authkey很成功,但是用get獲取課表信息就遇到了問題,他給的api地址里的末尾有一個/:id,我不知道這是干什么,原樣放了進去就404,上網查了好久,沒有結果,因為搜索引擎總是把我的/:這倆符號吃掉,最后受到一篇博客的啟發,用id變量直接代替/:id,成功收到了返回,也是漲知識了,因為之前壓根沒有用過get這種,但這次是沒有權限。
4/10 與希悅的工程師建立了微信溝通,他為我開放了權限,我也在他的指導下成功取得了返回,在通過學號查找獲取數據庫id的過程中,我發現即使 把學號作為參數傳了上去,結果依舊是沒有經過篩選的,后來得知要把id傳到網頁的后綴里,問題就解決了,結果只有查找到的一個學生?;丶覍?查課表的功能又做了一些拓展。
4/11 修復了小虎因聊天記錄讀寫錯誤而造成服務停機的bug。
總結
以上是生活随笔為你收集整理的XiaoHu.ai开发日志(自2018年2月6日至2019年4月11日)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SDRAM工作原理
- 下一篇: 牢记使命让你的公司走的更远