Releases: tier4/scenario_simulator_v2
9.4.0
Description
Abstract
Support message type autoware_internal_planning_msgs::msg::PathWithLaneId.
Background
From Pilot.Auto 0.41.0, autoware_internal_planning_msgs has been added. Due to the addition of this message type, tier4_planning_msgs::msg::PathWithLaneId will be replaced by autoware_internal_planning_msgs::msg::PathWithLaneId from Pilot.Auto 0.41.1 onwards. In other words, Pilot.Auto 0.41.0 is a version to give time for the message type change, and while tier4_planning_msgs::msg::PathWithLaneId and autoware_internal_planning_msgs::msg::PathWithLaneId coexist, tier4_planning_msgs::msg::PathWithLaneId is the one that is used.
To accommodate this change, scenario_simulator_v2 needs to support both message types and be able to switch which one to use. This pull request does this.
Details
The current default architecture_type is awf/unvierse/20240605 and this pull request does not change it. (We need to consider how to manage the default architecture_type in the future.)
- If
architecture_typeisawf/universe/20250130or later,autoware_internal_planning_msgs::msg::PathWithLaneIdsubscribers are instantiated. - Otherwise,
tier4_planning_msgs::msg::PathWithLaneIdsubscribers are instantiated.
To achieve the above switch, the class template Subscriber has been updated, and some auxiliary class templates have been added for it.
References
None.
Destructive Changes
None.
Known Limitations
None.
Related Issues
9.3.1
Description
Abstract
This pull-request is deleting unnecessary target branch filter in workflow trigger
Background
When adding new features or refactorings that require multiple pull requests, the target branch is often set to something other than master.
There is no reason to exclude such cases from CI.
Details
This pull-request does not change any code.
So, no regression tests are executed.
The workflows below are not fixed because it makes sense to narrow down the target branch to master.
- .github/workflows/CheckBranchUpToDate.yaml
- .github/workflows/CheckLabel.yaml
- .github/workflows/Release.yaml
References
None
Destructive Changes
None
Known Limitations
None
Related Issues
9.3.0
Description
Abstract
Add docker image for traffic_simulator.
Background
The Docker Image of scenario_simulator_v2 is currently 13.6 GB following the humble-9.1.0 version.
Therefore, the size of the Docker Image was very large when trying to develop an application using scenario_simulator_v2.
Details
Additional Docker Image including only traffic_simulator and its dependent packages.
References
N/A
Destructive Changes
N/A
Known Limitations
N/A
Related Issues
9.2.0
Description
Abstract
This pull request introduces a fix for lanelet slope inaccuracies in the FollowTrajectoryAction and WalkStraightAction.
Details
In the case of FollowTrajectoryAction and WalkStraightAction, an issue arises in the algorithm responsible for determining the entity's position. During each simulation step, displacement is calculated based on the velocity vector and step_time. When the entity moves along a sloped lanelet (e.g., driving uphill), the calculated displacement can sometimes exceed the remaining distance to the end of the lanelet.
To address transitions between lanelets, the method CanonicalizedLaneletPose::adjustOrientationAndOzPosition adjusts the entity's orientation to match the lanelet's pitch angle and sets the entity's height to the lanelet's elevation. As a result, the cumulative displacement computed by the makeUpdatedStatus function may not always reflect the actual distance traveled.
The proposed solution involves checking the remaining distance to the end of the current lanelet. If the calculated displacement exceeds this distance, the entity's position is updated to the next lanelet in a controlled manner. This ensures accurate positioning and smooth transitions between lanelets.
Code Changes
Pose
- The
updatePositionForLaneletTransitionfunction accounts for cases where the entity reaches the end of the current lanelet and needs to transition to the next lanelet. Link
Follow Trajectory Action
- The
makeUpdatedStatusmethod has been updated to fix issues. Link
Walk Straight Action
- The method
ActionNode::calculateUpdatedEntityStatusInWorldFramehas been modified to fix the issue withWalkStraightAction. It updates the position and orientation of the entity, ensuring precise movement along the lanelet and accurate handling of transitions between lanelets. Link.
New Vector and Quaternion Operations
-
Added function to calculate the norm of a quaternion. Link
-
Added function to normalize a quaternion. Link
-
An operator overload for the + operator was added to facilitate vector addition. This allows combining custom vector types with Eigen::Vector3d seamlessly. Link
References
Internal link 1
Internal link 2
Destructive Changes
--
Known Limitations
--
Related Issues
9.1.0
Description
NPC should detect another Entity with see_around even when the Entity does not overlap the center line of the lane which the NPC is on. This change allows to detect another NPC which overlap path of this NPC.
Abstract
This PR changes detection function of front entity in ActionNode.
Details
I've changed getDistanceToTargetEntityPolygon to use boundingBoxRelativeLaneletPose. It calculates relative pose between current NPC and another one. If absolute value of offset is less than half of NPC width it means that it intersects with current NPC path. If so distance to front entity is s of the pose enlarged by half of the length of NPC, as we need distance from the center.
Destructive Changes
--
Known Limitations
--
Related Issues
9.0.3
Description
Abstract
This pull request introduces a fix for sign of slope acceleration when consider_acceleration_by_road_slope is set to true.
Details
When consider_acceleration_by_road_slope was set to true some scenarios were failing.
This was primarily because of wrong calculation of actual acceleration, slope acceleration sign was sometimes changed by multiplying it by gear sign, when slope acceleration value was already properly signed.
Second problem was CanonicalizedEntityStatus::getLaneletPose method throwing exception because slope acceleration was tried to calculate even when lane matching was not successful. This was fixed by checking lane matching before slope acceleration is calculated, and removing noexcept operator.
Code Changes
EgoEntitySimulation
- slope acceleration was moved out of the bracket as the slope acceleration is already a signed value and there is no need to multiply it by gear sign
- check lane matching status to avoid exception when not and to provide slope acceleration when information of actual lanelet slope is obtained
CanonicalizedEntityStatus
noexceptwas removed fromgetLaneletIdandgetLaneletPoseas those two methods can actually throwcommon::SemanticError
References
Destructive Changes
--
Known Limitations
--
Related Issues
9.0.2
Description
Abstract
This pull-request is updating actions/upload-artifact from v3 to v4 in Documentation.yaml
Background
Since January 30th, actions/upload-artifact@v3 was no longer be able to use and preffered to use v4.
https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/
Details
None
References
The fixed workflow works fine!
https://github.com/tier4/scenario_simulator_v2/actions/runs/13064313151/job/36453875184?pr=1520
Destructive Changes
None
Known Limitations
None
Related Issues
9.0.1
Description
Abstract
porting autowarefoundation/autoware.universe#10030.
use vel state for acc state calculation of SimModelDelaySteerVel
Background
fix the scenario fails in https://tier4.atlassian.net/browse/RT1-9039
this caused by introducing acc condtion
96/98(2025/01/14) -> 64/98(2025/01/15) (degraded!!)
Details
Currently, the vel input control is used to calculate the acc state. However, the input values can fluctuate, sometimes resulting in a large acc state.
In this PR, I’ve changed the calculation method so that the acc state is now based on the vel state, which is computed using a first-order lag filter.
before
after
References
How was this PR tested?
-
print the acc value in scenario simulator v2
-
96/98(2025/01/14) -> 64/98(2025/01/15) (degraded!! introduce acc fail condition) ->
96/98 (2025/01/28 (with #1516)
Destructive Changes
Known Limitations
Related Issues
9.0.0
Description
Abstract
This pull request introduces the change of exposing direct access to Entity objects through the API. This change increases flexibility of using the API and removes the need to have many forwarding functions to Entities member functions.
Background
This pull request is one of many that aim to modularize the scenario_simulator_v2.
The main goal of this PR was to remove numerous member functions of EntityManager (and subsequently some of API too) that forwarded calls to Entities member functions:
https://github.com/tier4/scenario_simulator_v2/blob/0dbf4ec0e573372306716f8d77933891564b36d6/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp#L162-L216
This has largely been achieved by exposing direct access to Entity and its member functions through the API::getEntity function:
https://github.com/tier4/scenario_simulator_v2/blob/8940b3e2f127bbca92295a91d580887030e45be6/simulation/traffic_simulator/include/traffic_simulator/api/api.hpp#L303
The following change was to adjust all cpp mock scenarios to use the new interface.
This is the main reason why this PR is so large - all mock scenarios had to be corrected.
Scenarios using the new interface have been changed similarly to the example below.
Before:
https://github.com/tier4/scenario_simulator_v2/blob/0dbf4ec0e573372306716f8d77933891564b36d6/mock/cpp_mock_scenarios/src/follow_lane/acquire_position_in_world_frame.cpp#L41-L64
After:
https://github.com/tier4/scenario_simulator_v2/blob/8940b3e2f127bbca92295a91d580887030e45be6/mock/cpp_mock_scenarios/src/follow_lane/acquire_position_in_world_frame.cpp#L41-L64
Similar changes had to be applied to the whole codebase relying on the API like simulator_core.hpp.
What is more, EgoEntity has been modified in such a way, that the function
https://github.com/tier4/scenario_simulator_v2/blob/0dbf4ec0e573372306716f8d77933891564b36d6/simulation/traffic_simulator/include/traffic_simulator/entity/ego_entity.hpp#L68
has been replaced with a set of other functions below:
https://github.com/tier4/scenario_simulator_v2/blob/8940b3e2f127bbca92295a91d580887030e45be6/simulation/traffic_simulator/include/traffic_simulator/entity/ego_entity.hpp#L155-L164
This change simplifies the interface of calling Ego specific actions like engage or sendCooperateCommand.
Details
Below are the detailed interface changes that have been made to EntityStatus, EntityBase, EntityManager and the API.
EntityStatus
- Renamed
laneMatchingSucceedtoisInLanelet:
auto laneMatchingSucceed() const noexcept -> bool;
->
auto isInLanelet() const noexcept -> bool;
EntityBase
-
Removed forwarded using macro to
EntityStatus:laneMatchingSucceed:
laneMatchingSucceed -
Removed
asFieldOperatorApplication,reachPositionandrequestClearRoute:
auto asFieldOperatorApplication() const -> concealer::FieldOperatorApplication &;
bool reachPosition(const geometry_msgs::msg::Pose & target_pose, const double tolerance) const;
bool reachPosition(const CanonicalizedLaneletPose & lanelet_pose, const double tolerance) const;
bool reachPosition(const std::string & target_name, const double tolerance) const;
void requestClearRoute(); -
Added:
isStopped,isInPositionandisInLanelet.
auto isStopped() const -> bool;
auto isInPosition(const geometry_msgs::msg::Pose & pose, const double tolerance) const -> bool;
auto isInPosition(const CanonicalizedLaneletPose & lanelet_pose, const double tolerance) const -> bool;
auto isInLanelet() const -> bool;
auto isInLanelet(const lanelet::Id lanelet_id, std::optional<double> tolerance = std::nullopt) const -> bool;
Note: Maybe it's a good idea to provide that tolerance is always of type std::optional<double>?
EgoEntity
- Removed
asFieldOperatorApplication:
auto asFieldOperatorApplication() const -> concealer::FieldOperatorApplication & override;
FieldOperatorApplicationFor
- Added visibility to members of
FieldOperatorApplication(see this comment). - EgoEntity now exposes these inherited members as a replacement of previous
asFieldOperatorApplication:
auto isStopRequested() const -> bool;
auto isEngageable() const -> bool;
auto isEngaged() const -> bool;
auto engage() -> void;
auto sendCooperateCommand(const std::string & module_name, const std::string & command) -> void;
auto getAutowareStateName() const -> const std::string &;
auto getEmergencyStateName() const -> const std::string &;
auto getMinimumRiskManeuverBehaviorName() const -> const std::string &;
auto getMinimumRiskManeuverStateName() const -> const std::string &;
auto getTurnIndicatorsCommandName() const -> std::string;
auto requestAutoModeForCooperation(const std::string & module_name, const bool enable) -> void;
auto getWaypoints() const -> traffic_simulator_msgs::msg::WaypointsArray;
EntityManager
-
Removed forwarded using macro to
EntityBase:activateOutOfRangeJob,asFieldOperatorApplication,cancelRequest,get2DPolygon,getBehaviorParameter,getBoundingBox,getCanonicalizedStatusBeforeUpdate,getCurrentAccel,getCurrentTwist,getDefaultMatchingDistanceForLaneletPoseCalculation,getEntityType,getEntityTypename,getLinearJerk,getRouteLanelets,getStandStillDuration,getTraveledDistance,isControlledBySimulator,laneMatchingSucceed,reachPosition,requestAcquirePosition,requestAssignRoute,requestClearRoute,requestFollowTrajectory,requestLaneChange,requestSpeedChange,requestSynchronize,requestWalkStraight,setAcceleration,setAccelerationLimit,setAccelerationRateLimit,setBehaviorParameter,setControlledBySimulator,setDecelerationLimit,setDecelerationRateLimit,setLinearJerk,setLinearVelocity,setMapPose,setTwist,setVelocityLimit:
FORWARD_TO_ENTITY(activateOutOfRangeJob);
FORWARD_TO_ENTITY(asFieldOperatorApplication);
FORWARD_TO_ENTITY(cancelRequest);
FORWARD_TO_ENTITY(get2DPolygon);
FORWARD_TO_ENTITY(getBehaviorParameter);
FORWARD_TO_ENTITY(getBoundingBox);
FORWARD_TO_ENTITY(getCanonicalizedStatusBeforeUpdate);
FORWARD_TO_ENTITY(getCurrentAccel);
FORWARD_TO_ENTITY(getCurrentTwist);
FORWARD_TO_ENTITY(getDefaultMatchingDistanceForLaneletPoseCalculation);
FORWARD_TO_ENTITY(getEntityType);
FORWARD_TO_ENTITY(getEntityTypename);
FORWARD_TO_ENTITY(getLinearJerk);
FORWARD_TO_ENTITY(getRouteLanelets);
FORWARD_TO_ENTITY(getStandStillDuration);
FORWARD_TO_ENTITY(getTraveledDistance);
FORWARD_TO_ENTITY(isControlledBySimulator);
FORWARD_TO_ENTITY(laneMatchingSucceed);
FORWARD_TO_ENTITY(reachPosition);
FORWARD_TO_ENTITY(requestAcquirePosition);
FORWARD_TO_ENTITY(requestAssignRoute);
FORWARD_TO_ENTITY(requestClearRoute);
FORWARD_TO_ENTITY(requestFollowTrajectory);
FORWARD_TO_ENTITY(requestLaneChange);
FORWARD_TO_ENTITY(requestSpeedChange);
FORWARD_TO_ENTITY(requestSynchronize);
FORWARD_TO_ENTITY(requestWalkStraight);
FORWARD_TO_ENTITY(setAcceleration);
FORWARD_TO_ENTITY(setAccelerationLimit);
FORWARD_TO_ENTITY(setAccelerationRateLimit);
FORWARD_TO_ENTITY(setBehaviorParameter);
FORWARD_TO_ENTITY(setControlledBySimulator);
FORWARD_TO_ENTITY(setDecelerationLimit);
FORWARD_TO_ENTITY(setDecelerationRateLimit);
FORWARD_TO_ENTITY(setLinearJerk);
FORWARD_TO_ENTITY(setLinearVelocity);
FORWARD_TO_ENTITY(setMapPose);
FORWARD_TO_ENTITY(setTwist);
FORWARD_TO_ENTITY(setVelocityLimit); -
Removed
is,isStopping,isInLanelet,checkCollision,getEntityStatus,getCurrentAction:
bool is(const std::string & name) const;
~~`bool isStopping(co...
8.0.2
Abstract
This PR contains a bug fix for the issue described here.
Details
The reference to a value managed by the shared pointer escapes (Line 30).
https://github.com/tier4/scenario_simulator_v2/blob/fa9ca062dfd0cb5ca6ea55ae28d29c8935dee668/external/concealer/include/concealer/subscriber.hpp#L21-L56
When that const & is used and the underlying value is modified by the owner, a race condition occurs.
Return by value instead of by const & to force a copy and avoid the problem.
References
Regressions OK