boxz 的长相确实待人亲,第一次看到就喜欢上了,well done!
这几天给 boxz 做了个 android 客户端,顺便瞄了一下 boxz 的代码,感觉 boxz 还有很大的进步空间,索性斗胆写点个人的建议吧。
一、抽象和封装
在做客户端的时候,最开始的想设计成类似游戏手柄那样的万向控制杆,但通过阅读 boxz 的代码发现这是不可能的。
因为 boxz 的运动命令只能是如下中的一个:
停止
前进、前进一段时间后停止
后退、后退一段时间后停止
左转、左转一段时间后停止
右转、右转一段时间后停止
举个例子,我不能通过上面的命令控制 boxz 以大转弯半径左转前行,是不?
甚至,我不能控制 boxz 的速度,对不对?但实际上用电机驱动板控制行进速度是非常容易的,我们为什么要隐藏这个重要功能呢?
说实话我不清楚 boxz 当初的设计目标,但我猜测它应该是一个平台,允许玩家对其进行编程和控制,对不对?
那么,我个人认为,boxz 本身所提供的功能,不应该是一个应用功能,而是基本功能。
具体点说:
1、首先,我们应该把 boxz 的基本功能封装成一个 lib,对外我们只提供一个类及它的各种方法。
这样的好处是对于只是打算玩 boxz 的人,他只要研究他的控制程序就行了,根本不需要了解 boxz 内部是怎样的;
同时,如果想了解 boxz 也很简单,因为我们的 lib 是开源的。
2、boxz 类的基本方法应该尽量原子化,比如:move(int motoIndex, int direction, int speed);
这样的好处是,我们虽然对电机驱动板进行了封装,但却没有人为的隐藏它的功能,即玩家可以不受任何限制的控制 boxz 的运动,而不是我们提供给他们的:前进、后退、左转。。。。。
3、在这些原子方法的基础上,我们可以考虑进行高层封装,以方便玩家调用,比如(以双电机为例):
moveForward(int leftMotoSpeed, int rightMotoSpeed);
moveBackward(int leftMotoSpeed, int rightMotoSpeed);
二、通信协议
目前 boxz 的通信协议比较简单:单字符。
w、s、a、d、W、S、A、D、u、j、i、k、o、l、U、J、I、K、O、L、f
这个协议确实通俗易懂,符合喜欢玩格斗游戏的玩家的思维(哈哈,我喜欢玩侍魂。。。。)。
但这个协议信息量非常有限,几乎没有扩展性可谈。如果能够换成最经典的 header-body 方式就会好很多:
header 共 16 字节
1-2: 固定为 0x0B 0x0B
3-4: 协议版本
5-6: 消息类型 (例如: 0x00 0x01 代表 停止)
7-10: 内容长度(即不包括 header 的报文长度)
11-16: 保留 用 0x00 填充
body 长度由 header 中的内容长度控制(允许为 0),其内容为消息的参数,例如运动的方向、速度等。
再配合抽象出来的 boxz 类,我们可以实现无数多的功能而根本不需要修改协议本身。
三、玩具?机器人?
从目前 boxz 的代码上看,boxz 其实就是一个遥控玩具(连遥控模型都算不上,因为它的控制不是比例的)。
我想,这应该不是 boxz 这个项目的最终目标吧。。。。
其实 arduino 能干的事情太多了,咱们是否可以考虑换个思路,从玩具进步到机器人?
在现在这个 boxz 的硬件架构上,再增加如下硬件就可以变身成机器人了:
1、若干红外线传感器,用于判断周围是否有敌人或障碍;
2、一个超声波传感器,用于判断敌人或障碍的距离;
3、颜色传感器,用于敌我识别或寻找目标(可选)。
4、。。。。
同样,我们把这些传感器的探测结果也封装在 boxz 的 lib 中去。
哦了,现在的 boxz,就是一个真正的平台、真正的机器人了!
它能做什么?哈哈,完全由你来决定。障碍赛?拳皇?踢足球?灭火?救人?把妹?偷拍?。。。
是自主控制还是遥控?这个要看这场比赛的裁判是怎么想的了。。。。
一些拙见,希望给 boxz 项目尽点微薄之力,也祝愿可爱的 boxz 越来越好!
|