Releases: tier4/scenario_simulator_v2
7.4.4
Description
Abstract
The package concealer code was refactored. (continuation of #1488.)
Background
See #1488 description.
Details
Reducing Member Functions
Several member functions were removed for the same purpose as in #1488. Below is the background and policy for this as described in #1488.
Member functions that are only used by certain member functions have been changed to function local functions. Making them private member functions was also an option, but we decided not to do so. Based on our experience in maintenance over the past few years, the cost of understanding where a certain member function is being called from is a burden both in terms of code modification and code review. This is just a matter of preference. I don't mind changing function-local functions to private member functions at some point, so I'm doing it this way for now to make refactoring following this pull request easier.
References
Destructive Changes
None.
Known Limitations
None.
Related Issues
7.4.3
Description
The following function in traffic_light_base.cpp
is quite heavy because it always tries adding traffic light even when the traffic light has been registered in simulator.
auto TrafficLightsBase::getTrafficLight(const lanelet::Id traffic_light_id) -> TrafficLight &
{
addTrafficLight(traffic_light_id);
return traffic_lights_map_.at(traffic_light_id);
}
As a result, it becomes a bottle neck of simulator when I write a code to update traffic light color frequently.
Abstract
I added the guard to prevent redundant process like this:
diff --git a/simulation/traffic_simulator/src/traffic_lights/traffic_lights_base.cpp b/simulation/traffic_simulator/src/traffic_lights/traffic_lights_base.cpp
index 48110784a..906e80258 100644
--- a/simulation/traffic_simulator/src/traffic_lights/traffic_lights_base.cpp
+++ b/simulation/traffic_simulator/src/traffic_lights/traffic_lights_base.cpp
@@ -123,6 +123,10 @@ auto TrafficLightsBase::addTrafficLight(const lanelet::Id traffic_light_id) -> v
auto TrafficLightsBase::getTrafficLight(const lanelet::Id traffic_light_id) -> TrafficLight &
{
+ if (isTrafficLightAdded(traffic_light_id)) {
+ return traffic_lights_map_.at(traffic_light_id);
+ }
+
addTrafficLight(traffic_light_id);
return traffic_lights_map_.at(traffic_light_id);
}
Background
N/A
Details
With this PR, I confirmed the process load became light.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.4.2
Description
Abstract
Updated the rviz config file based on autoware.rviz to display the latest Rviz plugin used by Autoware developers.
However, some modifications have been made so as not to disrupt the appearance of the previous scenario_simulator_v2 Rviz.
Background
Continuation of #1349
References
Destructive Changes
This is a destructive change for rviz config file.
But, there are no effects for simulation and autoware behaviors even if some rviz plugins are missing.
Known Limitations
None
Related Issues
7.4.1
Description
Abstract
catch common::SemanticError
inside traffic_simulator::pose::canonicalize
function.
Background
In #1266 the CanonicalizedLaneletPose::canonicalize
function is now used in the constructor of the CanonicalizedLaneletPose
class.
CanonicalizedLaneletPose
class is used inside traffic_simulator::pose::canonicalize
function.
The traffic_simulator::pose::canonicalize
function has a return value of type std::optional and must return std::nullopt if it is used for lane coordinate system calculation, but CanonicalizedLaneletPose ::canonicalize
function throws common::SemanticError
in case of failure of lane coordinate system calculation, so if std::nullopt is expected as a return value, an exception is raised and the simulation stops.
Details
catch common::SemanticError
inside traffic_simulator::pose::canonicalize
function.
Unit tests run on the source code of this commit hash will output the following error and fail.
- test_pose
<<< failure message
-- run_test.py: invoking following command in '/home/user/workspace/pilot-auto.x2/build/traffic_simulator/test/src/utils':
- /home/user/workspace/pilot-auto.x2/build/traffic_simulator/test/src/utils/test_pose --gtest_output=xml:/home/user/workspace/pilot-auto.x2/build/traffic_simulator/test_results/traffic_simulator/test_pose.gtest.xml
[==========] Running 44 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 6 tests from pose
[ RUN ] pose.quietNaNPose
[ OK ] pose.quietNaNPose (0 ms)
[ RUN ] pose.quietNaNLaneletPose
[ OK ] pose.quietNaNLaneletPose (0 ms)
[ RUN ] pose.transformRelativePoseToGlobal
[ OK ] pose.transformRelativePoseToGlobal (0 ms)
[ RUN ] pose.relativePose_poses_zero
[ OK ] pose.relativePose_poses_zero (0 ms)
[ RUN ] pose.relativePose_poses_zeros
[ OK ] pose.relativePose_poses_zeros (0 ms)
[ RUN ] pose.relativePose_poses_complex
[ OK ] pose.relativePose_poses_complex (0 ms)
[----------] 6 tests from pose (0 ms total)
[----------] 38 tests from PoseTest
[ RUN ] PoseTest.canonicalize_default
[ OK ] PoseTest.canonicalize_default (8 ms)
[ RUN ] PoseTest.canonicalize_invalid
unknown file: Failure
C++ exception with description "/home/user/workspace/pilot-auto.x2/src/simulator/scenario_simulator/simulation/traffic_simulator/src/data_type/lanelet_pose.cpp:81: Lanelet pose (id=203,s=1000,offset=0,rpy.x=0,rpy.y=0,rpy.z=0) is invalid, please check lanelet length and connection." thrown in the test body.
[ FAILED ] PoseTest.canonicalize_invalid (7 ms)
[ RUN ] PoseTest.canonicalize_valid
[ OK ] PoseTest.canonicalize_valid (7 ms)
[ RUN ] PoseTest.toMapPose_CanonicalizedLaneletPose
[ OK ] PoseTest.toMapPose_CanonicalizedLaneletPose (6 ms)
[ RUN ] PoseTest.toMapPose_LaneletPose
[ OK ] PoseTest.toMapPose_LaneletPose (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_valid
[ OK ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_valid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_invalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_noBoundingBox_noRoute_invalid (6 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_valid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_valid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_invalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_noRoute_invalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyInvalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyInvalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyValid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_emptyValid (6 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyInvalid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyInvalid (7 ms)
[ RUN ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyValid
[ OK ] PoseTest.toCanonicalizedLaneletPose_BoundingBox_route_nonEmptyValid (7 ms)
[ RUN ] PoseTest.relativePose_canonicalized_end_position
[ OK ] PoseTest.relativePose_canonicalized_end_position (6 ms)
[ RUN ] PoseTest.relativePose_canonicalized_start_position
[ OK ] PoseTest.relativePose_canonicalized_start_position (7 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_disjoint
[ OK ] PoseTest.boundingBoxRelativePose_disjoint (6 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_commonEdge
[ OK ] PoseTest.boundingBoxRelativePose_commonEdge (7 ms)
[ RUN ] PoseTest.boundingBoxRelativePose_intersect
[ OK ] PoseTest.boundingBoxRelativePose_intersect (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_s_invalid
[ OK ] PoseTest.relativeLaneletPose_s_invalid (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_s_valid
[ OK ] PoseTest.relativeLaneletPose_s_valid (7 ms)
[ RUN ] PoseTest.relativeLaneletPose_offset_invalid
[ OK ] PoseTest.relativeLaneletPose_offset_invalid (6 ms)
[ RUN ] PoseTest.relativeLaneletPose_offset_valid
[ OK ] PoseTest.relativeLaneletPose_offset_valid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_s_invalid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_s_invalid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_s_valid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_s_valid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_offset_invalid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_offset_invalid (7 ms)
[ RUN ] PoseTest.boundingBoxRelativeLaneletPose_offset_valid
[ OK ] PoseTest.boundingBoxRelativeLaneletPose_offset_valid (6 ms)
[ RUN ] PoseTest.isInLanelet_inside
[ OK ] PoseTest.isInLanelet_inside (8 ms)
[ RUN ] PoseTest.isInLanelet_outsideFrontFar
[ OK ] PoseTest.isInLanelet_outsideFrontFar (7 ms)
[ RUN ] PoseTest.isInLanelet_outsideFrontClose
[ OK ] PoseTest.isInLanelet_outsideFrontClose (6 ms)
[ RUN ] PoseTest.isInLanelet_outsideBackFar
[ OK ] PoseTest.isInLanelet_outsideBackFar (8 ms)
[ RUN ] PoseTest.isInLanelet_outsideBackClose
[ OK ] PoseTest.isInLanelet_outsideBackClose (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_noFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_noFollowing_within (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_singleFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_singleFollowing_within (6 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_singleFollowing_outside
[ OK ] PoseTest.isAtEndOfLanelets_singleFollowing_outside (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_multipleFollowing_within
[ OK ] PoseTest.isAtEndOfLanelets_multipleFollowing_within (7 ms)
[ RUN ] PoseTest.isAtEndOfLanelets_multipleFollowing_outside
[ OK ] PoseTest.isAtEndOfLanelets_multipleFollowing_outside (7 ms)
[ RUN ] PoseTest.laneletLength_invalid
[ OK ] PoseTest.laneletLength_invalid (7 ms)
[ RUN ] PoseTest.laneletLength_valid
[ OK ] PoseTest.laneletLength_valid (7 ms)
[----------] 38 tests from PoseTest (260 ms total)
[----------] Global test environment tear-down
[==========] 44 tests from 2 test suites ran. (260 ms total)
[ PASSED ] 43 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] PoseTest.canonicalize_invalid
References
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.4.0
Abstract
This PR contains the continuation of #1443
Details
- There is no longer
lanelet::Id
passed into TrafficSink, but anoptional<lanelet::Id>
. It is still used solely for the purpose of visualization, wherenullopt
means that the sink was placed too far from the lane. Resigning from passinglanelet::Id
altogether turned out to be problematic, because ends of multiple lanelets overlap and the corresponding lanelet could not be determined. - Additionally I would like to propose an alternative approach to the
set sinkable_entity_types
variable. - I have removed the special case
if sinkable_entity_types is empty, then all entities should sink
. In my opinion it could be misleading (someone could pass emptysinkable_entity_types
and expect that no sinking behavior will occur). Now if we want to sink all entities, we need to provide the full setsinkable_entity_types
. - I have removed the
bool auto_sink
variable, which could be equivalent tosinkable_entity_types.empty()
with this approach. - The default behavior is
sinkable_entity_types = {}
, that is no auto sinks are generated.
References
Related Issues
7.3.5
Description
Abstract
The package concealer
code was refactored.
Background
The code of the package concealer
has been modified without any refactoring since its creation until today. This is not due to technical reasons, but simply because there was no opportunity. However, now that the merge of #1454 has been completed, I thought it was a good opportunity to refactor it.
Details
As the title suggests, I plan to refactor concealer
in several stages. The purpose of this pull request is to first make the code more compact without making any functional changes.
Base Class Autoware
When I designed concealer
, I was struggling with the need to support three different Autoware flavors in scenario_simulator_v2: Autoware.AI, Autoware.T4B, and AutowareArchitectureProposal. The structure of the base class Autoware
and its derived class AutowareUniverse
is based on the assumption that Autoware with an architecture different from Autoware.Universe will appear. However, in reality, no such different type of Autoware has appeared since the emergence of Autoware.Universe. This could be interpreted as just a coincidence that it has not appeared until now, but it is also true that the code is bulky due to this structure, so for the time being, I deleted the base class and simplified the code.
Reducing Member Functions
Member functions that are only used by certain member functions have been changed to function local functions. Making them private member functions was also an option, but we decided not to do so. Based on our experience in maintenance over the past few years, the cost of understanding where a certain member function is being called from is a burden both in terms of code modification and code review. This is just a matter of preference. I don't mind changing function-local functions to private member functions at some point, so I'm doing it this way for now to make refactoring following this pull request easier.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
7.3.4
Description
Abstract
Add auto HdMapUtils::isInIntersection(const lanelet::Id lanelet_id) const -> bool
function.
Background
In the current master branch implementation, there was no function to determine if a lanelet is a lanelet at an intersection.
Details
Since it was found that lanelets included in an intersection have an attribute called turn_direction
, it was decided to make a judgment based on this attribute.
The use of intersection_area
polygon was also suggested, but the condition is that intersection in lanelet2 means
turn_direction, and polygon(intersection_area) is the polygon that is responsible for setting the area. Therefore, we decided to use the presence or absence of
turn_direction` as a condition for judgment.
Lanelet outside intersection.
Lanelet inside intersection.
References
Internal link.
Document about lanelet2(Japanese)
Document about lanelet2(English)
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.3.3
Description
Abstract
Merge SpellCheckAll
and SpellCheck
workflow.
Background
SpellCheckAll and SpellCheck do almost same thing.
Details
Merge SpellCheckAll
and SpellCheck
workflow.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
7.3.2
Description
Arm64 CI was broken, so remove it temporarily.
Abstract
Remove ARM64 CI.
Background
Arm64 CI was broken, so remove it temporarily.
Details
Remove arm64 CI from matrix.
strategy:
matrix:
rosdistro: [humble]
# arch: [amd64, arm64]
arch: [amd64]
References
N/A
Destructive Changes
N/A
Known Limitations
N/A