Revision history [back]

@mackou Autoware is currently underoing our "Maintenance/Clean-Up Phase" from the AVP demo. Part of this effort is to merge the changes we made during our rush up to the AVP demo on the integration branch back into master. The code that we used during final testing and the demo is on the integration branch and I recommend running your tests there for the time being. Additionally, the main issue that you're seeing in rviz is actually a visualization bug rather than a speed issue. Here is the situation:

1. The launch file publishes a stiatic identity transform between odom and base_link.
2. The Map Provider node publishes the static lidar point cloud map in the map frame once per second (a work-around for the dashing version of rviz not supporting transient-local topic lifetime).
3. The lidar fusion node continuously outputs a fused point cloud from both lidars in the base_link frame.
4. The NDT localization node consumes the fused point cloud and publishes a TF between map and odom.

Each time rviz receives data in a frame other than base_link, it has to look up the transform between that frame and base_link. Since the NDT localizer passes along the timestamp from the fused point cloud to the TF that it produces between map and odom and since the NDT localizer has a non-trivial compute time, you can sometimes receive data for which there is not yet a valid TF. If you expand the point cloud map topic in the left panel and look at the Status, you'll likely see the Transform flicker between Error and OK. We have fixed this in the integration branch. You can verify this by switching the Fixed Frame to map, in which case you'll see the opposite (data in map will be solid but other frames will be delayed/flicker).

I'll update this question once all changes in the integration branch have been merged to master.

@mackou Autoware is currently underoing our "Maintenance/Clean-Up Phase" from the AVP demo. Part of this effort is to merge the changes we made during our rush up to the AVP demo on the integration branch back into master. The code that we used during final testing and the demo is on the integration branch and I recommend running your tests there for the time being. Additionally, the main issue that you're seeing in rviz is actually a visualization bug rather than a speed issue. Here is the situation:

1. The launch file publishes a stiatic identity transform between odom and base_link.
2. The Map Provider node publishes the static lidar point cloud map in the map frame once per second (a work-around for the dashing version of rviz not supporting transient-local topic lifetime).
3. The lidar fusion node continuously outputs a fused point cloud from both lidars in the base_link frame.
4. The NDT localization node consumes the fused point cloud and publishes a TF between map and odom.

Each time rviz receives data in a frame other than base_link, it has to look up the transform between that frame and base_link. Since the NDT localizer passes along the timestamp from the fused point cloud to the TF that it produces between map and odom and since the NDT localizer has a non-trivial compute time, you can sometimes receive data for which there is not yet a valid TF. If you expand the point cloud map topic in the left panel and look at the Status, you'll likely see the Transform flicker between Error and OK. We have fixed this in the integration branch. You can verify this by switching the Fixed Frame to map, in which case you'll see the opposite (data in map will be solid but other frames will be delayed/flicker).

I'll update this question once all changes in the integration branch have been merged to master.

@mackou Autoware is currently underoing our "Maintenance/Clean-Up Phase" from the AVP demo. Part of this effort is to merge the changes we made during our rush up to the AVP demo on the integration branch back into master. The code that we used during final testing and the demo is on the integration branch and I recommend running your tests there for the time being. Additionally, the main issue that you're seeing in rviz is actually a visualization bug rather than a speed issue. Here is the situation:

1. The launch file publishes a stiatic identity transform between odom and base_link.
2. The Map Provider node publishes the static lidar point cloud map in the map frame once per second (a work-around for the dashing version of rviz not supporting transient-local topic lifetime).
3. The lidar fusion node continuously outputs a fused point cloud from both lidars in the base_link frame.
4. The NDT localization node consumes the fused point cloud and publishes a TF between map and odom.

Each time rviz receives data in a frame other than base_link, it has to look up the transform between that frame and base_link. Since the NDT localizer passes along the timestamp from the fused point cloud to the TF that it produces between map and odom and since the NDT localizer has a non-trivial compute time, you can sometimes receive data for which there is not yet a valid TF. If you expand the point cloud map topic in the left panel and look at the Status, you'll likely see the Transform flicker between Error and OK. We have fixed this in the integration branch. You can verify this by switching the Fixed Frame to map, in which case you'll see the opposite (data in map will be solid but other frames will be delayed/flicker).

I'll update this question once all changes in the integration branch have been merged to master.

UPDATE using integration branch:

In your local copy of the AutowareAuto repository (assuming you've cloned the official one and not a fork):

git checkout integration
git pull
git checkout 684-fix-segfault-in-point-cloud-filter-transform-nodes
git checkout integration
git cherry-pick d67af14e

$ ade --rc .aderc-lgsvl start --update --enter
ade$ source /opt/AutowareAuto/setup.bash
ade$ /opt/lgsvl/simulator

$ ade enter
ade$ cd AutowareAuto
ade$ source /opt/AutowareAuto/setup.bash
ade$ colcon build --packages-select point_cloud_filter_transform_nodes autoware_auto_avp_demo
ade$ source install/setup.bash
ade$ ros2 launch autoware_auto_avp_demo ms2.launch.py

ros2 action send_goal /planning/recordtrajectory recordreplay_planner_actions/action/RecordTrajectory "{record_path: $HOME/test.path}"

ros2 action send_goal /planning/replaytrajectory recordreplay_planner_actions/action/ReplayTrajectory "{replay_path: $HOME/test.path}"