精华内容
下载资源
问答
  • 服务机器人架构
    千次阅读
    2019-09-26 10:14:11

        目前市场上主流轮式服务机器人(送餐机器人、迎宾机器人、家庭陪护机器人、酒店服务机器人等)主体架构分三层:人机交互层(Android系统)、自主导航层(Linux系统)、电机控制及传感器层(Stm32单片机);

        人机交互层:

            1.语音交互:科大讯飞、思必驰、云知声等

                 1.1科大讯飞的AIUI是目前唯一真正实现全双工人机交互场景,aiui有纯软件api方案、软核方案和硬核方案。其中软核方案需要将讯飞的aiui核心模块集成到运行Android系统的Arm主控板;硬核方案包括aiui核心板和底板,通过底板串口与Android主控板进行串口通信,此方案可以参看讯飞官方aiui评估板。

                 1.2思必驰的DUI系统采用半双工语音交互,对接很多成熟的第三方iot解决厂商(如南京物联等),多轮对话效果没有科大讯飞好;

            2.人脸识别:虹软、百度、汉王等

                  2.1虹软最大的特点是免费、轻量级、本地识别,适用场景:预识别对象较少

                  2.2百度识别率相对高、有本地识别和云端识别两个方案,参考百度官网,适用场景:预识别对象较大

                  2.3汉王比较传统的人脸识别方案,本地识别需要加密狗进行授权,适用场景:预识别对象较大

            3.问题集锦:mic 、摄像头等

                  3.1喇叭不发音或者噪音严重,大多是因为电流不稳或者电压不足造成的,大功率音箱可以通过电源模块、电压转换器单独给其供电以解决喇叭音量过小的问题;

                  3.2mic无法拾音,大多是摄像头自带mic占用mic通道、别的录音相关应用占用mic服务等造成的;

                  3.3摄像头无法预览,大多需要与硬件厂商沟通,一般是底层问题,可考虑摄像头的前后置的默认设置,可以通过android系统自带照相机检测其是否能正常工作;

                  3.4串口无法正常通信,检查波特率及串口名称是否一一对应,主控板底层硬件是否支持,可以通过pc机串口调试助手、usb转串模块测试主控板的串口是否能正常通信;

     

    更多相关内容
  • ROS机器人操作系统学习笔记(三)ROS通信架构 ROS的通信架构是ROS的灵魂,也是整个ROS正常运行的关键所在。ROS通信架构包括各种数据的处理,进程的运行,消息的传递等等。本章主要介绍了通信架构的基础通信方式和...

    ROS机器人操作系统学习笔记(三)ROS通信架构

    • ROS的通信架构是ROS的灵魂,也是整个ROS正常运行的关键所在。ROS通信架构包括各种数据的处理,进程的运行,消息的传递等等。本章主要介绍了通信架构的基础通信方式和相关概念。其中首先介绍了最小的进程单元节点Node,和节点管理器Node master。了解了ROS中的进程都是由很多的Node组成,并且由Node master来管理这些节点。
    • 第二节我们介绍了ROS的“发动机”——launch文件,学习它的格式和内容,更深入的理解ROS在启动运行时它的工作都是由什么进程支配的,从而理解启动运行的原理。
    • 在后面的几节我们介绍了ROS中通信方式。ROS中的通信方式有四种,主题、服务、参数服务器、动作库。每个通信方式都有自己的特点,本章首先介绍话题通信方式–topic。

    3.1 Node & Master

    3.1.1 Node

    在ROS的世界里,最小的进程单元就是节点(node)。一个软件包里可以有多个可执行文件,可执行文件在运行之后就成了一个进程(process),这个进程在ROS中就叫做节点
    从程序角度来说,node就是一个可执行文件(通常为C++编译生成的可执行文件、Python脚本)被执行,加载到了内存之中;从功能角度来说,通常一个node负责者机器人的某一个单独的功能。由于机器人的功能模块非常复杂,我们往往不会把所有功能都集中到一个node上,而会采用分布式的方式,把鸡蛋放到不同的篮子里。例如有一个node来控制底盘轮子的运动,有一个node驱动摄像头获取图像,有一个node驱动激光雷达,有一个node根据传感器信息进行路径规划……这样做可以降低程序发生崩溃的可能性,试想一下如果把所有功能都写到一个程序中,模块间的通信、异常处理将会很麻烦。

    3.1.2 Master

    由于机器人的元器件很多,功能庞大,因此实际运行时往往会运行众多的node,负责感知世界、控制运动、决策和计算等功能。那么如何合理的进行调配、管理这些node?这就要利用ROS提供给我们的节点管理器master, master在整个网络通信架构里相当于管理中心,管理着各个node。node首先在master处进行注册,之后master会将该node纳入整个ROS程序中。node之间的通信也是先由master进行“牵线”,才能两两的进行点对点通信。当ROS程序启动时,第一步首先启动master,由节点管理器处理依次启动node。

    就像GitHub里面的结点和分支一样,要进行管理。

    3.1.3 启动master和node

    当我们要启动ROS时,首先输入命令:

    $ roscore
    

    此时ROS master启动,同时启动的还有rosoutparameter server,其中rosout是负责日志输出的一个节点,其作用是告知用户当前系统的状态,包括输出系统的error、warning等等,并且将log记录于日志文件中,parameter server即是参数服务器,它并不是一个node,而是存储参数配置的一个服务器,后文我们会单独介绍。每一次我们运行ROS的节点前,都需要把master启动起来,这样才能够让节点启动和注册。

    master之后,节点管理器就开始按照系统的安排协调进行启动具体的节点。节点就是一个进程,只不过在ROS中它被赋予了专用的名字里——node。在第二章我们介绍了ROS的文件系统,我们知道一个package中存放着可执行文件,可执行文件是静态的,当系统执行这些可执行文件,将这些文件加载到内存中,它就成为了动态的node。具体启动node的语句是:

    $ rosrun pkg_name node_name
    

    通常我们运行ROS,就是按照这样的顺序启动,有时候节点太多,我们会选择用launch文件来启动,下一小节会有介绍。
    Master、Node之间以及Node之间的关系如下图所示:

    img

    3.1.3 rosrun和rosnode命令

    3.1.3 rosrun和rosnode命令

    rosrun命令的详细用法如下

    $ rosrun [--prefix cmd] [--debug] pkg_name node_name [ARGS]
    

    rosrun将会寻找PACKAGE下的名为EXECUTABLE的可执行程序,将可选参数ARGS传入。
    例如在GDB下运行ros程序:

    $ rosrun --prefix 'gdb -ex run --args' pkg_name node_name
    

    rosnode命令的详细作用列表如下

    rosnode命令作用
    rosnode list列出当前运行的node信息
    rosnode info node_name显示出node的详细信息
    rosnode kill node_name结束某个node
    rosnode ping测试连接节点
    rosnode machine列出在特定机器或列表机器上运行的节点
    rosnode cleanup清除不可到达节点的注册信息

    以上命令中常用的为前三个,在开发调试时经常会需要查看当前node以及node信息,所以请记住这些常用命令。如果你想不起来,也可以通过rosnode help来查看rosnode命令的用法。

    3.2 launch文件

    3.2.1 launch简介

    机器人是一个系统工程,通常一个机器人运行操作时要开启很多个node,对于一个复杂的机器人的启动操作应该怎么做呢?当然,我们并不需要每个节点依次进行rosrun,ROS为我们提供了一个命令能一次性启动master和多个node。该命令是:

    $ roslaunch pkg_name file_name.launch

    roslaunch命令首先会自动进行检测系统的roscore有没有运行,也即是确认节点管理器是否在运行状态中,如果master没有启动,那么roslaunch就会首先启动master,然后再按照launch的规则执行。launch文件里已经配置好了启动的规则。
    所以roslaunch就像是一个启动工具,能够一次性把多个节点按照我们预先的配置启动起来,减少我们在终端中一条条输入指令的麻烦。

    3.2.2 写法与格式

    launch文件同样也遵循着xml格式规范,是一种标签文本,它的格式包括以下标签:

    <launch>	<!--根标签-->
    <node>	<!--需要启动的node及其参数-->
    <include>	<!--包含其他launch-->
    <machine>	<!--指定运行的机器-->
    <env-loader>	<!--设置环境变量-->
    <param>	<!--定义参数到参数服务器-->
    <rosparam>	<!--启动yaml文件参数到参数服务器-->
    <arg>	<!--定义变量-->
    <remap>	<!--设定参数映射-->
    <group>	<!--设定命名空间-->
    </launch>	<!--根标签-->
    

    3.3 Topic

    ROS的通信方式是ROS最为核心的概念,ROS系统的精髓就在于它提供的通信架构。ROS的通信方式有以下四种:

    • Topic 主题
    • Service 服务
    • Parameter Service 参数服务器
    • Actionlib 动作库

    ROS中的通信方式中,topic是常用的一种。对于实时性、周期性的消息,使用topic来传输是最佳的选择。topic是一种点对点的单向通信方式,这里的“点”指的是node,也就是说node之间可以通过topic方式来传递信息。topic要经历下面几步的初始化过程:首先,publisher节点和subscriber节点都要到节点管理器进行注册,然后publisher会发布topic,subscriber在master的指挥下会订阅该topic,从而建立起sub-pub之间的通信。

    img

    Subscriber接收消息会进行处理,一般这个过程叫做回调(Callback)。所谓回调就是提前定义好了一个处理函数(写在代码中),当有消息来就会触发这个处理函数,函数会对消息进行处理。

    示例:

    我们以摄像头画面的发布、处理、显示为例讲讲topic通信的流程。在机器人上的摄像头拍摄程序是一个node(圆圈表示,我们记作node1),当node1运行启动之后,它作为一个Publisher就开始发布topic。比如它发布了一个topic(方框表示),叫做/camera_rgb,是rgb颜色信息,即采集到的彩色图像。同时,node2假如是图像处理程序,它订阅了/camera_rgb这个topic,经过节点管理器的介绍,它就能建立和摄像头节点(node1)的连接。

    那么怎么样来理解**“异步”**这个概念呢?在node1每发布一次消息之后,就会继续执行下一个动作,至于消息是什么状态、被怎样处理,它不需要了解;而对于node2图像处理程序,它只管接收和处理/camera_rgb上的消息,至于是谁发来的,它不会关心。所以node1、node2两者都是各司其责,不存在协同工作,我们称这样的通信方式是异步的。

    ROS是一种分布式的架构,一个topic可以被多个节点同时发布,也可以同时被多个节点接收。比如在这个场景中用户可以再加入一个图像显示的节点,我们在想看看摄像头节点的画面,则可以用自己的笔记本连接到机器人上的节点管理器,然后在自己的电脑上启动图像显示节点。

    这就体现了分布式系统通信的好处:扩展性好、软件复用率高。

    总结三点

    1. topic通信方式是异步的,发送时调用publish()方法,发送完成立即返回,不用等待反馈。
    2. subscriber通过回调函数的方式来处理消息。
    3. topic可以同时有多个subscribers,也可以同时有多个publishers。ROS中这样的例子有:/rosout、/tf等等。

    3.3.4 操作命令

    在实际应用中,我们应该熟悉topic的几种使用命令,下表详细的列出了各自的命令及其作用。

    命令作用
    rostopic list列出当前所有的topic
    rostopic info topic_name显示某个topic的属性信息
    rostopic echo topic_name显示某个topic的内容
    rostopic pub topic_name ...向某个topic发布内容
    rostopic bw topic_name查看某个topic的带宽
    rostopic hz topic_name查看某个topic的频率
    rostopic find topic_type查找某个类型的topic
    rostopic type topic_name查看某个topic的类型(msg)

    如果你一时忘记了命令的写法,可以通过rostopic helprostopic command -h查看具体用法。

    3.3.5 测试实例

    1. 首先打开ROS-Academy-for-Beginners的模拟场景,输入roslaunch robot_sim_demo robot_spawn_launch,看到我们仿真的模拟环境。该launch文件启动了模拟场景、机器人。
    2. 查看当前模拟器中存在的topic,输入命令rostopic list。可以看到许多topic,它们可以视为模拟器与外界交互的接口。
    3. 查询topic/camera/rgb/image_raw的相关信息:rostopic info /camera/rgb/image_raw。则会显示类型信息type,发布者和订阅者的信息。
    4. 上步我们在演示中可以得知,并没有订阅者订阅该主题,我们指定image_view来接收这个消息,运行命令rosrun image_view image_view image:=<image topic> [transport]。我们可以看到message,即是上一步中的type。
    5. 同理我们可以查询摄像头的深度信息depth图像。
    6. 在用键盘控制仿真机器人运动的时候,我们可以查看速度指令topic的内容rostopic echo /cmd_vel ,可以看到窗口显示的各种坐标参数在不断的变化。

    通过这些实例的测试,帮助我们更快的掌握topic各种操作命令的使用,以及对topic通信的理解。

    3.4 Message

    topic有很严格的格式要求,比如上节的摄像头进程中的rgb图像topic,它就必然要遵循ROS中定义好的rgb图像格式。这种数据格式就是Message。Message按照定义解释就是topic内容的数据类型,也称之为topic的格式标准。这里和我们平常用到的Massage直观概念有所不同,这里的Message不单单指一条发布或者订阅的消息,也指定为topic的格式标准。

    3.4.1 结构与类型

    基本的msg包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、duration、header、可变长数组array[]、固定长度数组array[C]。那么具体的一个msg是怎么组成的呢?我们用一个具体的msg来了解,例如上例中的msg sensor_msg/image,位置存放在sensor_msgs/msg/image.msg里,它的结构如下:

    std_msg/Header header
    	uint32	seq
    	time	stamp
    	string	frame_id
    uint32	height
    uint32	width
    string	encoding
    uint8	is_bigendian
    uint32	step
    uint8[]	data
    

    观察上面msg的定义,是不是很类似C语言中的结构体呢?通过具体的定义图像的宽度,高度等等来规范图像的格式。所以这就解释了Message不仅仅是我们平时理解的一条一条的消息,而且更是ROS中topic的格式规范。或者可以理解msg是一个“类”,那么我们每次发布的内容可以理解为“对象”,这么对比来理解可能更加容易。

    3.4.2 操作命令

    rosmsg的命令相比topic就比较少了,只有两个如下:

    rosmsg命令作用
    rosmsg list列出系统上所有的msg
    rosmsg show msg_name显示某个msg的内容

    3.5 常见的msg

    本小节主要介绍常见的message类型,包括std_msgs, sensor_msgs, nav_msgs, geometry_msgs等

    Vector3.msg

    #文件位置:geometry_msgs/Vector3.msg
    
    float64 x
    float64 y
    float64 z
    

    Accel.msg
    #定义加速度项,包括线性加速度和角加速度
    #文件位置:geometry_msgs/Accel.msg
    Vector3 linear
    Vector3 angular

    Header.msg
    #定义数据的参考时间和参考坐标
    #文件位置:std_msgs/Header.msg
    uint32 seq #数据ID
    time stamp #数据时间戳
    string frame_id #数据的参考坐标系

    Echos.msg
    #定义超声传感器
    #文件位置:自定义msg文件
    Header header
    uint16 front_left
    uint16 front_center
    uint16 front_right
    uint16 rear_left
    uint16 rear_center
    uint16 rear_right

    Quaternion.msg

    #消息代表空间中旋转的四元数
    #文件位置:geometry_msgs/Quaternion.msg
    
    float64 x
    float64 y
    float64 z
    float64 w
    

    Imu.msg

    #消息包含了从惯性原件中得到的数据,加速度为m/^2,角速度为rad/s
    #如果所有的测量协方差已知,则需要全部填充进来如果只知道方差,则
    #只填充协方差矩阵的对角数据即可
    #位置:sensor_msgs/Imu.msg
    
    Header header
    Quaternion orientation
    float64[9] orientation_covariance
    Vector3 angular_velocity
    float64[9] angular_velocity_covariance
    Vector3 linear_acceleration
    float64[] linear_acceleration_covariance
    

    LaserScan.msg

    #平面内的激光测距扫描数据,注意此消息类型仅仅适配激光测距设备
    #如果有其他类型的测距设备(如声呐),需要另外创建不同类型的消息
    #位置:sensor_msgs/LaserScan.msg
    
    Header header			#时间戳为接收到第一束激光的时间
    float32 angle_min		#扫描开始时的角度(单位为rad)
    float32 angle_max		#扫描结束时的角度(单位为rad)
    float32 angle_increment	#两次测量之间的角度增量(单位为rad)
    float32 time_increment	#两次测量之间的时间增量(单位为s)
    float32 scan_time		#两次扫描之间的时间间隔(单位为s)
    float32 range_min		#距离最小值(m)
    float32 range_max		#距离最大值(m)
    float32[] ranges		#测距数据(m,如果数据不在最小数据和最大数据之间,则抛弃)
    float32[] intensities	#强度,具体单位由测量设备确定,如果仪器没有强度测量,则数组为空即可
    

    Point.msg

    #空间中的点的位置
    #文件位置:geometry_msgs/Point.msg
    
    float64 x
    float64 y
    float64 z
    

    Pose.msg

    #消息定义自由空间中的位姿信息,包括位置和指向信息
    #文件位置:geometry_msgs/Pose.msg
    
    Point position
    Quaternion orientation
    

    PoseStamped.msg

    #定义有时空基准的位姿
    #文件位置:geometry_msgs/PoseStamped.msg
    
    Header header
    Pose pose
    

    PoseWithCovariance.msg

    #表示空间中含有不确定性的位姿信息
    #文件位置:geometry_msgs/PoseWithCovariance.msg
    
    Pose pose
    float64[36] covariance
    

    Power.msg

    #表示电源状态,是否开启
    #文件位置:自定义msg文件
    Header header
    bool power
    ######################
    bool ON  = 1
    bool OFF = 0
    

    Twist.msg

    #定义空间中物体运动的线速度和角速度
    #文件位置:geometry_msgs/Twist.msg
    
    Vector3 linear
    Vector3 angular
    

    TwistWithCovariance.msg

    #消息定义了包含不确定性的速度量,协方差矩阵按行分别表示:
    #沿x方向速度的不确定性,沿y方向速度的不确定性,沿z方向速度的不确定性
    #绕x转动角速度的不确定性,绕y轴转动的角速度的不确定性,绕z轴转动的
    #角速度的不确定性
    #文件位置:geometry_msgs/TwistWithCovariance.msg
    
    Twist twist
    float64[36] covariance  #分别表示[x; y; z; Rx; Ry; Rz]
    

    Odometry.msg

    #消息描述了自由空间中位置和速度的估计值
    #文件位置:nav_msgs/Odometry.msg
    
    Header header
    string child_frame_id
    PoseWithCovariance pose
    TwistWithCovariance twist
    

    3.6 service

    上一章我们介绍了ROS的通信方式中的topic(主题)通信,我们知道topic是ROS中的一种单向的异步通信方式。然而有些时候单向的通信满足不了通信要求,比如当一些节点只是临时而非周期性的需要某些数据,如果用topic通信方式时就会消耗大量不必要的系统资源,造成系统的低效率高功耗。
    这种情况下,就需要有另外一种请求-查询式的通信模型。这节我们来介绍ROS通信中的另一种通信方式——service(服务)。

    3.6.1 工作原理

    为了解决以上问题,service方式在通信模型上与topic做了区别。Service通信是双向的,它不仅可以发送消息,同时还会有反馈。所以service包括两部分,一部分是请求方(Clinet),另一部分是应答方/服务提供方(Server)。这时请求方(Client)就会发送一个request,要等待server处理,反馈回一个reply,这样通过类似“请求-应答”的机制完成整个服务通信。img

    Service是同步通信方式,所谓同步就是说,此时Node A发布请求后会在原地等待reply,直到Node B处理完了请求并且完成了reply,Node A才会继续执行。Node A等待过程中,是处于阻塞状态的成通信。这样的通信模型没有频繁的消息传递,没有冲突与高系统资源的占用,只有接受请求才执行服务,简单而且高效。

    3.6.2 topic VS service

    名称TopicService
    通信方式异步通信同步通信
    实现原理TCP/IPTCP/IP
    通信模型Publish-SubscribeRequest-Reply
    映射关系Publish-Subscribe(多对多)Request-Reply(多对一)
    特点接受者收到数据会回调(Callback)远程过程调用(RPC)服务器端的服务
    应用场景连续、高频的数据发布偶尔使用的功能/具体的任务
    举例激光雷达、里程计发布数据开关传感器、拍照、逆解计算

    3.6.3 操作命令

    在实际应用中,service通信方式的命令时rosservice,具体的命令参数如下表:

    rosservice 命令作用
    rosservice list显示服务列表
    rosservice info打印服务信息
    rosservice type打印服务类型
    rosservice uri打印服务ROSRPC uri
    rosservice find按服务类型查找服务
    rosservice call使用所提供的args调用服务
    rosservice args打印服务参数

    3.7 Srv

    类似msg文件,srv文件是用来描述服务(service数据类型的,service通信的数据格式定义在*.srv中。它声明了一个服务,包括请求(request)和响应(reply)两部分。其格式声明如下:

    msgs_demo/srv/DetectHuman.srv

    bool start_detect
    ---
    my_pkg/HumanPose[] pose_data
    

    msgs_demo/msg/HumanPose.msg

    std_msgs/Header header
    string uuid
    int32 number_of_joints
    my_pkg/JointPose[]joint_data
    

    msgs_demo/msg/JointPose.msg

    string joint_name
    geometry_msgs/Pose pose
    floar32 confidence
    

    DetectHUman.srv文件为例,该服务例子取自OpenNI的人体检测ROS软件包。它是用来查询当前深度摄像头中的人体姿态和关节数的。srv文件格式很固定,第一行是请求的格式,中间用**—**隔开,第三行是应答的格式。在本例中,请求为是否开始检测,应答为一个数组,数组的每个元素为某个人的姿态(HumanPose)。而对于人的姿态,其实是一个msg,所以srv可以嵌套msg在其中,但它不能嵌套srv

    3.7.2 操作命令

    具体的操作指令如下表:

    rossrv 命令作用
    rossrv show显示服务描述
    rossrv list列出所有服务
    rossrv md5显示服务md5sum
    rossrv package列出包中的服务
    rossrv packages列出包含服务的包

    3.7.3 修改部分文件

    定义完了msg、srv文件,还有重要的一个步骤就是修改package.xml和修改CMakeList.txt。这些文件需要添加一些必要的依赖等,例如:

    <build_depend>** message_generation **</build_depend>
    <run_depend>** message_runtime **</run_depend>
    

    上述文本中“**”所引就是新添加的依赖。又例如:

    find_package(...roscpp rospy std_msgs ** message_generation **)
    catkin_package(
    ...
    CATJIN_DEPENDS ** message_runtime ** ...
    ...)
    
    add_message_file(
    FILES
    ** DetectHuman.srv **
    ** HumanPose.msg **
    ** JointPos.msg **)
    
    ** generate_messages(DEPENDENCIES std_msgs) **
    

    添加的这些内容指定了srv或者msg在编译或者运行中需要的依赖。

    4.8 Parameter server

    这节介绍另外一种通信方式——参数服务器(parameter server)。与前两种通信方式不同,参数服务器也可以说是特殊的“通信方式”。特殊点在于参数服务器是节点存储参数的地方、用于配置参数,全局共享参数。参数服务器使用互联网传输,在节点管理器中运行,实现整个通信过程。

    参数服务器,作为ROS中另外一种数据传输方式,有别于topic和service,它更加的静态。参数服务器维护着一个数据字典,字典里存储着各种参数和配置。

    何为字典,其实就是一个个的键值对,我们小时候学习语文的时候,常常都会有一本字典,当遇到不认识的字了我们可以查部首查到这个字,获取这个字的读音、意义等等,而这里的字典可以对比理解记忆。键值kay可以理解为语文里的“部首”这个概念,每一个key都是唯一的

    参数服务器的维护方式非常的简单灵活,总的来讲有三种方式:

    • 命令行维护
    • launch文件内读写
    • node源码

    3.8.1 命令行维护

    使用命令行来维护参数服务器,主要使用rosparam语句来进行操作的各种命令,如下表:

    rosparam 命令作用
    rosparam set param_key param_value设置参数
    rosparam get param_key显示参数
    rosparam load file_name从文件加载参数
    rosparam dump file_name保存参数到文件
    rosparam delete删除参数
    rosparam list列出参数名称

    load&&dump文件

    load和dump文件需要遵守YAML格式,YAML格式具体示例如下:

    name:'Zhangsan'
    age:20
    gender:'M'
    score{Chinese:80,Math:90}
    score_history:[85,82,88,90]
    

    简明解释。就是“名称+:+值”这样一种常用的解释方式。一般格式如下:

    key : value
    

    遵循格式进行定义参数。其实就可以把YAML文件的内容理解为字典,因为它也是键值对的形式。

    3.8.2 launch文件内读写

    launch文件中有很多标签,而与参数服务器相关的标签只有两个,一个是<param>,另一个是<rosparam>。这两个标签功能比较相近,但<param>一般只设置一个参数,请看下例:

    (1)<param name="robot_description" command="$(find xacro)/xacro.py $(find robot_sim_demo)/urdf/robot.xacro" />
    <!--在Gazebo中启动机器人模型-->
    <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen" 
        args="-urdf -x $(arg x) -y $(arg y) -z $(arg z) -Y $(arg yaw) -model xbot2 -param robot_description"/>
        
    <!--把关节控制的配置信息读到参数服务器-->
    (2)<rosparam file="$(find robot_sim_demo)/config/xbot2_control.yaml" command="load"/>
    
    <!--启动关节控制器-->
    <node name="spawner" pkg="controller_manager" type="spawner" respawn="false"
    output="screen" ns="/xbot2" args="joint_state_controller
    yaw_platform_position_controller
    pitch_platform_position_controller
    "/>  <!--mobile_base_controller-->
    
    
      <!-- 将关节状态转换为TF变-->
      <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" ns="/xbot2" respawn="false" output="screen">
        (3)<param name="publish_frequency" value="100.0"/>
      </node-->
    </launch>
    

    观察上例比如序号3的param就定义了一个key和一个value,交给了参数服务器维护。而序号1的param只给出了key,没有直接给出value,这里的value是由后没的脚本运行结果作为value进行定义的。序号(2)就是rosparam的典型用法,先指定一个YAML文件,然后施加command,其效果等于rosparam load file_name

    3.8.3 node源码

    除了上述最常用的两种读写参数服务器的方法,还有一种就是修改ROS的源码,也就是利用API来对参数服务器进行操作

    3.9 Action

    Actionlib是ROS中一个很重要的库,类似service通信机制,actionlib也是一种请求响应机制的通信方式,actionlib主要弥补了service通信的一个不足,就是当机器人执行一个长时间的任务时,假如利用service通信方式,那么publisher会很长时间接受不到反馈的reply,致使通信受阻。当service通信不能很好的完成任务时候,actionlib则可以比较适合实现长时间的通信过程,actionlib通信过程可以随时被查看过程进度,也可以终止请求,这样的一个特性,使得它在一些特别的机制中拥有很高的效率。

    3.9.1 通信原理

    Action的工作原理是client-server模式,也是一个双向的通信模式。通信双方在ROS Action Protocol下通过消息进行数据的交流通信。client和server为用户提供一个简单的API来请求目标(在客户端)或通过函数调用和回调来执行目标(在服务器端)。工作结构示意图如下:

    img

    通信双方在ROS Action Protocal下进行交流通信是通过接口来实现,如下图:

    img

    我们可以看到,客户端会向服务器发送目标指令和取消动作指令,而服务器则可以给客户端发送实时的状态信息,结果信息,反馈信息等等,从而完成了service没法做到的部分.

    3.9.3 Action规范

    利用动作库进行请求响应,动作的内容格式应包含三个部分,目标、反馈、结果。

    • 目标

    机器人执行一个动作,应该有明确的移动目标信息,包括一些参数的设定,方向、角度、速度等等。从而使机器人完成动作任务。

    • 反馈

    在动作进行的过程中,应该有实时的状态信息反馈给服务器的实施者,告诉实施者动作完成的状态,可以使实施者作出准确的判断去修正命令。

    • 结果

    当运动完成时,动作服务器把本次运动的结果数据发送给客户端,使客户端得到本次动作的全部信息,例如可能包含机器人的运动时长,最终姿势等等。

    Action规范文件的后缀名是.action,它的内容格式如下:

    # Define the goal
    uint32 dishwasher_id  # Specify which dishwasher we want to use
    ---
    # Define the result
    uint32 total_dishes_cleaned
    ---
    # Define a feedback message
    float32 percent_complete
    

    3.10 附录

    3.10.1 常见srv类型

    本小节介绍常见的srv类型及其定义
    srv类型相当于两个message通道,一个发送,一个接收

    AddTwoInts.srv

    #对两个整数求和,虚线前是输入量,后是返回量
    #文件位置:自定义srv文件
    int32 a
    int32 b
    ---
    int32 sum
    

    Empty.srv

    #文件位置:std_srvs/Empty.srv
    #代表一个空的srv类型
    
    ---
    

    GetMap.srv

    #文件位置:nav_msgs/GetMap.srv
    #获取地图,注意请求部分为空
    
    ---
    nav_msgs/OccupancyGrid map
    

    GetPlan.srv

    #文件位置:nav_msgs/GetPlan.srv
    #得到一条从当前位置到目标点的路径
    geometry_msgs/PoseStamped start		#起始点
    geometry_msgs/PoseStamped goal		#目标点
    float32 tolerance	#到达目标点的x,y方向的容错距离
    ---
    nav_msgs/Path plan
    

    SetBool.srv

    #文件位置:std_srvs/SetBools.srv
    bool data # 启动或者关闭硬件
    ---
    bool success   # 标示硬件是否成功运行
    string message # 运行信息
    

    SetCameraInfo.srv

    #文件位置:sensor_msgs/SetCameraInfo.srv
    #通过给定的CameraInfo相机信息,来对相机进行标定
    sensor_msgs/CameraInfo camera_info		#相机信息
    ---
    bool success			#如果调用成功,则返回true
    string status_message	#给出调用成功的细节
    

    SetMap.srv

    #文件位置:nav_msgs/SetMap.srv
    #以初始位置为基准,设定新的地图
    nav_msgs/OccupancyGrid map
    geometry_msgs/PoseWithCovarianceStamped initial_pose
    ---
    bool success
    

    TalkerListener.srv

    #文件位置: 自定义srv文件
    ---
    bool success   # 标示srv是否成功运行
    string message # 信息,如错误信息等
    

    Trigger.srv

    #文件位置:std_srvs/Trigger.srv
    ---
    bool success   # 标示srv是否成功运行
    string message # 信息,如错误信息等
    

    3.10.2 常见action类型

    本小节介绍常见的action类型以及其定义

    AddTwoInts.action

    #文件位置:自定义action文件
    #表示将两个整数求和
    int64 a
    int64 b
    ---
    int64 sum
    ---
    

    AutoDocking.action

    #文件位置:自定义action文件
    #goal
    ---
    #result
    string text
    ---
    #feedback
    string state
    string text
    

    GetMap.action

    #文件位置:nav_msgs/GetMap.action
    #获取地图信息,响应部分为空
    
    ---
    nav_msgs/OccupancyGrid map
    ---
    #无返回部分
    

    MoveBase.action

    #文件位置:geometry_msgs/MoveBase.action
    geometry_msgs/PoseStamped target_pose
    ---
    ---
    geometry_msgs/PoseStamped base_position
    s   # 标示srv是否成功运行
    string message # 信息,如错误信息等
    

    Trigger.srv

    #文件位置:std_srvs/Trigger.srv
    ---
    bool success   # 标示srv是否成功运行
    string message # 信息,如错误信息等
    

    3.10.2 常见action类型

    本小节介绍常见的action类型以及其定义

    AddTwoInts.action

    #文件位置:自定义action文件
    #表示将两个整数求和
    int64 a
    int64 b
    ---
    int64 sum
    ---
    

    AutoDocking.action

    #文件位置:自定义action文件
    #goal
    ---
    #result
    string text
    ---
    #feedback
    string state
    string text
    

    GetMap.action

    #文件位置:nav_msgs/GetMap.action
    #获取地图信息,响应部分为空
    
    ---
    nav_msgs/OccupancyGrid map
    ---
    #无返回部分
    

    MoveBase.action

    #文件位置:geometry_msgs/MoveBase.action
    geometry_msgs/PoseStamped target_pose
    ---
    ---
    geometry_msgs/PoseStamped base_position
    

    文章来源:https://www.kancloud.cn/zhouws/robot_ustc_mooc/2153685

    展开全文
  • 基于ROS的移动机器人上层系统架构分析   看过网上不少博客,介绍ROS系统架构的,基本上都是在介绍ROS自身系统架构,很少有介绍特定机器人的系统架构的。个人觉得,入门一个系统,首先需要从整体开始把握,而不必...

    基于ROS的移动机器人上层系统架构分析


      以后不会在CSDN更新了,欢迎关注知乎 楼上观光。链接: 基于ROS的移动机器人上层系统架构分析
      看过网上不少博客,介绍ROS系统架构的,基本上都是在介绍ROS自身系统架构,很少有介绍特定机器人的系统架构的。个人觉得,入门一个系统,首先需要从整体开始把握,而不必在意细节,整体把握好了,细节自然水到渠成。因此,本文以当下火热的移动机器人为载体,介绍移动机器人上层ROS系统架构,当然了,该架构也是参考了ROS BY EXAMPLE中Turtlebot,该书是个很适合入门的书,有空可以看看。
      图是最容易说明问题的,一张清晰的架构图,能够让你少走很多弯路,看了下面这张架构图,你就大概能知道,一个激光SLAM的移动机器人系统,究竟需要哪些模块,而这些模块之间的关系又是什么,使用哪些Topic进行交互。下面的架构图中都是核心模块,有时间每一个模块都需要去熟悉和学习。
    在这里插入图片描述
      ROS作为一个分布式架构,特点是低耦合,你可以随意的添加和删除模块,特别方便开发,但这种架构最大的问题是什么呢,进程交互速度慢,具有一定的延时,因此,这也是ROS饱受诟病的问题。
      移动机器人ROS架构里面最核心的部分,自然是建图、定位和路径规划,分别对应着图中的Gmapping、AMCL和Move_base。建图算法,在室内移动机器人中, gmapping必须拥有姓名。为什么这里画成虚线呢,因为建图不是每次都需要的,一次就可以了,无论你采用什么方法,只要环境变化不大,建出一张图,你就可以一直使用。以后,只需要启动AMCL算法,根据此地图,即可实现移动机器人的定位。AMCL采用粒子滤波,融合激光雷达话题/scan和下面提到的odom坐标系到base_link坐标系的变换,主要向tf树发布base_link坐标系到map坐标系的坐标变换。
      这里重点说说robot_pose_ekf节点,该节点通过扩展卡尔曼滤波器,融合/odom、/imu_data和/vo话题,实现更为精确的里程计先验,发布odom坐标系到base_link坐标系的变换。在我们自身的实际机器人架构中,/odom话题指四轮麦克纳轮解算出的里程计数据,没有采用视觉里程计,而是采用了测量轮加惯导生成的里程计数据代替/VO话题。大家一定要区分odom坐标系和/odom话题,这是两个概念,前者是坐标系,后者是根据编码器(或者视觉等)计算的里程计。
    下图清晰的表明了这一关系,/map到/odom的坐标变换为里程计的漂移,也就是说系统刚启动的时候里程计漂移为0,/map坐标系和/odom坐标系重合,而后来随着机器人的不断移动漂移越来越大,因为里程计是相对定位,具有累积误差。
    在这里插入图片描述
      Robot_state_publisher节点,解析URDF模型,向tf坐标树发布机器人各模块之间的坐标变换,如激光雷达位置相对于base_link的坐标变换。该坐标变换一方面是为了各模块之间的坐标系转换,同时也是为了在RVIZ中显示。该URDF模型可以手动编写,更方便的是用solidworks建模完成后进行导出。
      我们自身实现了一个Chassis_driver节点,该节点是需要自行编程并建立与下位机STM32之间的通信协议。该底层通信节点接收下位机的里程计数据并发布到话题/odom和/vo,同时接收move_base生成的速度,发送给下位机的STM32。
      而底层STM32控制器实现了怎样的功能呢?其一,将上层传递的速度指令解析成四个轮子的转速,下发给四个驱动器;其二,接收四个麦克纳姆轮的编码器数据,解析成轮式里程计数据,传给Chassis_driver节点。至于麦克纳姆轮的正逆解,可以参考下面: https://blog.csdn.net/qq413886183/article/details/78045515。当然了,现在有了ros_control,甚至可以将麦克纳姆轮正逆解也交到上层来做,直接控制电机驱动器即可。
      下面为我们实验室第一代自主搭建的机器人底盘以及跑出来的效果,可以看出机器人可以穿过房门并在走廊行驶。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
      这是本人的第一篇博客,旨在让新手入门ROS移动机器人,熟悉移动机器人整体架构,各模块之间是如何协同工作的,未涉及到具体的实现细节,对应各个模块的具体实现,可以参考roswiki官方,或网上的各种比较细节的教程,如有不足,请多多包涵。本人几年前就想写博客,一开始是想着做旅游博主的,给大家提供旅游攻略,但是一直拖着未能实现,希望以后有机会能补上。

    展开全文
  • ROV架构篇在这里:https://blog.csdn.net/zanran8/article/details/116331778?spm=1001.2014.3001.5501 上篇讲到,电子舱内部可分为,供电系统,通信系统,控制系统,并且对供电系统做了介绍。...

    ROV架构篇在这里:https://blog.csdn.net/zanran8/article/details/116331778?spm=1001.2014.3001.5501

    上篇讲到,电子舱内部可分为,供电系统通信系统控制系统,并且对供电系统做了介绍。(https://blog.csdn.net/zanran8/article/details/116922620?spm=1001.2014.3001.5501

    本篇介绍通信系统。通信系统主要是实现水下和岸上的通信。因为电磁波在水下衰减很严重,所以ROV的通信一般是有线的。ROV和岸上部分传输数据内容主要是视频图像,声呐图像,传感器数据,ROV信息等,考虑到传输的数据存在视频,所以对通信系统的带宽的要求是比较高的。常用的有可以分为几个模式。

    这种模式需要在ROV端放置一个工控机,其实就是一个电脑,树莓派也可。因为网络信号传输衰减也比较严重,网线芯数过多,所以一般采用将网络信号转换为电力载波信号传输。电力载波模块需要成对使用。

    这种模式好处是去除了工控机,水下部分直接和岸上电脑通信。

    这种模式和上一种是一样的,只不过在舱内的USB传输改成了网络传输。

    这种是完全使用光纤的,对于数据量大的需要,可以考虑这个方案,但是成本比较高。

     

    有几点小建议:

    1,建议使用USB摄像头,延迟小。

    2,一般的机器电力载波模块就已经足够使用了

    以上仅为个人浅见,如有错误,还请指正!

    有兴趣的小伙伴可以加一下QQ898023874,一起学习,共同进步!

     

    展开全文
  • #资源达人分享计划#
  • ROS架构ROS架构设计计算图节点消息话题服务节点管理器文件系统 ROS架构设计 三个层次:OS层、中间层、应用层 1、OS层: 并不是一个传统意义上的操作系统,需要依托于Linux系统(如Ubuntu、macOS、Arch等) 2、中间层...
  • ROS的通信架构是ROS的灵魂,也是整个ROS正常运行的关键所在。ROS通信架构包括各种数据的处理,进程的运行,消息的传递等等。本章主要介绍了通信架构的基础通信方式和相关概念。其中首先介绍了最小的进程单元节点Node...
  • 工业机器人控制系统的设计框架

    千次阅读 2021-07-07 20:37:57
    声明:本文为张晓辉博士在睿慕课开设的《工业机器人控制系统的设计》公开课学习笔记,版权归原作者及睿慕课所有,如有...( 03:04)2-4 数据通信模块 ( 03:50)第3章 控制系统软件架构3-1 基于PLCOpen的软件架构 ( 05
  • 分析了EtherCAT的通信协议,通过TwinCAT搭建了主站和从站,完成对六轴工业机器人的控制。根据D-H建模理论得到六轴工业机器人的模型,分析了六轴工业机器人的正运动学和逆运动学,并推导出逆运动学的解析解。通过雅可比...
  • ROS机器人操作系统(通信架构上)

    千次阅读 2018-11-21 22:20:28
    这就要利用ROS提供给我们的节点管理器master, master在整个网络通信架构里相当于管理中心,管理着各个node。node首先在master处进行注册,之后master会将该node纳入整个ROS程序中。node之间的通信也是先由master进行...
  • 基于系统的硬件架构,建立了绘图机器人的几何坐标系,通过对电机力矩及转速分析确立了绘图机器人的运动方程。所要绘制的目标图形经二值化、边缘细化、连续曲线检测等系列处理后转换为适合机器人执行的矢量图,下载至...
  • 语音机器人架构: STM32系统板<--UART-->庆科MiCOKit STM32系统板<--SPI-->LD3320语音模块 STM32系统板<--SPI-->SD卡 STM32系统板<--并口通信-->NOKIA5110液晶(这只是我调试用一下,所以...
  • 模仿人脸表情的高逼真机器人程序功能模块: OpenCV人脸识别 基于多级回归树的人脸关键点回归 基于SVM的人脸训练集表情分类识别 3D GUI显示 蓝牙通信用于连接硬件 模仿人脸表情的高逼真机器人视频演示: 模仿人脸表情的...
  • 文章目录一、软件架构设计的生命周期1. 软件开发流程2. 关于套路3. 先僵化,后优化,再固化4. 佛说:“知我说法,如筏喻者”二、需求调研和需求分析1. 功能需求2. 质量属性3. 条件约束4. 画用例图5. 写用例描述6. ...
  • SLAM+语音机器人DIY系列:(二)ROS入门——2.ROS系统整体架构 摘要 ROS机器人操作系统在机器人应用领域很流行,依托代码开源和模块间协作等特性,给机器人开发者带来了很大的方便。我们的机器人“miiboo”中的大...
  • EMC2是开源的数控机床控制系统软件。EMC2能移植到实时操作系统(例如ubuntu等)并根 据开发者定制完成复杂的机床和机器人实时控制。...对整个软件的架构通信机制,各模块的功能以及大致的工作流程进行深入分析。
  • 系列文章目录 提示:这里可以添加系列文章的所有文章的目录,目录需要自己手动添加 TODO:写完再整理 文章目录系列文章目录前言一、开发平台二、传感器系统1.无人驾驶车传感器配置2....通讯架构架构1:有M
  • 执行运算任务的进程,一个系统一般由多个节点组成,可以称为软件模块。 2话题和服务通信的异同点有哪些? 话题:异步,无反馈,更新快,逻辑弱,适合数据传输;发布/订阅 服务:同步,有反馈,更新慢,逻辑强,...
  • cv5200双向无线通信系统,基于802.11无线通信标准,采用自身开发的LR-WiFi(远距离WiFi)私有协议,具备ML,MRC,LDPC,MIMO-OFDM等高级无线技术。 具有传输距离远、可组网、抗干扰性强、超高灵敏度的
  • ROS通信架构(一) node: 最小的进程单元。一个软件包里有多个可执行文件,一个可执行文件在运行执行之后会变成一个进程,进程在ROS中就叫做node节点。从程序来看,node就是一个可执行文件(C++或Python脚本)被...
  • 学历要求:本科及以上学历,机器人、数学、计算机、通信或电子工程类相关专业 经验:3年以上 坐标:苏州或者上海 职位描述: 1、负责全覆盖路径机器人规划算法开发,包括:遍历路径规划,自主反充,分区处理,...
  • ROS通信架构及其弊端

    千次阅读 2019-06-29 11:27:45
    ROS通信架构及其弊端 严格来讲ROS并非是一种操作系统,它只是一种通信框架,一种基于消息传递通信的分布式多进程框架。ROS的主要组成包括ROS Mastar 、 ROS Node、ROS Service等。不同的功能可以由不同的节点实现,...
  • 机器人开发--Apollo ROS介绍

    千次阅读 2022-03-23 12:38:50
    机器人开发--Apollo ROS介绍1 介绍1.1 概述1.2 历程2 ROS的不足大数据传输性能瓶颈单中心的网络存在单点风险(ROS2为分布式避免该问题)数据格式缺乏向后兼容3 Apollo ROS的改进通信性能优化消息通信延时吞吐量CPU...
  • 机器人开发--OS系统介绍

    千次阅读 2022-03-07 20:46:35
    机器人开发--OS系统介绍1 概述2 各系统介绍华为--Huawei LiteOS鸿蒙谷歌--FuchsiaQNXFreeRTOSSylixOSRT-ThreadContikiμCOS-II/μCOS-IIIARM--ARMmbed微软--Windows 10 IoT阿里云--AliOS Things腾讯--TencentOS tiny...
  • 系列文章目录 提示:这里可以添加系列文章的...本文先对XXX做个简单的介绍,具体内容后续再更,其他模块可以参考去我其他文章 提示:以下是本篇文章正文内容 一、 1. 2. 3. 4. 二、 1. 2. 3. 4. 三、 1. 2. 3. 4. 四、
  • 4 ROS通信架构 4.1 启动master和node 4.1.1启动master : roscore 4.1.2 启动node : rosrun, roslaunch 4.1.3 rosnode命令 4.2 ROS的通信方式 4.2.1 Topic 4.2.2 Service 4.2.3 Parameter server 4.2.4 ...
  • 松灵机器人SCOUT的ROS代码架构

    千次阅读 2020-05-29 17:42:47
    首先惯例是吐槽,github上的readme太简略,照着他那个做会感觉一堆问题,尤其是在你使用usb转can模块后。正确的做法是git下来,看代码里面的readme,那里面会有详细的介绍,包括如何运行webots机器人仿真。 接下来是...
  • 文章目录目录部署架构 5 大要素1、性能2、可用性3、伸缩性4、扩展性5、安全性部署架构技术手段分布式系统架构横向分层纵向分割分布式集群缓存CDN 静态化数据异步冗余自动化安全 部署架构 5 大要素 一般说来,除了...
  • 远距离WiFi模组结合数据、图像采集模块,可以对目标对象进行数据采集及远距离传输通信,并广泛应用到智能安防、无人机等等领域。 智能cv5200双向无线通信系统,基于802.11无线通信标准,采用自身开发的LR-WiFi...
  • PR2 (Personal Robot 2, 个人机器人2)是威楼加拉吉生产的机器人。它的前身是斯坦福研究生埃里克·伯格和基南·威罗拜克开发的PR1机器人。PR2价格高昂,2011年零售价高达40万美元。PR2现主要用于研究。 PR2有两条手臂...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,114
精华内容 2,445
关键字:

机器人模块通信架构