Skip to content

Commit 49c94ea

Browse files
cassavacassava
committed
Add release notes for Cloe 0.20.0
1 parent 6836cae commit 49c94ea

File tree

4 files changed

+240
-15
lines changed

4 files changed

+240
-15
lines changed

‎docs/news.rst

+28
Original file line numberDiff line numberDiff line change
@@ -23,8 +23,36 @@ News
2323
:hidden:
2424
:maxdepth: 1
2525

26+
news/release-0.20.0
2627
news/release-0.19.0
2728

29+
:doc:`Version 0.20.0 Release <news/release-0.20.0>`
30+
---------------------------------------------------
31+
32+
This version includes several improvements to the simulator plugin for
33+
VTD and an update to the stack file format, among other smaller improvements.
34+
35+
The `vtd` simulator binding now has support for VTD 2022.3,
36+
OpenScenario files, and the `scp` action to send SCP messages from
37+
triggers.
38+
39+
You can now integrate custom vehicle dynamics models as Cloe
40+
plugins.
41+
42+
The stackfile schema format has been updated to support minor versions.
43+
44+
Triggers can have an `optional: true` field set to make them not fail
45+
when the action or event does not exist.
46+
47+
The fable library has been refactored and may require you to include
48+
`fable/schema/number_impl.hpp` or `fable/schema.hpp` for your code to keep
49+
compiling. Compile performance should be better though.
50+
51+
The tooling in the project has been updated for better compatibility with
52+
Conan 2.0 and packages that use more recent Conan features.
53+
54+
Read all about it :doc:`here <news/release-0.20.0>`.
55+
2856
:doc:`Version 0.19.0 Release <news/release-0.19.0>`
2957
---------------------------------------------------
3058

‎docs/news/release-0.19.0.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ This version contains some breaking changes in how the project is built.
44
It also contains improvements across the board. This post highlights some of
55
the more interesting changes.
66

7-
For the entire changelog, see the Git commit history.
7+
For the entire changelog, see the [Git commit history](https://github.com/eclipse/cloe/compare/v0.18.0...v0.19.0).
88

99
## Makefile Refactoring
1010

‎docs/news/release-0.19.1.md

-14
This file was deleted.

‎docs/news/release-0.20.0.md

+211
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,211 @@
1+
# Version 0.20.0 Release
2+
3+
This version includes several improvements to the simulator plugin for VTD
4+
and an update to the stack file format, among many other smaller improvements.
5+
6+
For the entire changelog, see the [Git commit history](https://github.com/eclipse/cloe/compare/v0.19.0...v0.20.0).
7+
8+
## VTD Simulator Plugin
9+
10+
TLDR: The `vtd` simulator binding now has support for VTD 2022.3,
11+
OpenScenario files, and the `scp` action to send SCP messages from
12+
triggers.
13+
14+
The `vtd` simulator binding now has support for
15+
[VTD 2022.3](https://mscsoftware.my.site.com/customers/s/article/Whats-New-VTD-2022-3)
16+
and using OpenScenario.
17+
18+
The simulator binding can now be built with *one* of the two VTD versions
19+
supported:
20+
21+
- VTD 2.2.0
22+
- VTD 2022.3
23+
24+
For this, the respective `vtd` and `vtd-api` Conan package needs to
25+
be available. These can be built from the `optional/vtd/vendor`
26+
folder, provided you have the corresponding sources.
27+
28+
Then, simply build the `cloe-plugin-vtd` package with the
29+
`vtd-api` dependency set to the version you want to use it with.
30+
31+
The `scp` action has been added, which lets you send SCP messages to VTD from
32+
a trigger:
33+
```json
34+
{
35+
"event": "time=5",
36+
"action": {
37+
"name": "vtd/scp",
38+
"xml": "<SimCtrl><Stop/></SimCtrl>"
39+
}
40+
}
41+
```
42+
43+
You can also define SCP templates in the `vtd` binding configuration:
44+
```yaml
45+
version: "4"
46+
defaults:
47+
simulators:
48+
binding: vtd
49+
args:
50+
scp_actions:
51+
simctrl: "<SimCtrl><[[cmd]]/></SimCtrl>"
52+
stop: >
53+
<SimCtrl>
54+
<Stop/>
55+
</SimCtrl>
56+
```
57+
This can then be used without arguments like so:
58+
```json
59+
{
60+
"event": "time=5",
61+
"action": "vtd/scp=stop"
62+
}
63+
```
64+
65+
Or with template arguments in the long form:
66+
```json
67+
{
68+
"event": "time=5",
69+
"action": {
70+
"name": "vtd/scp",
71+
"template": "simctrl",
72+
"data": {
73+
"cmd": "Stop"
74+
}
75+
}
76+
}
77+
```
78+
See the plugin {doc}`documentation <../reference/plugins/vtd>` for more details.
79+
80+
## Support for Vehicle Dynamics Model Integration
81+
82+
TLDR: You can now integrate custom vehicle dynamics models as Cloe
83+
plugins. The updated ego vehicle state will be sent to the `vtd` simulator, if
84+
configured accordingly.
85+
86+
A new interface `VehicleStateModel` has been added to `models`. This can be
87+
used as base class for custom vehicle dynamics model plugins. User models shall
88+
provide the updated ego vehicle state as `Object` type in every simulation
89+
cycle.
90+
91+
An additional interface `DriverRequest` has been added to pass requests from
92+
a driver model (built into the simulator or external) to a controller plugin.
93+
The `basic` controller has been extended to forward requests from the
94+
configured `DriverRequest` to the `actutator` component, in case no ADAS
95+
function is active. Albeit being a simplistic arbitration logic, this ensures
96+
that a custom vehicle dynamics model that reads from the `actuator` component
97+
will always receive a valid actuation request.
98+
99+
The `vtd` binding now supports sending the updated ego vehicle state from
100+
a custom vehicle dynamics model to the simulator. Driver steering and
101+
acceleration requests from the `vtd` driver model are received by the plugin.
102+
103+
## Stackfile 4.1
104+
105+
TLDR: The stackfile schema format has been updated to support minor versions.
106+
107+
That means for this version of the Cloe Engine, the following versions all mean
108+
the same thing: `4`, `4.0`, `4.1`. The default version is the *string* `4.1`:
109+
```json
110+
{
111+
"version": "4.1"
112+
}
113+
```
114+
If they are all compatible, you may wonder what the point is. The key phrase is
115+
"for this version of the engine". An older version of the engine will reject
116+
the stackfile, and the current version will reject a version that is newer
117+
than `4.1`. That means we can effectively specify the minimum stack file
118+
version required, if we need to be explicit. This follows the way that tools
119+
like `docker-compose` have managed versioning the input files.
120+
121+
If you don't care, just keep using the version `4`. Nothing will change for you.
122+
If on the other hand, you need to ensure that a recent version of Cloe is
123+
used, because you are using an added feature, then you should specify the
124+
minor version that introduced the feature you want to use, or simply the latest
125+
one.
126+
127+
Apart from validation, this has no other effect on parsing or the simulation.
128+
129+
## Optional Triggers
130+
131+
TLDR: Triggers can have an `optional: true` field set to make them not fail
132+
when the action or event does not exist.
133+
134+
This is the change that caused the stackfile to be updated and version bumped.
135+
136+
Nominally, triggers consist of an *event* and an *action*. There are several
137+
other fields that can be specified to modify specifics of how Cloe treats
138+
the trigger. The new `optional` field is false by default and specifies
139+
whether the trigger can be ignored if it cannot be constructed.
140+
141+
That is, if construction of a trigger fails because the specified event and/or
142+
action are not available, then a warning is printed instead of a simulation
143+
abort.
144+
145+
When is this useful, you may ask. When a controller plugin has actions that are
146+
generated by some code-generation routine that can be configured, then different
147+
configurations can result in a different set of actions. To support using the
148+
same trigger list with these different configurations, the "problematic"
149+
triggers can be made optional.
150+
151+
Since this is still not an optimal solution, warnings are still printed when
152+
a trigger is discarded like this.
153+
154+
## Fable Improvements
155+
156+
TLDR: The fable library has been refactored and may require you to include
157+
`fable/schema/number_impl.hpp` or `fable/schema.hpp` for your code to keep
158+
compiling. Compile performance should be better though.
159+
160+
There are these changes to the Fable library:
161+
162+
New:
163+
164+
- Add String schema `enum_of` method to specify valid values of string.
165+
- Add String schema unit tests to test all features.
166+
- Extend utility header `gtest.hpp` to support Schema type where previously
167+
only Confable type was supported.
168+
169+
Changed:
170+
171+
- Remove include of `fable/schema.hpp` in `fable/confable.hpp`.
172+
This allows better compile-time optimization but may require users to include
173+
`fable/schema.hpp` themselves.
174+
- Update example projects to use modern CMake commands in Makefile.
175+
- Update Conan test package test_v2_package to support
176+
`conan create .` outside of test package mode.
177+
178+
Performance:
179+
180+
- Extract String implementation from header.
181+
- Extract Boolean implementation from header.
182+
- Extract Number implementation from header.
183+
- If a user uses a Number with a non-standard numeric type, then they need to
184+
include `fable/schema/number_impl.hpp`
185+
186+
## Conan 2.0 Support
187+
188+
TLDR: The tooling in the project has been updated for better compatibility with
189+
Conan 2.0 and packages that use more recent Conan features.
190+
191+
These changes allow for the following, among other things:
192+
193+
Using standard CMake commands such as find_package() for dependency management.
194+
Use of multiple build types at the same time, such as Release and Debug.
195+
Relying on a single lockfile for CI, once Conan 2.0 is used.
196+
197+
## Smoketest Conanfiles
198+
199+
TLDR: Smoketest configurations are named `conanfile_default.py` instead of
200+
`profile_default.py` since the latter terminology conflicts with Conan.
201+
This change only really affects those developing on or with Cloe.
202+
203+
This version contains changes in how the test profiles are named since the
204+
original name was misleading.
205+
The files in question were all located in `tests/` directories alongside
206+
stackfiles and BATS tests and were previously named `profile_XYZ.py`.
207+
208+
Specifically, it was unclear when talking about the profile test files if the
209+
user wanted to refer about the conan profile instead. To avoid this confusion
210+
we decided to rename the files to a more understandable name: `conanfile_XYZ.py`.
211+
This makes clear that these are normal conanfiles.

0 commit comments

Comments
 (0)