@Jaeyoung-Lim @dagar can you please give this a review? seems like a good addition

This will good and will need docs hint hint

@Jaeyoung-Lim is there anything preventing this from going in? I've addressed the comments so far. I think @hamishwillee is right that we will need a docs update after it goes in

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-feb-19-2025/43827/3

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-feb-19-2025/43827/1

@dirksavage88 As I commented above, you are configuring the physics only when a model exists.

However, physics is more of a world parameter and therefore should not be related to the model itself, but rather the world. For example, this would break if there are multiple vehicles in the simulation with the gz_bridge

Therefore I think it would be better if the config is done outside of gz_bridge.

@Jaeyoung-Lim I'm going push back and say this is a nitpick. What is the functional benefit to placing the physics outside of the gz_bridge? If you have no model and just a world, what is the functional benefit to having physics with nothing for physics to act on?

Also the world services are created in gz_bridge here:

Should not the physics also be configured along with the world services?

@dirksavage88 Yes, and that needs to change if we want to support multiple vehicles.

@Jaeyoung-Lim okay that is making sense now. So there should be somewhere else in the code where we can do both world services and physics.

@dirksavage88 Probably rethinking this - lets get this in as is, since I dont want to slow you down due to architectural improvements.

But lets put a note somewhere that we need to fix this, so that it flows nicely to multi vehicle support.

Also please create an issue to track this, make sure to assign yourself.

this would break if there are multiple vehicles in the simulation with the gz_bridge

So this only breaks if each px4-sitl instance has a different value for PX4_SIM_SPEED_FACTOR. Which is probably pretty easy to screw up. I don't think there's a way to set this directly in the world SDF though. I agree we should get it in now and fix later.

@dirksavage88 @Jaeyoung-Lim Re docs, is this as simple as updating https://docs.px4.io/main/en/simulation/#run-simulation-faster-than-realtime to mention Gazebo (GZ) supports this too?

Are there any specific things to think about that are different on GZ?

@dirksavage88 @Jaeyoung-Lim Re docs, is this as simple as updating https://docs.px4.io/main/en/simulation/#run-simulation-faster-than-realtime to mention Gazebo (GZ) supports this too?

Are there any specific things to think about that are different on GZ?

I think the COM_DL_LOSS_T param still applies, however I do notice that in the new gz with a speed up factor of 10x, I am not able to get local/global position to work. I am not sure if this was also the case for gz classic. I can get the x500 to arm in SITL with a speed up of 5x though

however I do notice that in the new gz with a speed up factor of 10x, I am not able to get local/global position to work

@dirksavage88 the issue is that this PR increases the time step rather than the real_time_factor. I have an open PR which is a large refactor of the the GZBridge and px4-rc.simulator which fixes this. If you want to try it out and leave a review!
#24421

Thanks very much.
Guys, when you merge something, please try update the docs. The chances of me missing stuff like this in autopilot PRs is high. I won't miss a PR against docs, even a trivial one.

Needs review: PX4/PX4-user_guide#3628