# Autoware.Auto with LGSVL MS3 demo very slow

Hello,

I'm trying to run the MS3 demo available here with LGSVL. The problem is that the ndt localization seem to be very slow. (Is it even NDT localization ?)

Here's what I do :

• I start LGSVL in ROS2 Native mode with the AWF Lexus car, Astuff parking lot and the sensor data found on the Autoware.Auto repo.
• Then in an other ADE terminal I run this launchfile : ros2 launch autoware_auto_avp_demo ms3_sim.launch.py
• RVIZ2 Opens and It appears that I am already localized on the pointcloud map. When I move around the localization updates very slowly.

What is happening here ! Is the ndt localization working ? I didn't set any approximate localization in RVIZ and I still seem to be localized, is that normal ?

Here is a video of the problem : https://www.youtube.com/watch?v=enRex...

Also the localization doc available here is not clear at all.

Be carefull to enter appropriate values for map parameters such as minimum and maximum points.

What are those values? How do I get them for my own pcd map ?.

edit retag close merge delete

Sort by » oldest newest most voted

@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):

## Terminal 1

$ade --rc .aderc-lgsvl start --update --enter ade$ source /opt/AutowareAuto/setup.bash
ade$/opt/lgsvl/simulator  ## Terminal 2 $ 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  In your browser, go to http://127.0.0.1:8080 and set up the LGSVL scenario as described in https://autowarefoundation.gitlab.io/... and start the simulation. After this, you'll need to start the recording using the actions of the recordreplay_planner node. Here is an example that starts a recording: ros2 action send_goal /planning/recordtrajectory recordreplay_planner_actions/action/RecordTrajectory "{record_path:$HOME/test.path}"


CTRL+C will stop the recording. After that, move the vehicle back to the start using LGSVL and the keyboard. Once it's back at the start, run the following command to replay that path:

ros2 action send_goal /planning/replaytrajectory recordreplay_planner_actions/action ...
more

Status of merging of integration to mastercan be followed here: https://gitlab.com/autowarefoundation...

( 2020-11-10 01:47:21 -0500 )edit

Hey @Josh Whitley I have noticed that new errors have appeared :
- Unable to start ade with the integration branch, it asks me for a token api key.
- I seems that the branches integration and master are now in sync so I switched to the master branch and now I can start ADE.
- Now the ms3 demo doesn't work anymore, the 2 point_cloud_filter_transform_node_exe nodes die and the ndt localization doesn't work anymore.

Are those problem expected and what should I do to solve them ? thanks !

( 2020-11-29 13:37:59 -0500 )edit

@Mackou The merge from integration to master is still not yet complete. See the status at the link I gave above. Additionally, we have seen the error you mentioned with point_cloud_filter_transform_node- see https://gitlab.com/autowarefoundation... for details.

( 2020-11-30 13:47:12 -0500 )edit

@Josh Whitley Then if the integration branch should still work it doesn't for me. When trying to start the docker container it asks me for credentials and displays this error:
Error response from daemon: manifest for registry.gitlab.com/autowarefoundation/autoware.auto/autowareauto/amd64/binary-dashing:integration not found: manifest unknown: manifest unknown  So nothing is orking or me at the moment

( 2020-11-30 14:38:03 -0500 )edit

@Mackou We are in a period of heavy changes to both master and integration. It is likely that the demo will not work completely until we finish much of the current milestone and release the 1.0.0 version. Regarding the current situation:

Thechanges that were made to master while integration was also being modified necessitated us merging master back into integration. This broke the integration branch's builds which means no binary build of the integration branch has ever been completed and pushed to the new Docker registry location (the URL that says the manifest is unknown). I'll put together a quick patch to fix the build on integration but you should know that master is the target and where work is being done. However, as I said, I don't expect the demo to work fully until the current milestone is complete.

( 2020-11-30 14:48:03 -0500 )edit

Keep an eye on this CI job: https://gitlab.com/autowarefoundation...

Once it finishes, there will be a binary version of integration available and using ade on the integrationbranch should work again. However, there is no guarantee that the MS3 demo will work completely at this point and it isn't a current focus of development. If you would like to be involved in the current development, please join the Autoware Software Working Group. For details, see the [Autoware shared calendar[(https://calendar.google.com....

( 2020-11-30 14:58:09 -0500 )edit

@Josh Whitley Well thanks a lot for your efforts ! I will try to make it work a good as possible. I just want to have simple ndt loc + path following. You advise me to switch to master from now on or continue on integration ? Or by chance do you have a tag or commit that is known to have those functionalities ? If I'm useful then with pleasure ! :)

Thanks again !

( 2020-11-30 15:05:49 -0500 )edit

@Mackou I've fixed the SEGFAULT issue in https://gitlab.com/autowarefoundation..., which is going to master. Once it is merged into master, it will likely also need to be applied to integration. After that, integration should be capable of doing what you're looking for. However, the MS3 launch file launches much more than that. You're really looking for more of the functionality that we went for in MS2. Here is a set of steps that should get you up and running:

( 2020-11-30 17:39:42 -0500 )edit