回忆一下一年前的出差日记吧，那个时候真的是一点经验没有，干硬件又干软件，只能一步一步慢慢摸索，努力过后慢慢成长起来的吧。那个时候甚至开学了都没有正常报道，但是也收获了不少东西，并且也将作为我后来继续沿着科研顶峰攀登的契机。
出差日记
6.19
前一天和姜工联系好了，带上设备和电脑，主要包括8个毫米波雷达，1个惯导，两个相机。5点半启程从北门出发，前往机场。
到达新疆后，与宋老师会合。2点左右，买了吃的便前往农场，开始进行初步部署，整理相关设备，均能正常使用，没有损坏。整理个人在本次出差中的任务分配，其中，我负责：
1）实现对惯导、毫米波雷达等与域控制器的通信，包括惯导标定。
2）跟改装公司确定转向和其他按钮的线控准备，摸清电气规律，我们自己要掌握里面所有的细节
3）和姜工对接，让域控制器运转起来。
任务整体难度极大，没有经验实操的我只能先学习用户手册，摸清CAN通信的相关知识，理解can报文与相关基础知识；配置域控制器相关环境（与张老师沟通，不打算使用比赛用的，便在前一天迅速配置）；毫米波雷达与域控通信（1个，没有转接线，只能先用一个）；惯导标定看起来非常简单，但是无从下手，只能先学习怎么接收惯导信号。
6.20
上午正式配置域控和传感器的通信，先对相关连线进行处理，
下午整理采棉机的工作流程
6.21
与改装公司的人对接，摸清改装细节
下午测量相关信号并记录
6.22
数据测量的收尾，确定所有的改装方案，整理相关数据
6.23
主要是开会讨论之后的安排。
后面我的工作在于：
1.radar更改模式，并将改好模式了的雷达进行测量，看到底能不能实现、怎么实现目标级的识别。——购买can卡
2.多个radar之间如何进行信息融合与标定，没人做过毫米波，我也需要时间——买转接线
2.组合惯导的配置和初始化，怎么设置，设置哪些参数。能配置的东西很多，但是说明文档没有说清楚怎么配置——这个必须找刘志师兄了，需要给我讲配哪些，怎么配置。
3.组合惯导的数据解析。拿到正确的组合惯导数据，写解析文件
4.相机接入域控并拿到相关的数据话题，这里面的接口我来做
当然也有一些问题，组合惯导没有带回，我该怎么学习配置呢
(wo kao)
./install_for_noetic.sh
以上是我的第一次出差，什么都不是很懂呢！！！！
中间又去了一次，找不到记录了，那一次是进步最大的一次，我成功打通了所有环节，让采棉机能够实现循迹了，还是很开心的吧。但是我也意识到无人驾驶还是有很多的缺陷。然后来到了第三次出差的时候。
8.20
今天是前往兵团的日子，我们的飞机在9点半就要登机，于是我们7点多8点不到就到达了机场，但是很遗憾，天公不作美，不一会乌云密布，大雨滂沱。
于是开始看一些机器学习的概念。机器学习是一种通过从数据中学习模式和规律来使计算机系统具备学习和自适应能力的方法。它的主要目标是通过从数据中自动推断出模型，并利用这些模型来进行预测、分类、聚类等任务。
以下是机器学习的一般过程：
- 数据收集：首先，你需要收集与你的问题相关的数据。数据可以是结构化的（如表格数据）或非结构化的（如文本、图像、音频等）。数据的质量和多样性对机器学习的结果至关重要，因此要确保收集的数据具有代表性。
- 数据预处理：在进入模型训练之前，你需要对数据进行预处理。这包括去除噪声、处理缺失值、处理异常值，以及对数据进行归一化或标准化等操作。此外，你还可以进行特征选择和提取，以提取出对问题最有用的特征。
- 模型选择和训练：在选择模型之前，你需要确定问题的类型。根据问题的类型，你可以选择监督学习、无监督学习或强化学习等方法。选择合适的模型后，你需要将数据划分为训练集和测试集。然后，使用训练集来训练模型，通过调整模型的参数和优化算法来最小化预测误差。
- 模型评估：训练完成后，使用测试集来评估模型的性能。常见的评估指标包括准确率、精确率、召回率、F1 分数等。评估模型的性能有助于了解模型的泛化能力和预测能力，并帮助你判断模型是否满足需求。
- 模型优化和调参：如果模型的性能不理想，你可以尝试优化模型。这包括调整模型的超参数（如学习率、正则化参数等）、尝试不同的优化算法，或者尝试其他模型结构。通过反复实验和调整，你可以逐步改进模型的性能。
- 模型部署和应用：当你对模型满意后，可以将其部署到实际应用中。这可能涉及将模型集成到现有系统中，或者创建一个可以接收输入并生成预测输出的 API。在部署模型之后，你还需要进行监控和维护，以确保模型的稳定性和性能。
需要注意的是，机器学习是一个迭代的过程。你可能需要多次调整和改进模型，甚至重新回到数据收集和预处理阶段，以获取更好的结果。
一直等到下午6、7点，才陆续开始有飞机起飞。我们的飞机也在8点多开始登记，9点多顺利起飞，这一次延误还是让我学会了买机票要看一下天气。终于在凌晨2点半左右到达了酒店。收拾行李，检查设备，然后简单使用了一下打点仪，比思南的操作难度小很多，很快就能上手了。
8.21
第一天到兵团，车辆正常启动。但是基本还没有办法跑寻迹。以下是遇到的几个问题：
0.车辆手柄完全失效，vcu控制完全失效，测量电压也完全为0
排查所有的继电器和保险，但是无一断开。
下午重新来启动机器，发现一切恢复正常，除了采头落不下去。
1.车辆不能定位。(定位数据出现严重的延迟)
解析程序使用了调库(但是不是根本问题，我觉得直接调库中设置了45和现在的解析应该是差别不大的)
解决：把gps的上位机发送频率设置为50hz。再跑gps数据，可以正常显示一条直线了
2.规划算法完全跑不出来
解决：适应正确的规划顺序，多次校验不同点的情况，而且一直在改解析程序。最后下定决心，就先使用原有的解析规则。
当然，也带着连会在烈日下测量场地的数据。我很担心他受不了这样的环境。但是他并没有一点抱怨，真正做好了打点侠任务。(我以前都是只能自己干这样的活，还没看到一个没有一点抱怨，没有一点不情愿）
3.cpe连不上网
解决：刚充了600块钱，但是却发现那张卡没有办法在新疆等地区用。准备用自己的手机卡联网。
8.22
今天继续修改代码。
宋老师提出了一些改进的意见：我们要先确认一下定位、闭环控制以及通信。以上的问题，我觉得，不一定是线控执行的问题。
1）定位：人开车沿着目标轨迹走，看看CTE和dHead对不对。
2）闭环控制：如果把那个车轮转角从±38度约束到正负5度，看看还会不会乱走。这种失控，一个看控制参数是不是太激进了，另外，确认实时性有没有问题（因为print或者ros.login搞的程序算不过来了也有可能；或者控制器本身哪里状态不对了）；
3）看看我们的目标转角下发指令是不是及时的。
实测的定位点也找到了：
以这个位置做寻迹，走的是规划出来的直线。
看直线的寻迹数据，没有把+5变成38时，算的cte和dhead中dhead是有问题的，最后算出的方向盘角度变化也是比较大，100°以上了，正负的。
需要检查一下gps里的head和规划里面的航向有没有问题。
连会和我再多测试几组数据，总结规律。贾哥继续优化QT界面，刘博继续建模工作。也算是第一次发布任务，所幸大家都是毫无怨言的执行。
8.23
1.CPE问题确认出在卡上，用手机卡换上去是照常能用的，需要联系技术解决
2.寻迹上：规划的直线轨迹确认没有问题。确定了是gps的数据解析出现了问题(可能是从上位机到解析程序，都有改过一些东西），明天解决，复现7.31时的寻迹功能。
另外，明天要把launch写一版，一键启动写一版，向日葵装上。
直线过程的目标方向盘转角不对。
直线过程的GPS数据不对
后面遇到的问题：
寻迹功能已恢复(轨迹是规划的直线）。向日葵装好能用了。CPE现在用的自己的手机卡。
线控部分的接收程序依然是有问题的，换成两个dbc也不行，需要debug。反馈数据现在只能从原始can信号拿到。
上位机中惯导发送频率50hz
解析程序我小改过，重新换回去了，但不是根本原因。通信都没有动过，大概率是发送频率调小了。走之前应该是把它调成10hz了。
8.24
惯导上位机会有一些问题：
有时候rtk客户端不能正常登录，此时只能重启惯导了，不然就是卫导模式而不是组合惯导模式。
qt界面效果非常智能，贾哥非常专业了。后面我是一定会学习c++的。
gps解析分成两个msg发了，验证了没有问题。
线控的程序问题解决了，dbc文件的数据格式和msg冲突了，需要修改dbc文件。现在已能正常接收反馈的转角信号了。但是还没测试和比较目标和反馈的数据。
24号晚上，能转弯了，转弯误差最大在0.5m左右，直线误差在6cm左右。
8.25
一键启动基本实现。
界面框架基本搭建完成，接下来接入ros。
全局规划程序已验证，完成了一半。剩下完整轨迹的规划、通信相关测试。
线控部分，有几个信号数据格式是有问题的(未解决），现在直接注释掉了。今天测了3组寻迹数据，待处理。
8.26
今天测了三组数据，其后休息一天。
基本上也有了一些解决问题的思路，首先要吧路径从2/3增加到3/4，然后开始准备使用某种数据结构来直接寻找最近点，现在的二分法也是有一些bug的。
8.27
继续修改代码，上午修改，下午去实车测试。
同时这一阶段开始学习和使用其他的传感器，从zed2双目相机开始，到激光雷达，到毫米波雷达，大家基本只用了两天左右就掌握了数据处理部分，后面的算法开发也是完全没有问题。
车上的程序这一阶段调整不大。
同时，细读了域控制器的使用手册，学会了更多技能：
首先，使用的Orin芯片和单片机TC297，后面有机会一定要把单片机用起来（MCU(Micro Controller Unit) 芯片是一种微控制器芯片），传感器的接口：摄像头的gmsl2，雷达的以太网，CAN，串口通信，等等（注意到usb转rs232）。
挂载一个500G的磁盘：
然后：
sudo chown -R 用户名 /home/nvidia/Documents
对于其默认的库而言，主要有以下：
除了以上的内容之外，还有挺多新东西的，参照以下文件：
8.28
循迹问题，咱们分析数据后，用仿真复现这个现象，然后发展一版算法。现在的循迹效果，应该算是一个保底版本了。
同时改进了规划算法，从3变到了4转向非常的漂亮。继续配置相关的传感器。
8.29
1） 功能：一键启动，能够按照规划的路径运行，中间可以停车避障，循迹比较准确，具备初步的故障诊断功能（搜星、差分、组合导航、CAN通信丢失，等），通过GUI界面可以启动车辆、设定目标点，显示故障。改装组升级车辆线控系统的硬件。
2） 数据：车速、方向盘转角、车辆位姿（用于建模）， 全局规划的路径和棉花垄线的对应关系，以确认现在的方案能不能简单应用；采头触觉传感器的信号特征，模拟车辆采棉花，看这个信号什么特点，如何辅助循迹或者局部路径的修正。
以上任务已经具备大部分了。
8.30
在10月份，我们有没有可能，在开始的时候，多采集几个点，把地头的十来米打点打出来，后面就循迹？这些轨迹，我们可以放在一个EXCEL表格中，批量导入。
我们直接做精细化的路径采集，然后循迹。其实，采集这些路径，比收棉花效率高多了。我们用这种方式，先让采棉机可以用。然后，收集数据回来，做我们自己的感知、规划和控制的工作。
这是新的规划的想法。我其实并不支持，打点需要的资源人力还是比较大的。
以及拍摄全流程视频。
9.1
在开学的这一天我们依然坚守！明天宋老师他们就要过来了，我们的工作也基本完成了90%，其中使用的一键启动主要用到了.sh脚本+桌面快捷方式这两个关键功能。
首先是建立一个desktop：
cd /usr/share/applications
sudo gedit pycharm.desktop
里面需要加入的是：
[Desktop Entry]
Type=Application
Name=cotton start
GenericName= cotton start
Comment= cotton start
Exec=“/home/cyun/cotton_ws/src/self_start/cotton_one_step_start.sh” %f
Icon=/home/cyun/cotton_ws/src/self_start/ cotton_one_step_start.png
Terminal=pycharm
Categories=Pycharm;
(基本思路是这样)
第一版的启动脚本只有一个，但是我发现只使用一个会占用大量的空间，屏幕是看不了的。所有把1个脚本分成了两个：
# 规划程序
sleep 2s
gnome-terminal --tab --title=“Plan” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun planning global_path_planning.py; exec bash”
one_step_start1.sh：
sleep 1s
开roscore
gnome-terminal --tab --title=“roscore” – bash -c “source /opt/ros/noetic/setup.bash;roscore; exec bash”
开gps
sleep 1s
gnome-terminal --tab --title=“gps_imu_pub” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun perception gps_imu_pub.py ; exec bash”
sleep 2s
gnome-terminal --tab --title=“camera” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun usb_cam img_publisher ; exec bash”
# 开人机交互界面（点指令下发）
sleep 5s
gnome-terminal --tab --title=“Hmi” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun hmi hmi_node ; exec bash”
sleep 5s
gnome-terminal --tab --title=“fault_diagnosis” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun faultdiagnosis fault_diagnosis.py ; exec bash”
sleep 4s
gnome-terminal --tab --title=“radar” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; roslaunch pro_can radar_nodes.launch ; exec bash”
one_step_start2.sh：
# 控制
sleep 2s
gnome-terminal --tab --title=“Control” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun control path_speed_control.py; exec bash”
显示CTE等信息
sleep 2s
gnome-terminal --tab --title=“CTE_visual” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun control cte_visual.py; exec bash”
线控程序
sleep 5s
gnome-terminal --tab --title=“Wirecontrol” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;cd /home/nvidia/cotton_ws; rosrun wirecontrol wired_control.py ; exec bash”
sleep 4s
record
gnome-terminal --tab --title=“Recorder” – bash -c “cd /home/nvidia/cotton_ws;source devel/setup.bash;rosbag record -O /home/nvidia/Documents/database/$(date +%m-%d_%H-%M) -a;exec bash”
后面打算把一键功能和开机自启结合一下。
带着老师他们把现在的车上的算法过了一遍，
9.2
修改了几个规划的bug，同时开始进行算法的验证
修改了故障诊断算法，适配诊断的任务需要。
探索c++版的ros通信研究，主要包括一下部分：
首先是msg的建议，这个和之前的并没有区别，但是要注意后面不再是import，而是include实现，同时也不再支持一次include多个msg了。以下是需要的CMakeLists.txt：
cmake_minimum_required(VERSION 3.0.2)
project(car_interfaces)
Compile as C++11, supported in ROS Kinetic and newer
add_compile_options(-std=c++11)
Find catkin macros and libraries
if COMPONENTS list like find_package(catkin REQUIRED COMPONENTS xyz)
is used, also find other catkin packages
find_package(catkin REQUIRED COMPONENTS
message_generation
message_runtime
roscpp
rospy
std_msgs
)
add_message_files(
FILES
GlobalPathPlanningInterface.msg
GpsImuInterface.msg
)
generate_messages(
DEPENDENCIES
std_msgs
)
catkin_package(
INCLUDE_DIRS include
LIBRARIES car_interfaces
CATKIN_DEPENDS message_generation message_runtime roscpp rospy std_msgs
DEPENDS system_lib
)
include_directories(
include
${catkin_INCLUDE_DIRS}
)
Package.xml：
9.3
修改人机交互界面，最终版本的确定。
人机交互界面加入了视觉相机，相机的使用。发现了多个相机不适配控制器的问题，这个不容易解决，后面再看型号怎么办。
相机的话题发布：
#include <ros/ros.h>
#include <image_transport/image_transport.h>
#include <opencv2/highgui.hpp>
#include <opencv2/calib3d.hpp>
#include <cv_bridge/cv_bridge.h>
#include
int main(int argc, char** argv)
{
ros::init(argc, argv, “img_publisher”);
ros::NodeHandle nh;
image_transport::ImageTransport it(nh);
image_transport::Publisher pub = it.advertise(“camera/image”, 1);
cv::VideoCapture cap;
cv::Mat frame;
int deviceID=0;
if(argc>1)
deviceID=argv[1][0]-‘0’;
int apiID=cv::CAP_ANY;
cap.open(deviceID+apiID);
if(!cap.isOpened()){
std::cerr<<“ERROR! Unable to open camera”<<std::endl;
return -1;
}
ros::Rate loop_rate(30);
while (nh.ok()) {
cap.read(frame);
if(!frame.empty()){
sensor_msgs::ImagePtr msg = cv_bridge::CvImage(std_msgs::Header(), “bgr8”, frame).toImageMsg();
pub.publish(msg);
}
ros::spinOnce();
loop_rate.sleep();
}
return 0;
}
这是之后的目标
1.把这个结构给完全理解并深入掌握
2.按照相应的规则重新写线程
9.4
最后的一天，主要内容是拍摄相关的纪录片，对于我来说，感受还是挺深的。其实是一个关于倒计时的故事。赶在老师到来前，日夜的调试，实现了既定目标90％，不成熟是肯定的。看到我们团队的同学顶着烈日采集重要数据毫无抱怨，看到我们设计的算法跑在祖国的北疆大地上，看到我们的成果受到肯定，还是很高兴的。
整个团队中，从改装组的吕工，硬件的黄工和线控的小姜工，以及安装工作的姜工等，从他们那学到了很多的知识，专业性非常强。同时还有和我一起出差的小伙伴们，能够一起坚持下来。
