autoware_rviz_plugins/BoundingBoxArray failed to load on ade foxy
I am trying to run object detection demo of AutowareClass on ade foxy environment. If I run the following command, rviz2 started correctly, but the vehicle mesh was not imported correctly and the lidar points were not displayed correctly.
runtao@ade:~$ rviz2 -d /opt/AutowareAuto/share/autoware_auto_examples/rviz2/autoware_perception_stack.rviz
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-runtao' [INFO] [1604751402.293935945] [rviz2]: Stereo is NOT SUPPORTED [INFO] [1604751402.294147922] [rviz2]: OpenGl version: 4.6 (GLSL 4.6) [INFO] [1604751402.328090400] [rviz2]: Stereo is NOT SUPPORTED [ERROR] [1604751483.305751195] [rviz2]: PluginlibFactory: The plugin for class 'autoware_rviz_plugins/BoundingBoxArray' failed to load. Error: According to the loaded plugin descriptions the class autoware_rviz_plugins/BoundingBoxArray with base class type rviz_common::Display does not exist. Declared types are rviz_default_plugins/Axes rviz_default_plugins/Camera rviz_default_plugins/FluidPressure rviz_default_plugins/Grid rviz_default_plugins/GridCells rviz_default_plugins/Illuminance rviz_default_plugins/Image rviz_default_plugins/InteractiveMarkers rviz_default_plugins/LaserScan rviz_default_plugins/Map rviz_default_plugins/Marker rviz_default_plugins/MarkerArray rviz_default_plugins/Odometry rviz_default_plugins/Path rviz_default_plugins/PointCloud rviz_default_plugins/PointCloud2 rviz_default_plugins/PointStamped rviz_default_plugins/Polygon rviz_default_plugins/Pose rviz_default_plugins/PoseArray rviz_default_plugins/PoseWithCovariance rviz_default_plugins/Range rviz_default_plugins/RelativeHumidity rviz_default_plugins/RobotModel rviz_default_plugins/TF rviz_default_plugins/Temperature rviz_default_plugins/Wrench
Also, If I source /opt/AutowareAuto/setup.bash, it returns bash: /opt/AutowareAuto/setup.bash: No such file or directory, because there's no AutowareAuto repository under /opt on ade.
If I run this demo on default ade dashing environmnt, it works properly, so I beliveve there's something missing in foxy environment. Any idea how to solve this?
Added: the output of displaying lidar points:
runtao@ade:~$ source AutowareAuto/install/setup.bash; ros2 run velodyne_node velodyne_cloud_node_exe --model vlp16 __ns:=/lidar_front __params:=/opt/AutowareAuto/share/velodyne_node/param/vlp16_test.param.yaml [WARN] [1604853903.473366050] [rcl]: Found remap rule '__ns:=/lidar_front'. This syntax is deprecated. Use '--ros-args --remap __ns:=/lidar_front' instead.
expected [string] got [not set]
Hello, @runtao! Thanks for using Autoware! Unfortunately, ROS Foxy support is still experimental and the environment is not complete. The
adeimage is available and the source code will compile but many tests still fail. For this reason, the pre-built binary volume that is attached to/opt/AutowareAutoin the Dashing environment is not yet available in Foxy.You have listed several problems here and the above explains the issue with the
No such file or directoryas well as the vehicle mesh (the URDF file requires a hard-coded path to the mesh file which currently points to the one normally installed to/opt/AutowareAuto/share). However, this does not explain why the lidar points are not being displayed. Can you please provide the output of the commandsros2 node listandros2 topic list -t?Hi @Josh Whitley, thanks for reply! Sorry forgot to add the output of displaying lidar points, I have just added it above. Since I cannot source /opt/AutowareAuto, I just source the overlay, but the velodyne_node still cannot get started.
Anyway, it seems like the foxy enivronment is not ready yet for such a demo as well as lgsvl, right? Do you have a time schedule on it? Btw, very appreciated for the improvement to foxy!
@runtao Yes, you are correct - this is an issue that has not yet been corrected for the Foxy environment. Unfortunately, I do not have a good timeline yet because Foxy support is only experimental until we begin working on our next development cycle (probably sometime around February). We are happy to accept fixes in merge requests! Since this problem is a direct conflict between Dashing and Foxy APIs, I recommend creating a copy of the launch file and adding the Foxy fixes. We need to maintain Dashing compatibility until our current development cycle is over.