search

srmainwaring / ardupilot_gazebo

GNU General Public License v3.0
3 stars 1 forks source link

Support for Fortress? #7

Closed clydemcqueen closed 2 years ago

clydemcqueen commented 2 years ago

Rhys -- thank you for this port. Much appreciated.

Any interest in hosting a Fortress branch? Basically the same as the Garden branch (so far), but of course the CMakeLists.txt would reference gazebo6, not gazebo7.

srmainwaring commented 2 years ago

Hi @clydemcqueen, yes - if we introduce a cmake command line variable we can support various versions in one branch which would be better.

Btw there is now an ArduPilot supported version of the plugin available here https://github.com/ArduPilot/ardupilot_gazebo, so I should put an archive note on this fork and a redirect.

There is also a set of example models in https://github.com/ArduPilot/SITL_Models (under the Ignition folder).

clydemcqueen commented 2 years ago

Thanks for the quick response!

Ah, I see that https://github.com/ArduPilot/ardupilot_gazebo already has a working Fortress branch. I'll work with that.

Thanks for the pointer to https://github.com/ArduPilot/SITL_Models.

I am working on a BlueROV2 model, updating the work in https://github.com/patrickelectric/bluerov_ros_playground. Is there interest in having this model in https://github.com/ArduPilot/SITL_Models?

srmainwaring commented 2 years ago

Is there interest in having this model in https://github.com/ArduPilot/SITL_Models?

Yes - I think it would be great to have a sub added to the set of models. At present we only include models that do not have any dependency on ROS, I'm not sure how this will work for you if you are using a model traditionally specified in xacro and spawned into Gazebo with launch files.

The other thought is providing support for the ArduPilot support for the thruster plugins - these may need some additional work to support (effectively we'd want to forward ArduPilot's PWM data for the relevant channels to the additional plugins. The easiest way to do this for general use would be add a control type that publishes the command value to a named topic which can be picked up by another plugin. My concern with this approach is that it may not be lock-step, as I am not sure if the messages published in the update step from one plugin are guaranteed to be received and processes by other plugins in the same physics update step (would need to look into pre-update, update, post-update etc and make sure that is all being dealt with consistently and correctly by the AP plugin and others).

As I think you've already spotted I'm working on some additions to Ignition for simulating marine surface craft - maybe not that relevant for subs aside from dressing up the visuals. The target is a more realistic surface model for boats and some hybrid situations such as interactions between flying craft on moving boats and possibly docking between marine vehicles. If you did want to get the BlueROV2 working with the early version of that I can certainly help.

clydemcqueen commented 2 years ago

I think it would be great to have a sub added to the set of models.

Excellent!

At present we only include models that do not have any dependency on ROS, I'm not sure how this will work for you if you are using a model traditionally specified in xacro and spawned into Gazebo with launch files.

Right now I'm focused on getting the Gazebo model to work. I may just copy the few bits I need in ROS into a separate URDF file.

The other thought is providing support for the ArduPilot support for the thruster plugins - these may need some additional work to support

Ah, interesting. Yes, this will require some investigation on my part. I'm new to ArduPilot & Ignition, so lots to learn.

As I think you've already spotted I'm working on some additions to Ignition for simulating marine surface craft

Yes, I've seen some posts -- very cool stuff!

Thanks for all your help. Feel free to close this issue. We can also connect in the various ROS forums (incl. Maritime Robotics), LinkedIn, etc.