压缩/解压
- tar 压缩
-
1
$ tar -zcvf dst.tar.gz /src-dir
- tar 解压
-
1
$ tar -xvf src.tar.gz
- zip 压缩
你永远流淌在我的记忆里?River flows in you
No results found
情况是这样的,在之前讲过的回播 .pcap 数据的 Velodyne_player 程序中,需要调用 Winpcap (其实就是 libpcap 的 Win挫版) 的 API 解析 .pcap 数据,再通过 UDP 发送出去。我们的 Velodyne_player 是一个 Win32 的程序,显然调用的就是32位的 Winpcap 库的 API; 后来我们也移植了一个 .pcap 采集程序的 Linux 版本,结果,用该 Linux 版本采集程序采集到的 .pcap 数据却没办法用我们 Win 下的 Velodyne_player 回播。后来发现,我们的 Linux 版本的采集程序用的是64位的 libpcap 库(因为系统是64位的 Ubuntu16.04,默认安装的就是64位的 libpcap 库),64位和32位的 libpcap,在时间戳上有很关键的区别,下面是开源的 pcap.h 中的声明:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17/*
* Generic per-packet information, as supplied by libpcap.
*
* The time stamp can and should be a "struct timeval", regardless of
* whether your system supports 32-bit tv_sec in "struct timeval",
* 64-bit tv_sec in "struct timeval", or both if it supports both 32-bit
* and 64-bit applications. The on-disk format of savefiles uses 32-bit
* tv_sec (and tv_usec); this structure is irrelevant to that. 32-bit
* and 64-bit versions of libpcap, even if they're on the same platform,
* should supply the appropriate version of "struct timeval", even if
* that's not what the underlying packet capture mechanism supplies.
*/
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};
SOCK_STREAM 面向连接 准确性/相对较慢 TCP
SOCK_DGRAM 无连接的传输方式 视频/音频 UDP
Server
1. 创建套接字 int sock = socket(AF_INET, SOCK_STREAM, 0);
2. 将套接字和IP、端口绑定 bind(sock, (struct sockaddr*)&serv_addr, sizeof(serv_addr));
3. 进入监听状态,等待客户端请求 listen(…);
accept(…);
4. 接受客户端数据/向客户端发送数据 read(…)/write(…);
5. 关闭套接字 close();
Client
1. 创建套接字
2. 向服务器(特定的IP和端口)发送请求 connect(…);
3. 读取服务器传回的数据/向服务器发送数据 read/write(sock, char*, sizeof(…));
4. 关闭套接字
从项目中一个实例说起,我们的目标是将决策层做出的控制小车的决策(主要是速度velocity还有角速度angular),通过TCP网络传输的方式传递到与控制小车的FPGA相连接的RaspberryPi。也许你会问,为毛要通过网络传输,不能通过其他方式,比如串口,不是会更快点吧?
Maybe…不过,这是有原因的。
其一,我觉得应该通过以太网线直接将运行决策的PC机网卡与树莓派上的网卡直接相连接,再用网络传输,应该比串口快,或者说,更稳定高效。遗憾的是,我们没办法通过以太网线直接相连,而是通过WiFi,这是因为,其二,PC机唯有的一个以太网卡,拿去插激光雷达了,而激光雷达作为一个sensor,是决策所必须的。
其三,整个体系运行在ROS之上,而,把ROS体系中做出来的决策送到控制端的树莓派上,我们得自己想办法或者说Coding。刚好,找到有一个开源的ros通讯,恰好人家是通过TCP传输的,所以,就没想那么多,直接用上了。
可想而知,这个开源的ros通讯要做的,就是把决策层做出来的velocity和angular,通过tcp传送到运行在树莓派上的程序进而控制FPGA控制小车。搞过ROS的应该知道,在ROS中节点都是通过消息进行通讯的,那么,这个ros通讯节点要做的肯定就是订阅决策层做出来的关于控制的消息,然后通过网络传输出去,这些,你可以阅读 这个开源项目 的源码进行了解。