You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some runs BSM was not able to be encoded. The issue is intermittent, but sometimes happens a lot to make BSM unusable.
I have seen the issue in simulation where the vehicle did not move at all. It suddenly started not being able to encode BSM, which the log shows failure to create projection from x,y.z to lat and lon that's needed in BSM. See below picture:
And also I noticed this issue in real life vehicle where BSM's lat lon comes out wrong intermittently:
good:
few sec later where vehicle didn't move, bsm id not changed (because configured to be fixed):
This is most likely occurring from constantly recreating projector because the georeference msg is being published at some rate and there is a race condition occurring:
Turning the georeference broadcast back to 2Hz actually makes the startup process little unstable where platform shuts down soon after startup. This is because when some data is broadcasting such as MAP, the node may not have georeference when it is instructed to process it. Then the common handling method looks like just throw an exception. Instead, the callers probably need to handle the exception gracefully
Summary
For some runs BSM was not able to be encoded. The issue is intermittent, but sometimes happens a lot to make BSM unusable.
I have seen the issue in simulation where the vehicle did not move at all. It suddenly started not being able to encode BSM, which the log shows failure to create projection from x,y.z to lat and lon that's needed in BSM. See below picture:
And also I noticed this issue in real life vehicle where BSM's lat lon comes out wrong intermittently:
good:
few sec later where vehicle didn't move, bsm id not changed (because configured to be fixed):
This is most likely occurring from constantly recreating projector because the georeference msg is being published at some rate and there is a race condition occurring:
NOTE:
It probably didn't have issue in ROS1 because we had 0.5hz as publication before. But ROS2 migration made it 2hz (every 500ms), which also probably should be reverted back:
ROS1:
https://github.com/usdot-fhwa-stol/autoware.ai/blob/carma-system-4.1.0/common/map_file/nodes/map_param_loader/map_param_loader.cpp#L98
ROS2:
https://github.com/usdot-fhwa-stol/autoware.ai/blob/carma-system-4.5.0/common/map_file_ros2/nodes/map_param_loader/map_param_loader.cpp#L63
Version
4.5.0 (Current)
Expected Behavior
BSM is able to be encoded
Actual Behavior
BSM not encodeable
Steps to Reproduce the Actual Behavior
Start carma and wait for logs to start saying not able to encode BSM.
Issue is intermittent.
Perhaps it will occur more on PC that has less power.
Related Work
No response
The text was updated successfully, but these errors were encountered: