最近情绪比较低落，不想干活就发呆，躺着，也不看闲书——其实干活也不想干，平均每天不到三个钟。屏幕脏了不想擦，人脏了也不想洗，中午吃饭完了就想睡觉，一连做了一个钟头的梦，后来梦见别人踢足球，居然是国足，跟谁忘了，刚刚梦到国足被进了个球，电话噹啷啷想了，是L，催我写博客——当时比分是3-3，场面蛮热烈的。

说实话L，我也不知道写些什么，真没觉得最近有什么有意思的事情，二十天前写完论文第一稿，被打回来，把参考文献的顺序改了一下，程序一直都不想动，直到最近两天才踉踉跄跄去升级一下。原先的程序架构是纯顺序执行的，没有建机器人对象。对我来说boost, linux编程是件很麻烦的事情，一直都是现学现卖，把程序做成面向对象的方式不光是要用boost线程，连线程消息队列也要自己做——一者是担心现成的Linux消息队列放到这个Player机器人API上有冲突，之前用pthread多线程模型就和这个Player冲突，二者是本来Linux上的消息就不熟，还不如自己写一个，简陋是简陋点，权当是学点东西了。

关于毕业和工作的事情，原本年轻的时候很梦想出国来着，然而老老实实当了两年985垫底的学校的研究生之后，反而觉得出国注定是要赔钱的买卖。读完研究生都已经26了，应该是26吧？自从上了大学之后就算不清年龄了。离30岁只剩下4年，出国如果要学有所成，少则四五年，多则十七八年，人也不能一辈子就老死在国外，三十岁回来的人一点根基都没有，说不定就打入技术冷宫或者又重新回到学校了，这辈子还有什么玩的。说来说去，还是上学太晚，上小学晚了，上中学晚了，上大学也晚了。

最近GR上订阅的几个NEU的博客都更新的很不勤快，yloves.cn算是比较勤快的，貌似基本是一周一文，最北京、畅所未想两只博客就像是丢失句柄的线程，都不知道运行到哪了，至于spykitten、zyp.name，都快一年没响动了吧。因为长期敲键盘和不写字的缘故，今天跟X解释写图像和编码的问题的时候发现写得跟鸡爪子一样，篮球，没打，羽毛球，没打，乒乓球，偶尔，极品飞车，都懒得打了。写字，屁，根本没动，两年的研究生，过得像是一滩烂泥。

过了六年的大学，恍如隔世，就是这两年的研究生，隔开了曾经的风花雪月，阻断逝去的青葱岁月，就眼下这样行尸走肉一般的生活，说出来忒恶心，我是应该认真考虑一下写小说的意见了，很久之前别人给我的一个意见。虽然我一直用着电脑，写博客，写电子邮件，我还有QQ，有msn，有Gtalk——全是废物，除了上Gtalk抓入Z问问编程的问题，还有点用，写小说，哼哼，下一次博客，就标签，小说！小说题目，题目，呃，题目，呃，到时候再说了。

顺便说，这照片是前几天在图书馆照的，没想到还找到一本书，居然是李书福写的～～～

  最后说一下工作的事情，之前所有的程序都是顺序直线代码，代码复用率基本为0，而且根本谈不上机器人的多任务执行。最近一礼拜都在尝试把boost的线程和对面向对象设计都加上去，林林总总的还有很多其他要考虑的技术问题，boost的模板元编程真是看天书一样，看得眼睛喷血都看不出什么名堂来的。

今天晚上摸爬滚打了这么就，多线程的问题没有两个月也有一个半月，用boost的多线程人实在太少了，能人就更少。总算是做出来一个简陋的类内部线程跟对应的消息队列，消息读写锁还是没有考虑，应该那个锁我也不太明白～～～唉，该明白的我都还没明白呢，周围也没有可以求教的人～～～反正今天晚上刚刚写出来的这段代码跌跌撞撞能用，容错性可想而知，一点没有鲁棒性。

好久没来写，发现wordpress的界面居然有点陌生了。白天几乎没做什么，一直在看boost，被它的多线程和消息挂住了。回到寝室想设计一下Walk函数，没想到，发现一个严重的设计错误，机器人行走任务应该优先指定目的地或者子级目的地，而不是优先指定速度控制的动作序列，之前好几周的脑筋白伤了。走点弯路倒是不算什么，关键是时间紧迫，区区半年时间，真让人恼火，即便是早半年告诉我做机器人，也不至于窘迫成现在这个样子。

晚上做player的多线程总算是有点了眉目，其实对于boost的多线程根本一窍不通，完全照葫芦画瓢，线程间通信到时候该怎么办还一点数都没有。之前为了设计运动Task的Generator和Interpretor困顿了好几天，最后把程序的抽象层次一降再降，最后还是回到了switch的模式，Generator还没写，暂时搁置一下。

重新审视了一下，最初硬生生把运动分成MoveStraight, TurnAround, Turn, Stand几个基本运动貌似其实画蛇添足。原来这么设计是为了复杂曲线或者复杂的加速过程留条活路，但是现在一想，暂且不说精确的速度加速度控制实现的难度怎样，其必要性也很值得怀疑。白天的时候考虑了一下路径规划的方式，预先设置好一条精确的路线然后执行的思维是自动化的思维，在智能的行为方式其实很强调外界的反馈，人并不会首先考虑按照原定计划怎么走，而是先观察环境，再考虑是不是按照原计划进行，甚至只是先执行一部分的预定计划再说。对于速度控制，精确的速度和加速度过程控制只能属于自动化的范畴，智能化只求方向正确，最终达成目标即可，中途有多少意外情况其实都是次要的，只要不超过忍耐限度就行了。

晚上做player的多线程总算是有点了眉目，其实对于boost的多线程根本一窍不通，完全照葫芦画瓢，线程间通信到时候该怎么办还一点数都没有。之前为了设计运动Task的Generator和Interpretor困顿了好几天，最后把程序的抽象层次一降再降，最后还是回到了switch的模式，Generator还没写，暂时搁置一下。
重新审视了一下，最初硬生生把运动分成MoveStraight, TurnAround, Turn, Stand几个基本运动貌似其实画蛇添足。原来这么设计是为了复杂曲线或者复杂的加速过程留条活路，但是现在一想，暂且不说精确的速度加速度控制实现的难度怎样，其必要性也很值得怀疑。白天的时候考虑了一下路径规划的方式，预先设置好一条精确的路线然后执行的思维是自动化的思维，在智能的行为方式其实很强调外界的反馈，人并不会首先考虑按照原定计划怎么走，而是先观察环境，再考虑是不是按照原计划进行，甚至只是先执行一部分的预定计划再说。对于速度控制，精确的速度和加速度过程控制只能属于自动化的范畴，智能化只求方向正确，最终达成目标即可，中途有多少意外情况其实都是次要的，只要不超过忍耐限度就行了。

贴几张照片，解解闷

 看着这幢新楼堵住视野，闹心

又到一年毕业时

昨天的问题今天晚上回来之前终于调出一丝曙光，终于可以在int * 的抽象层面访问底层函数，然后用基本业务层里面爽了一把函数调用。简单说明一下下面的几个仿真图，右边那个小黑快就是机器人，用户命令为0.5m/s线速度，同时45度/s左转，其实在底层直线行走和拐弯两个动作是相互独立的功能函数，这种设计可以减轻用户安排任务的压力，可以直接考虑基本的运动动作。可能是学机械的缘故，反正这种线速度控制和角速度分别控制的方式才是最合理的，不管是用户要进行复杂运动设计，还是机器人本身要提供复杂运动的控制方式，有了这样的两个基本函数，就可以随意进行功能组合了。

仿真窗口里面长放射线是激光测距仪的模拟，短放射线是声纳测距的模拟，整个运动是从静止开始匀速运动，最后撞墙。Player所提供的驱动里面还没有找到有提供加速度控制的接口，有点遗憾，但是有了速度控制，对于高级任务设计已经绰绰有余了，高级用户应该会比较少的要求亲自对加速度也进行控制。

虽然最近没有停下上层设计，但是花在底层功能实现上的时间却是最多的，反而没有时间把完整的上层设计都实现了，这个草稿不知道哪个年月才能实现了，都已经是人机会话的高度了～～～