You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A key thing to note here, is that the simulation crashes when trying to spawn two lidar instances (robots with lidar).
When the two lidar instances are a part of the world being launched - there is no problem here.
This situation is very similar to an issue I brought up about the gazebo reset: gazebosim/gz-sim#1904
Same situation where the crash happens when spawning the robot in but works fine when a part of the world sdf; I think this points to some sort of difference in handling the systems/sensors when it's being dynamically produced.
anyone@bob-the-not-so-plumber:~/hello$ gz sim empty.sdf
\libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
Warning [Utils.cc:130] [/sdf/model[@name="vehicle_blue"]/link[@name="link"]/sensor[@name="gpu_lidar"]/alwaysOn:./car.sdf:L55]: XML Element[alwaysOn], child of element[sensor], not defined in SDF. Copying[alwaysOn] as children of [sensor].
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
Warning [Utils.cc:130] [/sdf/model[@name="vehicle_blue"]/link[@name="link"]/sensor[@name="gpu_lidar"]/alwaysOn:./car.sdf:L55]: XML Element[alwaysOn], child of element[sensor], not defined in SDF. Copying[alwaysOn] as children of [sensor].
[Err] [SceneManager.cc:223] Visual: [ground_plane] already exists
[Err] [SceneManager.cc:223] Visual: [cool_lidar] already exists
[Err] [SceneManager.cc:223] Visual: [cool_car] already exists
[Err] [BaseStorage.hh:927] Another item already exists with name: sun
Stack trace (most recent call last) in thread 1098722:
#7 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in
#6 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fb9619269ff, in
#5 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fb961894b42, in
#4 Object "/lib/x86_64-linux-gnu/libstdc++.so.6", at 0x7fb95d0dc252, in
#3 Object "/home/anyone/gz-sim-fork/install/lib/gz-sim-7/plugins/libgz-sim-sensors-system.so", at 0x7fb8ccd300b7, in gz::sim::v7::systems::SensorsPrivate::RenderThread()
#2 Object "/home/anyone/gz-sim-fork/install/lib/gz-sim-7/plugins/libgz-sim-sensors-system.so", at 0x7fb8ccd2f9eb, in gz::sim::v7::systems::SensorsPrivate::RunOnce()
#1 Object "/home/anyone/gz-sim-fork/install/lib/libgz-sim7-rendering.so.7", at 0x7fb8ccc565c4, in gz::sim::v7::RenderUtil::Update()
#0 Object "/home/anyone/gz-sim-fork/install/lib/libgz-sim7-rendering.so.7", at 0x7fb8cccb39b8, in gz::sim::v7::SceneManager::CreateLight(unsigned long, sdf::v13::Light const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)
Segmentation fault (Address not mapped to object [(nil)])
The text was updated successfully, but these errors were encountered:
I noticed that you're including the Sensor system in your model. That system is meant to be used in the <world> tag, just like the Physics system. Does it crash if you remove it from your models and put just one Sensor system in the world?
Ahh yes, that was the issue thank you. This may also be the cause of the issue that I linked previously with the Reset – we're using a similar approach. I'll check and update that issue too
Environment
Description
Expected behavior:
The simulation doesn't crash
A key thing to note here, is that the simulation crashes when trying to spawn two lidar instances (robots with lidar).
When the two lidar instances are a part of the world being launched - there is no problem here.
This situation is very similar to an issue I brought up about the gazebo reset: gazebosim/gz-sim#1904
Same situation where the crash happens when spawning the robot in but works fine when a part of the world sdf; I think this points to some sort of difference in handling the systems/sensors when it's being dynamically produced.
Actual Behaviour
The simulation Crashed
Steps to reproduce
Here is the
car.sdf
gz sim empty.sdf
gz service -s /world/empty/create --reqtype gz.msgs.EntityFactory --reptype gz.msgs.Boolean --timeout 1000 --req 'sdf_filename: "./car.sdf", name: "car_1", pose: {position: {x: 0}}'
gz service -s /world/empty/create --reqtype gz.msgs.EntityFactory --reptype gz.msgs.Boolean --timeout 1000 --req 'sdf_filename: "./car.sdf", name: "car_2", pose: {position: {x: 10}}'
Output
Stack Trace
The text was updated successfully, but these errors were encountered: