3. CarMaker基础操作:项目结构、TestRun概念、驾驶场景编辑器、车辆模型选择

各位同学好,我是你们的老朋友。今天咱们来聊聊CarMaker的基础操作。说实话,我刚接触CarMaker那会儿,也被它那一套独特的概念搞得有点懵。什么项目结构、TestRun、场景编辑器……听着就头大。但别担心,我当年踩过的坑,今天帮你们一一填平。

这一章,我会带你把CarMaker的骨架摸清楚。说白了,就是搞懂它怎么组织文件、怎么跑一个测试、怎么画路、怎么选车。这些东西搞明白了,后面联合仿真才能玩得转。

3.1 项目结构:CarMaker的“文件夹哲学”

CarMaker的项目结构,其实没那么玄乎。它就是一个有规矩的文件夹系统。我个人习惯,每次新建项目前,都会先想清楚这个项目要测什么,然后严格按照它的目录结构来组织。

一个典型的CarMaker项目,根目录下通常长这样:

MyProject/
├── Data/
│   ├── Vehicle/        # 车辆模型数据
│   ├── Road/           # 道路数据
│   ├── Traffic/        # 交通参与者
│   └── Sensor/         # 传感器配置
├── TestRun/            # 测试用例(核心!)
├── Results/            # 仿真结果
├── Config/             # 项目配置文件
└── Scripts/            # 用户自定义脚本

嗯,这里要注意:TestRun文件夹是重中之重。你写的每一个测试场景,都放在这里。我见过不少新手,直接把文件乱丢,结果项目一复杂,自己都找不到东西。所以,从一开始就养成好习惯。

我的小技巧: 在项目根目录下,我通常会放一个README.txt,简单写一下这个项目是干嘛的、用了哪个车辆模型、测试目标是什么。别小看这个,半年后你回头看,会感谢自己的。

3.2 TestRun概念:一次测试的“身份证”

TestRun是什么?说白了,它就是一次仿真测试的完整定义。你想想看,一次测试需要什么?需要一辆车、一条路、一个驾驶任务、还有各种参数。TestRun就是把这些东西打包在一起的一个“文件夹”。

每个TestRun文件夹里,至少包含这几个文件:

  • TestRun.tpx:主文件,XML格式,记录了所有配置的索引。
  • Vehicle.vpe:车辆参数文件,定义了这辆车的物理特性。
  • Road.rd5:道路文件,定义了路有多宽、弯有多急。
  • Manoeuvre.mvr:驾驶动作文件,定义了车怎么开、什么时候刹车。

我在项目中遇到过一个问题:同事把TestRun复制了一份,改了名字,但忘了改里面的车辆参数。结果仿真结果完全对不上,排查了半天。所以,复制TestRun后,一定要检查里面的引用路径

避坑指南: 我曾经因为TestRun里的相对路径写错了,导致仿真一直报错“找不到车辆模型”。后来发现,是文件夹层级变了,但路径没更新。建议所有路径都使用相对路径,并且不要随意移动TestRun文件夹的位置。

3.3 驾驶场景编辑器:画路、摆车、设任务

驾驶场景编辑器,是CarMaker里我最喜欢的工具之一。它就像一个“交通沙盘”,你可以在这里画出任何你想要的场景。

打开编辑器,你会看到三个核心区域:

  • 道路编辑器:画路用的。可以画直线、曲线、十字路口、环岛。我习惯先画主干道,再画支路。
  • 交通流编辑器:设置其他车辆怎么走。可以设速度、跟车距离、变道逻辑。
  • 动作编辑器:定义主车(你的车)的驾驶任务。比如“加速到60km/h,然后保持车道”。

举个例子,你想测试AEB(自动紧急制动)功能。在场景编辑器里,你可以这样操作:

  1. 画一条笔直的道路。
  2. 在主车前方50米处,放一辆静止的障碍车。
  3. 设置主车以80km/h的速度直行。
  4. 保存场景,跑仿真。

是不是很简单?但要注意,场景的复杂度要循序渐进。我刚开始做的时候,总想一次搞个复杂的城市交通场景,结果调试起来特别痛苦。后来学乖了,先做最简单的直线场景,验证算法没问题了,再慢慢加车、加弯道。

核心要点: 场景编辑器的本质,是生成一个“剧本”。这个剧本告诉CarMaker:路长什么样、车在哪、车要干嘛。剧本写得越清晰,仿真结果越可靠。

3.4 车辆模型选择:选对车,仿真就成功了一半

CarMaker自带了不少车辆模型,从A级小车到重型卡车都有。怎么选?我一般看三个维度:

维度 说明 我的建议
动力学复杂度 从简单的“点质量模型”到复杂的“多体动力学模型” 做控制算法验证,用中等复杂度就够了;做底盘调校,必须用高保真模型
驱动形式 前驱、后驱、四驱 根据你的测试目标选。测ESP,后驱或四驱更合适
传感器配置 是否带雷达、摄像头、超声波 做ADAS功能,必须选带传感器的模型

我记得有一次,我为了省事,用了一个简单的点质量模型去验证车道保持算法。结果仿真跑得飞快,但算法到了实车上完全不行。为什么?因为点质量模型没有考虑轮胎的侧偏特性,转向响应太理想了。所以,选模型一定要匹配你的测试目的

另外,CarMaker允许你导入自己的车辆模型。如果你有CarSim或veDYNA的模型,也可以通过接口导入。但说实话,我建议初学者先用自带的模型。自带模型经过了充分验证,参数也调得比较合理,能帮你省去很多标定的时间。

一个小经验: 在项目初期,我会同时准备两个车辆模型:一个简单的用于快速迭代算法,一个高保真的用于最终验证。这样既保证了效率,又保证了精度。

3.5 知识体系总览

说了这么多,我画了一张图,帮你把这一章的核心逻辑串起来。你看完应该就明白了:

CarMaker基础操作 项目结构 Data/ Vehicle/ Road/ TestRun/ Results/ TestRun概念 .tpx / .vpe / .rd5 / .mvr 一次测试的完整定义 驾驶场景编辑器 道路 / 交通流 / 动作 画路、摆车、设任务 车辆模型选择 动力学复杂度 / 驱动形式 / 传感器配置 简单模型快速迭代 → 高保真模型最终验证

这张图你看懂了吗?从上到下,先搞清楚项目怎么组织,再理解TestRun是什么,然后学会用场景编辑器画场景,最后选一辆合适的车。这四个步骤,就是CarMaker基础操作的完整闭环。

好了,这一章的内容就到这里。记住,基础打牢了,后面联合仿真才能跑得顺。下次见!


专注资料整理