# Bounding Box Error in 3D Perception Stack of Autoware.Auto

Hi,

I was trying to use the 3D Perception Stack in Autoware.Auto to generate bounding boxes and I was facing some errors. Below is the attached rviz2 visualization alongside the simulation.

In the picture above, the blue circle represents the bounding box and the red circle represents filtered point clouds. There are two issues that I am trying to resolve:

1. The bounding boxes appear to be fish-tailing (rotating inconsistently). I have tried to change the parameters inside the .yaml configuration (param) files for the point_cloud_filter node as well but it does not seem to fix that. I have tried to look at the .urdf for the Lexus vehicle for the robot state publisher and manipulate the parameters according to how the lidar is configured, but that does not seem to fix it either. This can also be seen in the bounding boxes on the right (trees) which constantly keep changing orientation.

2. The bounding boxes appear to NOT line up longitudinally with the filtered point clouds. I have NOT changed anything in the .yaml config file for the Euclidean cluster, so I am confused why the bounding boxes do not line up with the filtered points. I would understand if the filtered points do not line up with the actual object in the simulation (since they can be calibrated using the sensor_height_m and the static transform parameters) but that is not the case.

The filtered points (output of thepoint_cloud_filter node) seem to lineup with the simulation meaning that the translation parameters are somewhat correct.

Let me know why these issues are happening!

Thanks, Shlok

edit retag close merge delete

Sort by » oldest newest most voted

1. Given that we are currently only using a naive Euclidean Clustering algorithm, the orientation of the bounding box for each object can change as points are added and removed from the clusters. Frame-to-frame tracking or an ML-based algorithm would be required to better estimate object orientation. Both of these are on our roadmap for the upcoming Cargo Delivery ODD.

2. This is likely due to both lidar processing delays and transform delays. If you change the fixed global frame in rviz to base_link, you can offset the second type of delay. Regarding the first, we made a huge performance improvement to the ray_ground_filter just prior to the 1.0.0 release Sunday. Please pull the latest ade images by adding --update to your ade start command and test again.

more

Hi, I didn't know before, but now I've seen something similar. In my case, the bounding boxes are not wrong, they are simply very late. Autoware.Auto lags a lot when running on mid-end computers, especially the object detection part is heavy. I'm trying to get performance prioritized for the coming work on Autoware.Auto, see e.g this ticket.

Hope this helps,

Nikolai

more

Hi Nikolai,

Thanks for getting back to me. I am not sure if this is due to the computational load. My simulation environment is actually running on a different windows PC while Autoware.Auto is running on a separate Linux machine. Since both of the environments are running separately (on different systems), I am skeptical if this is because of the computational load generated by the 3D perception stack in Autoware.Auto

That being said, I would like to ask you a follow-up comment on that:

I think the point I mentioned about the longitudinal offset as #2 in my original question is related to the lagging of the bounding boxes in relation to the filtered point cloud data. I tried to run a separate scenario with only one vehicle in front (with a fixed distance and velocity) and the bounding boxes did seem to line up (however they were ...(more)

( 2021-02-19 11:03:16 -0500 )edit