evshary
Cannot run the most recent version of Autoware with the bridge
Hi @evshary!
I'm currently trying to use the most recent version of Autoware, but I encountered the following error while running ./script/run-autoware.sh.
1702373501.2179277 [INFO] [launch]: Default logging verbosity is set to INFO
1702373508.5440278 [ERROR] [launch]: Caught exception in launch (see debug for traceback): Included launch description missing required argument 'duplicated_node_checker_param_path' (description: 'no description given'), given: [map_path, ...
It seems the new feature duplicated_node_checker is added to the Autoware, but the path duplicated_node_checker_param_path is not set. Could you please tell me where to modify to handle this issue?
Thank you. Please answer me when you are available.
Which branch do you refer to, main or humble?
Can you check the git status and see whether there is anything modified?
From the error log, I guess there is some version conflict with Autoware, so I would like to check this first.
Thank you for the response @evshary!
Sorry for omitting the branch. I'm currently running on humble branch.
I also tested the branches main and humble-0.9.14, but they also have the same problem.
And I'm running Autoware with the latest(20231201) docker image from here.
I've tried to relieve the issue by appending <arg name="duplicated_node_checker_param_path" value="$(find-pkg-share autoware_launch)/config/system/duplicated_node_checker/duplicated_node_checker.param.yaml"/> (from autoware_launch) to ./src/autoware_launch/autoware_launch/launch/autoware.launch.xml, but another parameter makes an error..
OK, that makes sense. The bridge hasn't been tested with the latest Autoware. If you want to try maybe you need to update the autoware_launch to the 20231201 first https://github.com/evshary/autoware_launch/tree/carla_202308 And then update the commit here https://github.com/evshary/autoware_carla_launch/blob/humble-0.9.14/autoware_carla.repos#L9 I haven't tried this, but some issues might need to be fixed.
Thank you for the reply @evshary!
I've done everything you suggested, and it seems there's no error regarding the parameters. However, I got another weird error during the initialization of rviz:
[rviz2-87] [ERROR] [1702515332.095774043] [rviz2]: Failed to create an OpenGL context. BadValue (integer parameter out of range for operation)
[rviz2-87] [ERROR] [1702515332.095825124] [rviz2]: RenderingAPIException: Unable to create a suitable GLXContext in GLXContext::GLXContext at ./.obj-x86_64-linux-gnu/ogre-v1.12.1-prefix/src/ogre-v1.12.1/RenderSystems/GLSupport/src/GLX/OgreGLXContext.cpp (line 60)
[rviz2-87] [ERROR] [1702515332.095855878] [rviz2]: rviz::RenderSystem: error creating render window: RenderingAPIException: Unable to create a suitable GLXContext in GLXContext::GLXContext at ./.obj-x86_64-linux-gnu/ogre-v1.12.1-prefix/src/ogre-v1.12.1/RenderSystems/GLSupport/src/GLX/OgreGLXContext.cpp (line 60)
It seems there are some issue on NVIDIA driver, and nvidia-smi also does not work (emits Failed to initialize NVML: Driver/library version mismatch).
I guess the required version of driver is changed for the latest autoware, so I'm going to ask about it to Autoware team.
Thank you for your help! Please let me know if you know anything about this issue!
Hi @evshary!
I updated my cuda version and I tried to run the Autoware with docker image 20231215.
Following your answer, I also synchronized autoware_launch(I cloned the last commit in 20231215 of autowarefoundation/autoware_launch and applied your one commit to it) with the Autoware version and I'm on humble branch of the bridge (carla version is 0.9.13).
But I encountered another problem, and I could not connect bridge with carla.
Here's the launch.log and the image of rviz: [launch.log] [rviz image]
From launch.log, I could check the error messages which have not been observed from the old version of Autoware(20230715):
1703148674.5888481 [ERROR] [lidar_centerpoint_node-47]: process has died [pid 4230, exit code -11, cmd '/autoware/install/lidar_centerpoint/lib/lidar_centerpoint/lidar_centerpoint_node --ros-args -r __node:=lidar_centerpoint -r __ns:=/perception/object_recognition/detection/centerpoint -p use_sim_time:=True -p wheel_radius:=0.383 -p wheel_width:=0.235 -p wheel_base:=2.79 -p wheel_tread:=1.64 -p front_overhang:=1.0 -p rear_overhang:=1.1 -p left_overhang:=0.128 -p right_overhang:=0.128 -p vehicle_height:=2.5 -p max_steer_angle:=0.7 --params-file /tmp/launch_params_4kszj1cz --params-file /tmp/launch_params_ywudzhz6 --params-file /tmp/launch_params_h9fkivzk --params-file /tmp/launch_params_k5u7sqlx --params-file /tmp/launch_params_99ao8xp4 --params-file /tmp/launch_params_swoe7dq0 --params-file /tmp/launch_params_h18_yoyd --params-file /tmp/launch_params_f1_mr26u --params-file /tmp/launch_params_1f5goik4 --params-file /tmp/launch_params_n6dblkl2 --params-file /home/mins/autoware_carla_launch/install/autoware_launch/share/autoware_launch/config/perception/object_recognition/detection/lidar_model/centerpoint_tiny.param.yaml --params-file /home/mins/autoware_carla_launch/install/autoware_launch/share/autoware_launch/config/perception/object_recognition/detection/lidar_model/detection_class_remapper.param.yaml -r ~/input/pointcloud:=/sensing/lidar/concatenated/pointcloud -r ~/output/objects:=objects'].
1703148675.2355673 [component_container_mt-58] [I] [TRT] [MemUsageChange] Init builder kernel library: CPU +888, GPU -4, now: CPU 1012, GPU 1290 (MiB)
1703148675.2513077 [component_container_mt-58] Could not open file /home/mins/autoware_data/traffic_light_classifier/traffic_light_classifier_mobilenetv2_batch_6.onnx
1703148675.2514405 [component_container_mt-58] Could not open file /home/mins/autoware_data/traffic_light_classifier/traffic_light_classifier_mobilenetv2_batch_6.onnx
1703148675.2514906 [component_container_mt-58] [E] [TRT] ModelImporter.cpp:733: Failed to parse ONNX model from file: /home/mins/autoware_data/traffic_light_classifier/traffic_light_classifier_mobilenetv2_batch_6.onnx
1703148675.2515256 [component_container_mt-58] [E] [TRT] Failed to parse onnx file
1703148675.2638552 [component_container_mt-58] [E] [TRT] [network.cpp::getInput::1968] Error Code 3: API Usage Error (Parameter check failed at: optimizer/api/network.cpp::getInput::1968, condition: index < getNbInputs()
1703148675.2640448 [component_container_mt-58] )
1703148675.5038345 [ERROR] [component_container_mt-58]: process has died [pid 4360, exit code -11, cmd '/opt/ros/humble/lib/rclcpp_components/component_container_mt --ros-args -r __node:=traffic_light_node_container -r __ns:=/perception/traffic_light_recognition/camera6 -p use_sim_time:=True -p wheel_radius:=0.383 -p wheel_width:=0.235 -p wheel_base:=2.79 -p wheel_tread:=1.64 -p front_overhang:=1.0 -p rear_overhang:=1.1 -p left_overhang:=0.128 -p right_overhang:=0.128 -p vehicle_height:=2.5 -p max_steer_angle:=0.7'].
And the image shows that the localization state is UNINITIALIZED.
Actually, I cannot sure whether the bridge or the Autoware makes the error, or maybe I made a mistake while updating autoware_launch version.
But I just want to know if you know any hint.
I always appreciate to your help! Thank you for reading!
Hi @Kim-mins
Maybe you can check whether the planning_simulator works well first.
If yes, then the error should come from the bridge.
BTW, I found that the machine learning models are now put inside the ~/autoware_data, which did not exist before.
https://github.com/autowarefoundation/autoware/tree/main/ansible/roles/artifacts
I guess this is the root cause.
Thank you for the information @evshary!!
I found the planning simulation does not works well too.
I also tried downloading autoware_data, but the planning simulation and the Autoware with the bridge did not work.
So I just asked to Autoware team. I'll let you know if I get any conclusion. Thank you!
Hi @evshary,
I can successfully run the planning simulation with the latest Autoware, but I could not run the latest Autoware with the bridge.. The setting is the same as before, and it seems the lanelet map is not loaded well.
Here's the screenshot:
As you can see, the pointcloud is loaded well but there's no lines regarding lanelet file. So the autoware fails to localize.
I think this situation is similar to that we suffered on July(when tried to run Autoware version 20230715), so I checked the parameter lanelet2_map_projector_type in autoware_launch/config/map/lanelet2_map_loader.param.yaml.
I tried MGRS, local and UTM, but every parameters did not work..
Do you have any idea on this issue?
Thank you!
Hi @Kim-mins Sorry for the late reply. I'm working on another project recently. I guess there might be changed a lot in Autoware from 0715 to 1215, and maybe there are some renamed topics or something else. Could you share the log about this issue? If I have time (I hope so...), I'll try to upgrade the Autoware as well.
Thank you for the response @evshary!!
I just found the (prebuilt) Autoware's latest version is 20240115 [link]. I'll try the bridge on the latest version and share the log and the results soon.
Thank you!
Hi @evshary
I tried from the prebuilt Autoware docker image [20240115], and I failed to run the Autoware with the bridge. For autoware launch, I tried the commit [10b95d7669ff77a8fce3954c0b314e1126f92d9c] and applied your [last commit]. As you mentioned before, I also downloaded the artifacts [here].
Here's the launch.log file: [launch.log] The situation of rviz is the same as the comment above, and it seems the Autoware fails to find the initial location.
I cannot sure, but I could find the two suspicious parts:
- Error log on
HW_ID
1705367914.2826617 [component_container-74] [WARN] [1705367914.278349422] [control.control_validator]: diagnostic_updater: No HW_ID was set. This is probably a bug. Please report it. For devices that do not have a HW_ID, set this value to 'none'. This warning only occurs once all diagnostics are OK. It is okay to wait until the device is open before calling setHardwareID.
- Error log on NDT align
1705367922.7957239 [pose_initializer_node-35] [INFO] [1705367922.794700570] [localization.util.pose_initializer_node]: Call NDT align server.
1705367922.7961497 [ndt_scan_matcher-34] [INFO] [1705367922.795110677] [localization.pose_estimator.ndt_scan_matcher]: waiting response
1705367922.7962029 [ndt_scan_matcher-34] [INFO] [1705367922.795243927] [localization.pose_estimator.ndt_scan_matcher]: Update map (Add: 0, Remove: 0)
1705367922.7965693 [ndt_scan_matcher-34] [INFO] [1705367922.795260143] [localization.pose_estimator.ndt_scan_matcher]: Skip map update
1705367922.7966206 [ndt_scan_matcher-34] [WARN] [1705367922.795267455] [localization.pose_estimator.ndt_scan_matcher]: No InputTarget. Please check the map file and the map_loader service
1705367922.7969539 [pose_initializer_node-35] [INFO] [1705367922.795325841] [localization.util.pose_initializer_node]: NDT align server failed.
1705367922.7973862 [service_log_checker-4] [ERROR] [1705367922.795475120] [system.service_log_checker]: /localization/initialize: status code 4 'NDT align server failed.' (/localization/util/pose_initializer_node)
1705367922.7974389 [service_log_checker-4] [ERROR] [1705367922.795874147] [system.service_log_checker]: /localization/initialize: status code 4 'NDT align server failed.' (/default_ad_api/node/localization)
1705367922.7979085 [service_log_checker-4] [ERROR] [1705367922.795930542] [system.service_log_checker]: /api/localization/initialize: status code 4 'NDT align server failed.' (/default_ad_api/node/localization)
1705367922.7979603 [service_log_checker-4] [ERROR] [1705367922.796016688] [system.service_log_checker]: /api/localization/initialize: status code 4 'NDT align server failed.' (/localization/util/default_ad_api/helpers/automatic_pose_initializer)
1705367923.6933978 [component_container-74] [INFO] [1705367923.692724870] [control.trajectory_follower.controller_node_exe]: Waiting for trajectory.
1705367923.6935482 [component_container-74] [INFO] [1705367923.692776002] [control.trajectory_follower.controller_node_exe]: Control is skipped since input data is not ready.
1705367924.2941697 [path_distance_calculator_node-82] [WARN] [1705367924.293058714] [autoware_api.utils.path_distance_calculator]: failed to get transform from map to base_link: Could not find a connection between 'map' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.
I don't know the details well, but I hope these could be the help.
I always appreciate to your help! Thank you!
Update
I just found the documentation on the map_loader [here] and I added the file named map_projector_info.yaml with the content below in each map folder(carla_map/Town01, carla_map/Town02, ...).
projector_type: local
This issue should come from the latter one, which means we need to take a look at why NDT align server failed.
I guess there is something wrong with the sensor transformation.
Maybe checking the output topic of sensors (GNSS & pointcloud) is a good starting point.
According to the node diagram, the input of ndt_scan_matcher might have some problems.
Thank you for the detailed response @evshary!
For debugging, I focused on the log message below:
1705367922.7962029 [ndt_scan_matcher-34] [INFO] [1705367922.795243927] [localization.pose_estimator.ndt_scan_matcher]: Update map (Add: 0, Remove: 0)
For the comparison, I checked if I can get the same log message from 20230715, but I could get a bit different log as below:
1705982206.5634191 [ndt_scan_matcher-31] [INFO] [1705982206.561748232] [localization.pose_estimator.ndt_scan_matcher]: Update map (Add: 1, Remove: 0)
which states the added one is 1, instead of 0.
So I checked the source code(I'm not that familiar though..), and I could find the code line relevant to the log above, and the variable related to that 1 or 0 is maps_to_add, which is the parameter of the function update_ndt.
The function update_ndt is called at line 76 of the same code, and I thought the parameter related to the variable maps_to_add have to do with pointcloud.
So I checked the message(as you recommended) from /localization/util/downsample/pointcloud, which is related to the pointcloud, and I could not get any message from the topic.
Also, following the topology of the diagram you provided, I echoed every topics (topologically) above the ndt_scan_matcher, but I cannot get any message from the latest version (I echoed to the topics /localization/util/voxel_grid_downsample/pointcloud, /localization/util/measurement_range/pointcloud, /sensing/lidar/top/pointcloud**).
However, when I echo the topic /localization/util/downsample/pointcloud on 20230715 version, I could get the message as below:
header:
stamp:
sec: 86
nanosec: 608223673
frame_id: base_link
height: 1
width: 1072
fields:
- name: x
offset: 0
datatype: 7
count: 1
- name: y
offset: 4
datatype: 7
count: 1
- name: z
offset: 8
datatype: 7
count: 1
is_bigendian: false
point_step: 16
row_step: 17152
data:
- 61
- 6
- 60
- 64
- 204
- 167
...
- '...'
is_dense: true
I also echoed to the (topologically) above topics on 20230715, but I could get the message from all the topics above, except /sensing/lidar/top/pointcloud, which seems not a published topic of the old version.
By the way, I could find some topics in the diagram you provided are not in my topic list(from ros2 topic list).
Here are the list of the topics I cannot find:
/localization/pose_twist_fusion_filter/pose_with_covariance_no_yaw_bias (from ekf_localizer to ndt_scan_matcher (in the diagram))
/sensing/lidar/*/velodyne_packets
/sensing/lidar/*/self_cropped/pointcloud
/sensing/lidar/*/mirror_cropped/pointcloud
...(maybe more..)
I wonder if those topics are processed internally, so that I cannot listen to it from outside. I inform you just with the concern that the topics above are new and should be handled.
Thank you for reading, even though you are so busy now! I always appreciate to your hard work!
@Kim-mins Thank you for diving into the code!
I agree with you it's weird that localization/util/downsample/pointcloud disappeared in the latest Autoware version.
It is worth a deeper investigation.
About the the lacking of
/sensing/lidar/*/velodyne_packets
/sensing/lidar/*/self_cropped/pointcloud
/sensing/lidar/*/mirror_cropped/pointcloud
We don't need this in Carla, since we can just transformed the lidar topic from Carla into /sensing/lidar/concatenated/pointcloud directly.
https://github.com/evshary/autoware_carla_launch/blob/main/src/carla_pointcloud/src/carla_pointcloud/carla_pointcloud_interface_node.cpp#L37C83-L37C106
However, I did find something changed in the latest Autoware
https://github.com/autowarefoundation/autoware.universe/commit/3e62ad4e6d5299c089d11a44a9373d5854b48c81#diff-03009c8cf043839bf6bc8604015a841a31b3e3981d91fb0e6f1f58c8558446c9L17
Would you mind modifying the code here with /sensing/lidar/top/pointcloud and test again?
https://github.com/evshary/autoware_carla_launch/blob/main/src/carla_pointcloud/src/carla_pointcloud/carla_pointcloud_interface_node.cpp#L35
Thank you for the response @evshary!!
I tried your suggestion by modifying the code
velodyne_points_localization =
this->create_publisher<sensor_msgs::msg::PointCloud2>("/sensing/lidar/top/outlier_filtered/pointcloud", rclcpp::SensorDataQoS());
to
velodyne_points_localization =
this->create_publisher<sensor_msgs::msg::PointCloud2>("/sensing/lidar/top/pointcloud", rclcpp::SensorDataQoS());
whose string /outlier_filtered is removed, and built the bridge and autoware again.
However, I got the same situation, with the same log(NDT align server failed) as below:
1706514376.2651873 [pose_initializer_node-35] [INFO] [1706514376.263545527] [localization.util.pose_initializer_node]: EKF Deactivation succeeded
1706514376.2676754 [pose_initializer_node-35] [INFO] [1706514376.266079588] [localization.util.pose_initializer_node]: NDT Deactivation succeeded
1706514376.2694700 [pose_initializer_node-35] Failed to find match for field 'x'.
1706514376.2695730 [pose_initializer_node-35] Failed to find match for field 'y'.
1706514376.2696171 [pose_initializer_node-35] Failed to find match for field 'z'.
1706514376.2696538 [pose_initializer_node-35] [INFO] [1706514376.267910920] [localization.util.pose_initializer_node]: Call NDT align server.
1706514376.2701447 [ndt_scan_matcher-34] [INFO] [1706514376.268579316] [localization.pose_estimator.ndt_scan_matcher]: waiting response
1706514376.2702029 [ndt_scan_matcher-34] [INFO] [1706514376.268879353] [localization.pose_estimator.ndt_scan_matcher]: Update map (Add: 0, Remove: 0)
1706514376.2702434 [ndt_scan_matcher-34] [INFO] [1706514376.268904988] [localization.pose_estimator.ndt_scan_matcher]: Skip map update
1706514376.2702796 [ndt_scan_matcher-34] [WARN] [1706514376.268913923] [localization.pose_estimator.ndt_scan_matcher]: No InputTarget. Please check the map file and the map_loader service
1706514376.2708511 [pose_initializer_node-35] [INFO] [1706514376.268995691] [localization.util.pose_initializer_node]: NDT align server failed.
1706514376.2713027 [service_log_checker-4] [ERROR] [1706514376.269196018] [system.service_log_checker]: /localization/initialize: status code 4 'NDT align server failed.' (/localization/util/pose_initializer_node)
1706514376.2716570 [service_log_checker-4] [ERROR] [1706514376.269990052] [system.service_log_checker]: /localization/initialize: status code 4 'NDT align server failed.' (/default_ad_api/node/localization)
1706514376.2717092 [service_log_checker-4] [ERROR] [1706514376.270057784] [system.service_log_checker]: /api/localization/initialize: status code 4 'NDT align server failed.' (/default_ad_api/node/localization)
1706514376.2717612 [service_log_checker-4] [ERROR] [1706514376.270159223] [system.service_log_checker]: /api/localization/initialize: status code 4 'NDT align server failed.' (/localization/util/default_ad_api/helpers/automatic_pose_initializer)
1706514376.5615833 [path_distance_calculator_node-82] [WARN] [1706514376.560890805] [autoware_api.utils.path_distance_calculator]: failed to get transform from map to base_link: Could not find a connection between 'map' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.
If you have time and more suggestions for the fix, I think you can provide me more, since I have the running environment now.
I'll also investigate more about the modified topics. Thank you!
EDIT--------------------
I also checked the topics above that did not work before(/localization/util/voxel_grid_downsample/pointcloud, /localization/util/measurement_range/pointcloud, /sensing/lidar/top/pointcloud, /sensing/lidar/top/pointcloud), and I could observe the output from every topics.
Hi @evshary
I cannot sure, but the commit below seems modifying topics.
- https://github.com/autowarefoundation/autoware.universe/commit/68ee0f220fcd3e4f0ed9276270008d04fd579120
- https://github.com/autowarefoundation/autoware.universe/commit/b498c5352390e3637fb723140bf7b541d5bb04a8
- https://github.com/autowarefoundation/autoware.universe/commit/8a139596de1ca20318cbb8d08a1a569e86988a90
Sorry for bothering you while you are busy now, but could you please check those if you have time?
@Kim-mins Thank you for the investigation. After a quick view, I don't think these modifications make any difference, but maybe I missed something. Will take a further look later.
I also checked the topics above that did not work before(/localization/util/voxel_grid_downsample/pointcloud, /localization/util/measurement_range/pointcloud, /sensing/lidar/top/pointcloud, /sensing/lidar/top/pointcloud), and I could observe the output from every topics.
Sounds good. At least we have some progress. Since lidar data should be good now, could you help me check whether GNSS works well or not?
Thank you for the response @evshary!
For GNSS, I echoed the topic with the string gnss(please tell me if there's more), and here's the echo result for each topic relevant to GNSS (every topic works)
-
/sensing/gnss/fixed:stamp: sec: 153 nanosec: 208064745 data: true -
/sensing/gnss/pose:header: stamp: sec: 136 nanosec: 258064492 frame_id: map pose: position: x: 66022.95483240287 y: 99706.26651246473 z: 19.40150260925293 orientation: x: 0.0 y: 0.0 z: 0.0 w: 1.0 -
/sensing/gnss/pose_with_covarianceheader: stamp: sec: 174 nanosec: 808065067 frame_id: map pose: pose: position: x: 66022.95483240287 y: 99706.26651246473 z: 19.40150260925293 orientation: x: 0.0 y: 0.0 z: 0.0 w: 1.0 covariance: - 10.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 10.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 10.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 -
/sensing/gnss/ublox/nav_sat_fixheader: stamp: sec: 186 nanosec: 708065244 frame_id: gnss_link status: status: 1 service: 15 latitude: -0.002653832465426831 longitude: 1.3563788603466434e-05 altitude: 19.40150260925293 position_covariance: - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 - 0.0 position_covariance_type: 0
It is good signal since every topic work, but I saw a bit weird position from /sensing/gnss/pose and /sensing/gnss/pose_with_covariance:
position:
x: 66022.95483240287
y: 99706.26651246473
z: 19.40150260925293
When I echoed to the topic /sensing/gnss/pose and /sensing/gnss/pose_with_covariance from the version 20230715, I could get the position values as below:
position:
x: 40.15022040623561
y: -143.9113872943367
z: -0.20792973165465334
which are valid for the given map(from Carla).
I thought this could be the map configuration error that we suffered while running 20230715, so I tried modifying map projection types(local, MGRS, LocalCartesianUTM, the result above is from MGRS), following the instructions here.
When I tried to echo to the topics relevant to GNSS for each projection type, I could observe that, two of GNSS topics(/sensing/gnss/fixed, /sensing/gnss/pose) are invisible with the projection type local and LocalCartesianUTM, and the rest of the visible topics do not publish any message.
So I think the projection type MGRS is the correct one, and maybe I should check another configurations.. do you have any idea on this?
Thank you for reading and thank you for your help!
Hi @evshary!
From the map loader instruction, I could see the limitation of using local as the projection type, which was updated last week.
We used local as the projection type for 20230715, but it does not work now. I think the limitation on local is exactly what we are suffering now(GNSS Localization), (I don't know why MGRS does not work, but) so maybe the map projection type could be the root cause of our issue. Do you have any idea on this?
Or.. I also checked the launch.log again and I focused on the warning on ekf_localizer.
[ekf_localizer-38] [WARN] [1706593199.330410044] [localization.pose_twist_fusion_filter.ekf_localizer]: The node is not activated. Provide initial pose to pose_initializer
According to the diagram you provided before, the component pose_initializer gets input from two topics, /sensing/gnss/pose_with_covariance and /initialpose.
However, I could not get the message from /initialpose, which is from HMI, so maybe this could be the another root cause. Do you have any idea on this?
/initialpose should not be the issue, since we don't need users to provide the initial pose. GNSS should provide enough information.
The issue of the map loader might be the key, although I haven't taken a deeper look.
Maybe we can focus on this first.
Hi @evshary!
I just found a comment of the discussion which seems strongly relevant to our issue: https://github.com/orgs/autowarefoundation/discussions/4040#discussioncomment-8239829
Also, this comment could be the solution for us, but I cannot understand.. could you please read the comment?
By the way, I also checked the reason why the topic /localization/util/downsample/pointcloud does not output any message since no publisher is assigned to the topic, and it seems the topic gets the message from another topic by remapping.
I'm investigating this more now, and I'll let you know if I could get something.
I also found that the topic /sensing/lidar/top/pointcloud is not properly published with the projector_type: local, and it works with the projector_type: MGRS. I don't know about this that well, so I'm also investigating on this.
@Kim-mins Maybe the problem is related to the issue https://github.com/orgs/autowarefoundation/discussions/3759#discussioncomment-6862856
Thank you for the response @evshary!
I checked the comment you mentioned and it seems they decided not to support some of the projector_types and change the way to provide the projector_type.
I'm using projector_type as local since this is the only option that loads lanelet2 map correctly. (I referred to the code and it seems the option local is valid.)
I thought I'm providing projection type properly, following the map projection loader documentation, but maybe I should check it more.
By the way, after some investigation, I observed that the gnss_poser node is not loaded with the projection type local but the node is loaded well with the projection type MGRS. gnss_poser is loaded well with the version 20230715, so maybe this could be the root cause of our issue. I'm focusing on this point now. Could you please share your opinion on this?
EDIT:
I also checked the launch.log file, and I could see the gnss_poser died at the beginning of the log as below:
1707272045.1582739 [ERROR] [gnss_poser-36]: process has died [pid 716, exit code -6, cmd '/autoware/install/gnss_poser/lib/gnss_poser/gnss_poser --ros-args -r __node:=gnss_poser -r __ns:=/sensing/gnss -p use_sim_time:=True -p wheel_radius:=0.383 -p wheel_width:=0.235 -p wheel_base:=2.79 -p wheel_tread:=1.64 -p front_overhang:=1.0 -p rear_overhang:=1.1 -p left_overhang:=0.128 -p right_overhang:=0.128 -p vehicle_height:=2.5 -p max_steer_angle:=0.7 --params-file /autoware/install/gnss_poser/share/gnss_poser/config/gnss_poser.param.yaml -r fix:=ublox/nav_sat_fix -r autoware_orientation:=/autoware_orientation -r gnss_pose:=pose -r gnss_pose_cov:=pose_with_covariance -r gnss_fixed:=fixed'].
I'll ask this error to the team and let you know if get the answer!
Sorry for bothering you too much, but I got to know that, the gnss_poser node dies after running the bridge.
I run the Autoware following your instruction on README.md, and there's no log regarding the error of gnss_poser.
But after running the bridge (following your instruction on README.md), the gnss_poser dies with the log of the previous comment.
Could you please tell me the way to debug it more? I'm not familiar to debug and find the root cause of Autoware. Maybe using projection type local is not supported now, as you told before.. but I cannot know how to resolve..
Is there any more log from gnss_poser before it died?
Maybe we need to add some debug messages into the gnss_poser to see what happened.
https://github.com/autowarefoundation/autoware.universe/blob/main/sensing/gnss_poser/src/gnss_poser_core.cpp#L29
Are you using the prebuilt Autoware? Or do you build the Autoware by yourself?
Thank you for the response @evshary!
Unfortunately, there's no more log from gnss_poser. The only logs I could get are the two lines below (the node dies just after being turned on):
...
1707289879.2995105 [INFO] [gnss_poser-36]: process started with pid [610]
1707289879.2996364 [ERROR] [gnss_poser-36]: process has died [pid 610, exit code -6, cmd '/autoware/install/gnss_poser/lib/gnss_poser/gnss_poser --ros-args -r __node:=gnss_poser -r __ns:=/sensing/gnss -p use_sim_time:=True -p wheel_radius:=0.383 -p wheel_width:=0.235 -p wheel_base:=2.79 -p wheel_tread:=1.64 -p front_overhang:=1.0 -p rear_overhang:=1.1 -p left_overhang:=0.128 -p right_overhang:=0.128 -p vehicle_height:=2.5 -p max_steer_angle:=0.7 --params-file /autoware/install/gnss_poser/share/gnss_poser/config/gnss_poser.param.yaml -r fix:=ublox/nav_sat_fix -r autoware_orientation:=/autoware_orientation -r gnss_pose:=pose -r gnss_pose_cov:=pose_with_covariance -r gnss_fixed:=fixed'].
...
I'm trying on the prebuilt Autoware from docker now(version 20240201).
I guess you want to check if I can append the code for debugging and build the source code.
I think I can anyway, but I have no idea on adding debugging options for gnss_poser. Could you please help me?
Hi @evshary!
I asked to the Autoware team, and sadly, I got the answer that the projector type local is not available now (as you mentioned before): https://github.com/orgs/autowarefoundation/discussions/4157#discussioncomment-8403435
So, maybe we should use another projector type.. I asked some more to the team, and I'll let you know if I get the answer.
Hi @Kim-mins
Thank you for the instant check with the Autoware team. I'm off from the office these days and might not be able to take a look. Starting from checking how to use another projector type should be a more feasible way to solve the problem.
Thank you for the response @evshary!
I'm discussing the way to use another projector type with the Autoware team now. I'll let you know if I got to know how. Have a nice holiday!