Add world with moving platform #83
Conversation
mbjd
force-pushed
the
moving_platform_world
branch
from
33a7cfa to
f920472
Compare
There was a problem hiding this comment.
If possible I would import the default world instead of copying, like we did with x500 gimbal
It looks like other worlds were merged with the same build error 253. I vote for extending the tests to handle the worlds correctly, or is there a reason for not doing it @Jaeyoung-Lim? |
|
@perrrre I thought about that, would be very neat, but the SDF format spec says: What do you think about the following alternative? We load the default world, and have a separate platform.sdf containing just the platform model. Then we dynamically add it from GZBridge, switched on or off with an extra environment variable. This is essentially what I had implemented previously PX4/PX4-Autopilot@adabdf4 -- I considered it not so clean because we add an extra environment variable and more logic in GZBridge, whereas the current version only relies on specifying the right world. But I see that repeating the default world is suboptimal too. If you think that weighs more, I'm happy to revert the related changes. |
|
This should probably be a custom plugin. The GZBridge is meant to be a simple uORB <--> gz::transport bridge. I've been working on implementing custom plugins architecture, I'll get it merged today. I've also got a PR which refactors the GZBridge quite significantly. I will also merge it today. So my thinking is that this should be a new world that includes a "moving platform" plugin and your platform model.sdf. The plugin would be responsible for driving around your model. |
|
Can you take a look at this discussion from Ardupilot? Adding an actual ship/ocean would be the optimal way to do this plugin repo |
|
@dakejahl thanks for the input, and those perfectly timed merges! I agree a plugin is probably the way to go, will implement it that way. |
|
See here how to add plugins (no longer in world files) |
|
Marking this as draft while I get the plugin implementation sorted and wait for PX4/PX4-Autopilot#24441 to merge. |
|
I updated the PR with a plugin template, if you do go down the custom plugin route. @mbjd did you look at https://github.com/srmainwaring/asv_wave_sim? I think this would work perfectly. It will also help out others who are working on boats. @patrickelectric any interest in seeing a gz ocean world? |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
|
@dakejahl very cool, thanks for the plugin template, will start once merged. About the wave sim -- we are actually targeting generic moving platforms, not just boats specifically. As such we don't need/want very realistic boat movement (let alone graphics...) and are fine with a simplistic flat plate, driven by low-pass filtered white noise. Thanks though for the pointer to the ardupilot discussion, that definitely has some helpful bits of info! |
That would be great! |
floating a bit above the ground to avoid hitting it.
realistic boats don't move too much when a drone lands on it :)
just for developing the plugin. will change to new plugin infrastructure once PX4/PX4-Autopilot#24441 merges.
mbjd
force-pushed
the
moving_platform_world
branch
from
432333b to
73cb2ec
Compare
|
Un-drafting this again, ready for review :) Changes:
Still the default world is essentially repeated, the only difference being The plugin implementation on the PX4 side is working now, based on the brand new plugin infrastructure: https://github.com/PX4/PX4-Autopilot/tree/gz_moving_platform |
| <sensor name="navsat_sensor" type="navsat"> | ||
| <always_on>1</always_on> | ||
| <update_rate>30</update_rate> | ||
| </sensor> |
There was a problem hiding this comment.
the navsat sensor is not needed. See my comments in PX4/PX4-Autopilot#24471
|
@Jaeyoung-Lim yes, my apologies, should have waited for all reviews. Will make followup PR with changes addressing review. |
6 participants
Same as default world, but with a flat platform to simulate shipboard takeoff & landing.
It will not move on its own. Velocity can be set by publishing a
gz::msgs::Twistmessage to/model/flat_platform/link/platform_link/cmd_vel, containing velocity and angular velocity. The platform uses thegz::sim::systems::VelocityControlplugin to move when receiving these messages. Working example here.(the CI check complains that it is not a model SDF file. It's a world SDF file and as such does not need a
modeltop level element as checked in check_sdf.cc. It is also a valid SDF file in the first place, otherwise the check would exit even earlier and outputworlds/moving_platform.sdf is not a valid SDF file!. Should the check be disabled for worlds, or extended to handle worlds correctly?)