Skip to content

Latest commit

 

History

History
389 lines (259 loc) · 10.6 KB

README.md

File metadata and controls

389 lines (259 loc) · 10.6 KB

easy apollo

这个仓库由我于2023-12-25开始开发, 早期的软件版本依赖apollo 7.0, 完全使用cmake 编译,不再依赖docker. 开发这个仓库,期望可以一键安装和部署apollo,更容易使用

主要更新

  • 编译规则使用cmake;
  • 程序运行不再依赖docker,而是可以直接在ubuntu 18/20运行;
  • 适配c++17;
  • 增加快速碰撞检测系统,gjk/epa/bvh,由张玉博士、我在2019-2020年开发,可以参考(https://arxiv.org/abs/2011.09117), 可以将系统耗时2秒降低为20毫秒;
  • 增加2d的交互界面,用来实时调试系统状态;
  • 增加仿真底盘,用来测试决策规划控制;
  • 增加path decision调试工具;
  • 增加speed decision调试工具;
  • 增加record解析脚本;
  • 增加log文件解析脚本;
  • 通过cyber rt c++/python版本,实时订阅cyber 消息,并且完成解析,可以实时分析问题或者单步调试问题;
  • hmi可以自主添加障碍物,并且可以控制障碍物的运动状态;
  • hmi可以自主控制红绿灯,并且可以发布红绿灯;
  • 增加路由点的配置文件,自动化读取;
  • 跟车不使用单一的跟车距离,引入了st point of interest,来生成可变的可行驶区域;
  • 限速优化,限速构成的边界考虑到车辆速度,不然速度优化经常无解;
  • 修复routing lane change的bug;
  • 增加dream view plus(这个模块是apollo9.0引入的,不知道是不是没有配置正确,还不能正确显示系统状态);
  • 增加路由配置文件,自动在default_end_way_point.txt文件配置waypoint,自动读取并解析,生成route。

软件依赖

基本库:

  1. ubuntu 18.04/20.04 (不要尝试2204,各种编译不了的问题)
  2. eigen 3.3.7 (可以使用脚本安装)
  3. google test 1.10.0
  4. glog 0.50 (apt install)
  5. benchmark 1.6.0
  6. c++ 17
  7. cmake
  8. g++-9.4.0,ubuntu 1804默认是7.5.0,一定要使用9.4.0,不然很多库无法编译,除非在其他版本的gcc下面重新编译所有库
  9. gcc-9.4.0;
  10. git
  11. canlib,v5.43.47
  12. python,3.6, ubuntu 20.04是3.8,ubuntu 18.04是3.6,
  13. opengl

apollo 7.0依赖的库:

  1. protobuf (3.14,需要cmake 编译安装)

xxx.pb.h生成cmd:

protoc -I=cyber/proto/ --cpp_out=cyber/proto cyber/proto/*.proto
protoc -I=cyber/proto/ --python_out=cyber/proto cyber/proto/*.proto


cd src/
protoc -I=./ --cpp_out=./ ./modules/drivers/camera/proto/*.proto
protoc -I=./ --python_out=./ ./modules/canbus/proto/*.proto
protoc -I=./ --python_out=./ ./modules/common/proto/*.proto
protoc -I=./ --python_out=./ ./modules/planning/proto/math/*.proto
protoc -I=./ --python_out=./ ./modules/planning/proto/*.proto
protoc -I=./ --python_out=./ ./modules/map/proto/*.proto
protoc -I=./ --python_out=./ ./modules/map/relative_map/proto/*.proto
protoc -I=./ --python_out=./ ./modules/routing/proto/*.proto
protoc -I=./ --python_out=./ ./modules/dreamview/proto/*.proto
protoc -I=./ --python_out=./ ./modules/perception/proto/*.proto

protoc -I=./ --python_out=./ ./modules/drivers/gnss/proto/*.proto
protoc -I=./ --python_out=./ ./modules/localization/proto/*.proto
protoc -I=./ --python_out=./ ./modules/common/configs/proto/*.proto

protoc -I=./ --python_out=./ ./modules/control/proto/*.proto

  1. gflags,2.2

  2. tinyxml2

  3. boost (1.65), apt install

  4. osqp(下载gitee的库source code安装),apollo 8.0 默认使用osqp 0.5.0版本

  5. ipopt,3.11.9,need to apt install

  6. adolc,2.6.3(apt install)

  7. proj 5.0在third party中;本来想安装到third party中,名字是proj.so.13,编译可以通过,但是一运行就报错。 目前apt install 到/usr/,但是open cv4.2基于proj.so.15,所以,只需要安装opencv即可。

  8. openmp,ubuntu2204自带这个库

  9. opencv 4.2, 使用4.2会存在和proj4的链接冲突。源码安装4.2.0,opencv依赖gdal,gdal依赖proj4,所以,只需要安装opencv即可。

  10. torch,1.10.0测试,在ubuntu2004上可以编译,可以加载模型,可以使用静态库链接torch,simulator可以正常运行。

  11. ad_rss_lib,1.1.0

  12. protobuf,3.14

  13. fastrtps,1.5.0

  14. fast cdr,1.0.7

  15. abseil, 20200225.2

  16. json,3.8.0

  17. civetweb

  18. poco,1.9.0

  19. pcl

  20. yaml-cpp

  21. ncurses

  22. tf2,0.5.16

环境配置

  • 到github下载源码

  • 安装其他库


cd install_scripts

bash install_dependence.sh


  • 编译
mkdir build


<!-- 在easy_apollo 目录下,运行脚本文件 -->
./x86_compile.sh

  • 运行
cd build

./launch_simulator.sh

日志系统

日志系统参考了google log和apollo log的封装,可以非常简单的记录每一个模块的日志

参数模块

  • 使用protobuf格式作为参数,读取xxx.pb.txt文件即可;
  • 使用google flag参数,可以配置文件更改,可以作为环境变量更改,可以程序启动时做为后缀输入更改参数;

消息

apollo 7.0使用protobuf格式作为消息格式

HMI

目前可以选择的hmi包括:

  • opencv viz3d,维护者较少,不更新了,文档也少,但是代码结构清晰;
  • rviz依赖ros,不推荐;
  • open 3d,持续更新,有python版本,可以利用cyber rt开发一个python版本的hmi;
  • im gui,带gui的架构,但是对于显示系统状态来说有一点大了?
  • osg,古老的api,最近不更新;
  • opengl:比较原始,api少;
  • opencv,开发简单,但是只能2d显示,且不能旋转缩放;
  • pcl viz,文档多,持续更新,可以尝试;

暂时开发一个2d版本的hmi,等以后有时间开始尝试open3d python版本或者pcl viz,来搞一个3d的hmi,现在dreamview/drewview plus对于不熟悉前后端开发者太不友好了,想调试自己的系统状态非常需要一个轻量级的hmi!

  • speed planning debug tool: matplot

  • path planning debug tool: opencv

dreamview

基本架构

apollo轨迹规划的压力都在纵向这边,原因如下:

  • 因为横向对于动态障碍物几乎不考虑,静态障碍物几乎都nudge,存在安全性问题;
  • 障碍物原因的换道没有,只有route原因的换道,存在合理性问题;
  • 生成路径的时候,没有考虑速度,存在路径太平缓、转弯半径太小的问题,导致后续速度规划无解、横向加速度太大;
  • 没有考虑非完整性约束
  • 没有考虑横向舒适度约束,目前通过调整pwj-path优化器的平滑度来改善,实际上不同场景中很难调整参数;
  • 左右避障决策,只有简单的障碍物位置而来的决策,实际上对于横向决策而言,如果不经过路径搜索,很难一直得到一个满意的结果。

硬件依赖

  • 推荐计算单元配置:i7以上,32G内存,512G固态。
  • 输入can,usb转接
  • 输出can,usb转接
  • 定位串口,usb转接
  • 感知,以太网连接

实车

车辆行驶时,通过can 订阅底盘,通过can发送控制指令

启动系统:

cd build
./launch_real.sh

仿真

仿真包括:

  • 底盘虚拟仿真
  • 交通灯仿真
  • 障碍物仿真

仿真底盘是一个简单的仿真,不包含车辆动力学、摩擦力学,是简单的自行车模型,输入是自行车模型的 前轮转角、加速度,输出是前轮转角、速度、加速度、车辆朝向、车辆位置。该模型是零延时模型,意味着 在输入来临时,车辆可以立马达到输入状态,不存在任何延时。

仿真环境运行步骤:

cd build
./launch_simulator.sh

cyber rt

python 版本

cd easy_apollo/


source set_python_env.bash

cd build
source set_env.sh
cd ..


python3 src/cyber/python/cyber_py3/examples/talker.py 
python3 src/cyber/python/cyber_py3/examples/listener.py 

cpp版本


cd build
./test_talker
./test_listener

记录消息

自动驾驶系统的每一个消息,都可以记录

launch_record.sh

回放

打开build/launch_replay.sh 修改.record文件路径,输入你想要回放的文件,比如在 ./../data/log/20231122_15/20231122151401.record.00000路径.

打开global_flagfile.txt 修改replay参数 --replay_mode=true

然后运行:

#运行自动驾驶程序
launch_replay_apollo.sh

#运行播放程序
launch_replay.sh

replay时,可以加速、暂停、步进

编译

# source这一步需要优化
mkdir build

1. 方法一
cd build

cmake ..
make -j8
make install

2. 方法二,在easy_apollo 目录下,运行
./x86_compile.sh



调试

gdb调试一个单独的进程,需要输入gflag参数

cd build

source set_env.sh

gdb planning_component

run --vehicle_config_path=./../modules/common/data/vehicle_param.pb.txt --map_dir=./../data/sanhuan_back --flagfile=./../modules/common/data/global_flagfile.txt --smoother_config_filename=./../data/conf/planning/qp_spline_smoother_config.pb.txt

版本号

Apollo 7.0:

根据年份来设置版本号,例如2023.12

参考

  • lanelet2
  • apollo
  • opendrive
  • autoware
  • bullet
  • box2d
  • fcl

编程风格

  • 代码风格尽量使用google code style:

  • 尽量使用多进程编程,这样模块化比较清晰,并且能够隔离每个模块的数据。如果使用多线程编程,当一个模块挂掉的时候,所有模块都可能挂掉;

  • 每一个模块都有自己的内部实现和外部接口。为了给外部模块使用,所以写一个接口,比如xxx_module_interface.h;

  • 每一个模块尽量多写单元测试,这样可以找到一些明显的错误。而且,新手在阅读单元测试时,能够帮助新手快速入门。

  • 每次提交一个小功能,都需要提交git commit。不要将多个模块的改动,集合到一次commit之中。

  • git commit可以按照模板:

    # <类型>:(影响范围) <主题> <JIRA?>
    
    # <body>
    
    # <footer>
    
    # 类型字段包含:
    #     feat:新功能(feature)
    #     fix:修复bug
    #     doc:文档(documentation)
    #     style: 格式化 ESLint调整等(不影响代码运行的变动)
    #     refactor:重构(即不是新增功能,也不是修改bug的代码变动)
    #     test:增加测试
    # 影响范围:
    #     用于说明 commit 影响的范围,比如修改的登录页、账户中心页等
    # 主题:
    #    commit目的的简短描述,不超过50个字符
    # JIRA:
    #    如果有对应的jira 请附上jira号
    # Body 部分是对本次 commit 的详细描述,可以分成多行
    # Footer用来关闭 Issue或以BREAKING CHANGE开头,后面是对变动的描述、
    #       以及变动理由和迁移方法