Closed machar94 closed 6 months ago
Commit: bdeafba
I'm observing the same behaviour (though not for the exact script you've provided, I have separately hit the issue). Similar to what you've observed, this only affects some spawned agents of particular classes. The problematic classes I've encountered are:
vehicle.bh.crossbike
vehicle.diamondback.century
vehicle.harley-davidson.low_rider
vehicle.gazelle.omafiets
vehicle.kawasaki.ninja
vehicle.yamaha.yzf
I believe all of these are two-wheelers.
I had the same issue with the last release 0.9.11, also just with 2Wheeled.
@doterop would you be able to have a look at this please?
observed the same issue, i was thinking about assigning a fixed value for that dimension (since all pedestrians have the same extents values) and solve that way. Would you mind sharing any alternative solution you found, if any? Thanks
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is still persistent with 0.9.13 version too. It is only with 2-wheelers. Due to this y = 0 extent, the bounding box could not be plotted when we project the 3D bounding box to 2D pixel wise bounding box.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Saw the same issue in 0.9.13. Any suggested workaround like what @rossivalen mentioned?
I had the same issue with the last release 0.9.13, also just with 2Wheeled.
@bernatx This needs your attention. There are multiple reports of this, e.g. https://github.com/carla-simulator/carla/issues/3801 and they are still perfectly valid in recent Carla versions (tested on 0.9.13 and 0.9.14).
On 0.9.13 all 2-wheel actors have zero y size of the bounding box, on 0.9.14 it is even worse, both x and y are zero. Furthermore the bounding box location if often very much off in the y-axis.
Please assign to a colleague that is still active in the project.
收到了!谢谢!
Hi, We are checking the bug. It seems that the bounding of the bike itself is correct, but when we try to add the bounding of the rider, it is done incorrectly. We are fixing that.
Thanks for warning about that.
Hi, We are checking the bug. It seems that the bounding of the bike itself is correct, but when we try to add the bounding of the rider, it is done incorrectly. We are fixing that.
Thanks for warning about that.
so, which version can be used?
Same for me using version 0.9.14. Does anyone know how to fix this?
Please find a solution to this problem. Does anyone checks if it is still the same on 0.9.15 ?
carla 0.9.15 is fine
Hi,
as of 0.9.15 does anyone still have issues with this?
Marcel
0.9.15 no issues
------------------ 原始邮件 ------------------ 发件人: @.>; 发送时间: 2024年5月10日(星期五) 晚上10:05 收件人: @.>; 抄送: "Zhang @.>; @.>; 主题: Re: [carla-simulator/carla] Some bounding box extents are 0 in Y axis (#3670)
Hi,
as of 0.9.15 does anyone still have issues with this?
Marcel
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Please find a solution to this problem. Does anyone checks if it is still the same on 0.9.15 ?
Yes, I think there is the same problem on v0.9.15
Carla version number: 0.9.10.1-112-g993f440b Commit: 993f440bb804f22ec4e94653e1dd97fb0ce6babc Platform/OS: Ubuntu 18.04.4 LTS
I have observed that some obstacles (mostly 2 wheelers) have an extent in the Y dimension of 0. I noticed this in my Carla/Apollo integration when the bounding boxes in the visualizer appeared distant and only in 2D. I modified the spawn_npc.py script (provided below) to print out the bounding boxes of any actors that reported a value of 0 in any of the axes. In addition, with the release of 0.9.10 I saw that bounding boxes can be obtained globally from the world object. I also checked whether there were any bounding boxes from the get_level_bbs method of world that also have a 0 extent value in any of the directions and there are none! Below is the output of the modified spawn_npc.py script for 1 tick. I have called out in bold the 0 extent values and if you see the relative location for those bounding boxes they appear to be greatly off in the y axis. In addition, out of all of the printed global bounding boxes (filtered for vehicles - not sure why there are more than 10 when I requested 10 vehicles), I am able to match the actor to the bounding box with proper extents since the location of those bounding boxes are in global coordinates. Out of 10 harley davidsons requested 3/10 were defective. This proportion changes as I vary the number of requested vehicles. I know this commit is about a month behind the head, but I was hoping if someone could quickly run the spawn_npc.py script I've provided and comment on whether they observe a similar issue with the bounding box extents. The proportions at the end of the tick output reflect the number of defective bounding boxes detected with each method.
spawn_npc.py
How I run the spawn_npc.py script.