当前仓库属于关闭状态,部分功能使用受限,详情请查阅 仓库状态说明
11 Star 25 Fork 319

OpenHarmony-SIG/contest
关闭

加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目,私有仓库也完全免费 :)
免费加入
文件
克隆/下载
贡献代码
同步代码
取消
提示: 由于 Git 不支持空文件夾,创建文件夹后会生成空的 .keep 文件
Loading...
README

Harmony Puppy学习笔记

项目工程:Harmony Puppy

p.jpg

1 项目简介

本项目设计并制作了一款基于传智教育Hi3861物联网鸿蒙模组主控、12个DOF的桌面级舵狗。

  • 主控MCU:Hi3861模组
  • 关节位控电机:9g舵机 ---> MG90S;
  • 舵机驱动管理:PCA9685PW;
  • IMU传感器:MPU6050;
  • 电机供电:DC-DC BUCK电路 ---> MP2236
  • 移动电源:航模聚合物锂电池 ---> 2S-35C

2 设计思路

具体的工程内容在上述链接中可见,故本笔记中主要阐述下设计出该机器人时的一些思路。

2.1 机械结构设计思路

为了能够使机器人在三维空间中能够自由运动,首先,确定了机器人整体设计有12个自由度。

腿部结构: 考虑到机器人后续的运动性能和续航,该机器人腿部结构的设计思路是,尽量减轻了腿部重量与保证单腿上三个电机的安装位置紧凑。故大腿小腿的的结构采用了并联腿结构。该并联腿的机构原理属于借鉴参考了其他开源项目,并不是完全创新。

躯体结构: 在设计机器人躯体是,依照的是模块化思路,将整个躯体分解为由顶层板、底层板、左侧板、右侧板、前侧板、后侧板六部分拼接而成,然后再依次在各板块上进行安装接口与外形设计。

接口安排: 四条单腿的电机安装接口分别在左侧板与右侧板上,而控制板的接口在顶层板上,移动电源设计放置在机器人腹内,四足机器人顶层板的前后侧部分挖空方便理线,顶层板尾部设计有天线接口,底层板前侧设计了一处舵机接口。接口的方式几乎均为镂空,另一好处可以节省材料。

结构制造: 由于本人制造手段目前限制于仅FDM式3D打印机,故结构设计过程中尽量避免的平行与底面的悬空结构,故该机器人的各零部件在打印时几乎不需要支撑结构,即方便后处理步骤与节省材料。

2.2 电控硬件设计思路

主控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。

2.3 控制算法设计思路

整体思路: 四足机器人基本的运动控制几乎都是在实现单腿正逆解的基础上实现的。

  • 单腿正逆解:了解到有DH建模法、几何法等方法可以实现,个人此次采用的是几何法实现。(因为DH建模时因为arcsin出现了很多计算上的BUG)

  • 姿态逆解:姿态逆解即在单腿逆解基础上,通过单腿把整个躯体当做并联机构来控制,其实也就设计单腿和躯体的坐标系变换,理解相对运动即可。

  • 步态规划:步态规划要控制的一个是足端轨迹,一个是单个步态周期中各腿的运动。首先可理解的是各腿的运动轨迹,可均采用一种规划,本项目中采用的是摆线来规划。随后主要控制的便是一个步态周期,各单腿的抬起落下,即摆动相与支撑相。
    本项目中仅演示了Trot步态,即对角小跑步态。对于足端轨迹是实时解算的,对角两腿向前摆动时,另外对角两腿同步向后支撑,即控制的机器狗的整体移动。包括后续的转弯,左右平移皆是一个原理。

2.4 上位机设计思路

整体思路: 上位机设计在移动端,即Andorid开发实现。 采用的是UDP通信,机器人与手机连入同一个WiFi即可控制。 实现通信仅需要对齐IPV4地址与端口号即可。 App里主要需要实现WiFi通信、UI布局设计、指令设计即可。 此次主要挑战了一下在界面设计与交互上的美化,运用了圆环动画按钮,其他交互设计上也想着尽量简洁而美观,控件主要也就涉及了Button、EditText等。 此App目前还不太完善,后面会继续完善开发其他功能

3 总结感悟

(1)开发过程中卡壳,先检查硬件问题,再检查软件问题。

硬件问题一般比软件问题更麻烦一些,毕竟可能遇到需要重买材料,重新制板等时间成本较大的修补措施。

硬件问题检查: 一般采用控制变量法把所有的嫌疑因素逐个排除。比如,先考虑各器件的焊接是否正常(可采用万用表蜂鸣档检测)。如果有MCU的电路先检查MCU及其外围电路,是否能够烧录程序。因为之后可通过写各种Demo小程序来快速测试其他硬件资源是否正常。

检查MCU及其外围电路是否正常,可以先观察焊接上是否有虚焊,连锡等情况。如果均无问题可接着测供电电压是否正常。同时需注意,用电端烧毁一般是电压问题,供电端烧毁一般是电流过大。

软件问题调试: 如果有报错信息,就去阅读报错信息来调试代码。如果语法错误就比较容易解决。如果遇到比如LED驱动不亮,先检查封装或LED焊反没,检查原理图上LED是引脚电平拉高还是拉低点亮。如果遇到采用IIC通讯的OLED屏幕无法点亮,先写简单的程序测通,比如先使屏幕点亮,再试着点亮一个点,再点亮一条线,画出一个方块,写下一个字符。各种功能齐全后在组合调试出自己想要的效果。

而且单片机开发调试时不应该光敲代码,中间需要穿插烧录到单片机看是否能够实现效果。问题多的话尽量分阶段解决,而不是汇总到最后一起解决,不然很可能会出现找不到哪里出错的。

(2)优质的问题获得优质的回答。

提问者要多思考,如何阐述清楚具体自己的问题,考虑是否方便回答者能简洁地回答自己的问题,比如对方只用回答是还是不是。

比如,代码编译报错,如果问为什么自己的代码跑不起来,自己的LED灯不亮了,这无疑很难获得自己想要的答案。因为开发的很多时候错误的Bug千万种,正确的跑通路只有一条。单对这个问题别人也很难想到问题出在哪里。如果代码的报错,自己首先要去检查所报错的代码段,细化大概在哪一行出现了问题,个人先去通过搜索、调试等手段尝试能否解决,然后这时候应该比较自己问题在哪了。

虽然有时太具体的问题也不太好回答,比如有人问自己想用Hi3861模组开发一款能够监测室内温湿度并实现浇水的智能浇花器。这类问题涉及的内容就比较多,也不好获得自己想要的回答。调整一下的话,比如可以在问题最后加上,能吗?或者问哪款温湿度传感器比较推荐,浇水用哪款电机比较合适等之类细化一些的问题。

(3)做项目,要一边开发一边学习。

想做一个项目,不像之前我们所接触的教育那样,先把一个领域全方面熟悉摸透后再去做。毕竟想摸清某个领域都是很不容易的。要明确知道自己的需求,自己想要实现什么,大概可以怎么样去实现,然后再去学习。需要用什么去学什么,需要用多少就学多少,除非自己对某方面非常感兴趣。这样才有可能快速的去完成完成自己的需求和实现想法。其实自己现在在接触一些新项目时也会有很多自己不了解的内容,主要也是锻炼自主学习的能力。

做项目也是多做才可以更熟练,入门的话可以先跟着资料齐全,文档清晰的优秀开源作品复刻,做了几个后。随后也会发现自己如果想要实现什么项目时,思路也会变得清晰。

马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化
1
https://gitee.com/openharmony-sig/contest.git
git@gitee.com:openharmony-sig/contest.git
openharmony-sig
contest
contest
master

搜索帮助