Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GZ: Add gimbal device #23382

Merged
merged 1 commit into from
Dec 18, 2024
Merged

GZ: Add gimbal device #23382

merged 1 commit into from
Dec 18, 2024

Conversation

StefanoColli
Copy link
Contributor

@StefanoColli StefanoColli commented Jul 10, 2024

Feature

Gimbal device to be controlled in SITL environment when using gazebo simulator (gz-garden). The device can act as a Mavlink gimbal (following Mavlink gimbal protocol v2) or as a non-Mavlink gimbal (responding to gimbal_controls messages) depending on MNT_MODE_OUT PX4 parameter.
It supports both angle and angular rate commands, it doesn't support yet the gimbal device flags (WIP).
It is meant to work with the gz_x500_gimbal model (PX4/PX4-gazebo-models#47).

Test coverage

Tested with QGC

WIP

The submodule Tools/simulation/gz is temporarily pointing to https://github.com/StefanoColli/PX4-gazebo-models waiting for
PX4/PX4-gazebo-models#47 to be merged into main.

Context

x500_gimbal2

gimbalQGCm.mp4

@lierdakil
Copy link

What's the status on this? I.e. why is it drafted? I kinda want a SITL gimbal real bad, hence asking whether this (mostly) works or if it's not ready at all.

@Jaeyoung-Lim
Copy link
Member

@lierdakil You can already try out the current status?

@StefanoColli
Copy link
Contributor Author

@lierdakil It is drafted because you would need to use my PX4-gazebo-models fork instead of the PX4 default one. But most of the functionalities are there except from the gimbal device flags as stated in the PR message

@lierdakil
Copy link

@StefanoColli thank you very much for the reply, that sounds great! I'll be trying this branch out shortly, then.

@lierdakil
Copy link

So this works great, but apparently the gimbal in the model is installed with the neutral position pointing backwards. I've rotated it 180⁰ in the model, and everything is fine, but was this intended?

@0uterspaceguy
Copy link

Cant make it work with qgc. Can you share parameters settings?

@lierdakil
Copy link

lierdakil commented Aug 17, 2024

Sorry, I didn't use qgc, I'm interfacing with it from software via mavlink.

But qgc v 4.4 has added some gimbal controls, which kind of work.

For one, there are some buttons at the top (click the joystick-looking thing to the right of the battery indicator)
image

If you've also enabled video in qgc, then "on Screen Camera Control", or at least "click to point" will work when you switch to the video feed.

image

(whether you actually have some video there is irrelevant)

That said, it seems pitch is inverted between qgc and px4, the camera very stubbornly pitches upwards instead of downwards (this may be my modifications to blame though). Also, the yaw indicator on the map is messed up, apparently the yaw angle shown is the sum of the frame's yaw and camera's yaw relative to the frame. So things are rough around the edges.

@Jaeyoung-Lim
Copy link
Member

@StefanoColli Any updates regarding this PR?

@Jaeyoung-Lim Jaeyoung-Lim mentioned this pull request Aug 26, 2024
30 tasks
@StefanoColli
Copy link
Contributor Author

StefanoColli commented Sep 13, 2024

So this works great, but apparently the gimbal in the model is installed with the neutral position pointing backwards. I've rotated it 180⁰ in the model, and everything is fine, but was this intended?

@lierdakil Are you sure about that? because in QGC I see that the gimbal in neutral position is correctly pointing forward...

@StefanoColli StefanoColli marked this pull request as ready for review September 13, 2024 15:27
@lierdakil
Copy link

lierdakil commented Sep 17, 2024

Are you sure about that?

Well, the actual video feed from the simulated camera (captured with ROS) does not point in the direction the drone flies in when the pitch stick is tilted forward. Also, the model visibly points backwards in Gazebo. When SITL first starts up, you're not looking at the front of the drone, you're looking at its butt 😅

P.S. Disclaimer: I didn't actually check the version that got eventually merged, but this was the case at the time I wrote the original comment. So take this with a grain of salt.

@hamishwillee
Copy link
Contributor

hamishwillee commented Sep 18, 2024

When this is ready can we please have some docs. Specifically and addition to https://docs.px4.io/main/en/sim_gazebo_gz/vehicles.html and to the list here: https://docs.px4.io/main/en/sim_gazebo_gz/#running-the-simulation

Also in https://docs.px4.io/main/en/sim_gazebo_gz/ a new section "Simulating a Gimbal" that explains how you set up gazebo/PX4 to use this, and how it can be tested.

What we need is enough information so that someone can run a turnkey set of instructions and then send MAVLink commands to a gimbal-protocol v2 compliant gimbal manager and drive the simulation. QGC has that implementation, at least in part, so should be a good first test point. MAVSDK too.

@anaam-wingxpand
Copy link

Are you sure about that?

Well, the actual video feed from the simulated camera (captured with ROS) does not point in the direction the drone flies in when the pitch stick is tilted forward. Also, the model visibly points backwards in Gazebo. When SITL first starts up, you're not looking at the front of the drone, you're looking at its butt 😅

P.S. Disclaimer: I didn't actually check the version that got eventually merged, but this was the case at the time I wrote the original comment. So take this with a grain of salt.

I am also seeing that the camera is pointing towards the butt of the drone. This is with the model that was merged.

@anaam-wingxpand
Copy link

anaam-wingxpand commented Nov 21, 2024

I had to add pi/2 to the yaw setpoint command to get it to "ROI at location" correctly via QGC.

In GZGimbal.cpp: publishJointCommand(_gimbal_yaw_cmd_publisher, static_cast<float>(M_PI_2) + _yaw_stp, _yaw_rate_stp, _last_yaw_stp, _yaw_min, _yaw_max, dt);

@Perrrewi
Copy link
Contributor

When this is ready can we please have some docs. Specifically and addition to https://docs.px4.io/main/en/sim_gazebo_gz/vehicles.html and to the list here: https://docs.px4.io/main/en/sim_gazebo_gz/#running-the-simulation

Started a draft here: PX4/PX4-user_guide#3496

@Jaeyoung-Lim
Copy link
Member

@StefanoColli Any updates?

@StefanoColli
Copy link
Contributor Author

I re-based my commits on top of master and then I need to open a PR in PX4-gazebo-models to fix the orientation of the gimbal

@Jaeyoung-Lim
Copy link
Member

Jaeyoung-Lim commented Dec 13, 2024

@StefanoColli Could you do it such that we can wrap this up?

Have you tested this with the QGC version that is available for the public as well?

@StefanoColli
Copy link
Contributor Author

Here is the PR in px4-gazebo-models that fixes the gimbal default orientation and isolates the gimbal model in an independent component so that it can be used in other vehicles.

@Jaeyoung-Lim Yes I have tested it with QGC v4.4.3

Perrrewi
Perrrewi previously approved these changes Dec 17, 2024
Copy link
Contributor

@Perrrewi Perrrewi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the gimbal model, will be useful!

We decided to add enums in another commit to wrap this up.

@sfuhrer sfuhrer changed the title Add gimbal device GZ: Add gimbal device Dec 17, 2024
Copy link
Contributor

@Perrrewi Perrrewi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gimbal is pointing in front aligned with the vehicles front and the small fixes are updated. I tested it with QGC and it works to change the gimbal attitude by clicking in the GCS window, and by sending commands via MAVLink Console.

@Perrrewi Perrrewi merged commit 0561f6c into PX4:main Dec 18, 2024
55 of 57 checks passed
mbjd pushed a commit to mbjd/PX4-Autopilot that referenced this pull request Dec 18, 2024
@michele-colombo
Copy link

Hi, thank you so much for this addition, I'm going to use it soon!
I just have a couple of clarification questions. My understanding is that you simply load the x500_gimbal model in Gazebo sim (using make px4_sitl gz_x500_gimbal for instance) and you're ready to send commands to gimbal, without any further configuration required. Is that right?
Currently I'm using uXRCE-DDS to communicate between ROS2 and PX4 (for sending commands to the drone and receiving data from the drone). I cannot see gimbal msgs in the yaml of uORB/ROS2 mapped topics. In order to use ROS2 msgs for controlling the gimbal and receiving gimbal attitude, is it enough to add the corresponding mappings in that yaml file?

@StefanoColli
Copy link
Contributor Author

@michele-colombo yes, just use make px4_sitl gz_x500_gimbal and you are good to go. You might also want to adjust MNT_* PX4 parameters to your needs.
Regarding the uXRCE-DDS part, it should be enough to add the messages to the yaml file as you wrote.

@michele-colombo
Copy link

Hi, thank you!
Yes, I can confirm that just by modifying the yaml file you have the uORB topics mapped to ROS2 topics. I'm able to command the gimbal by sending ROS GimbalManagerSetAttitude msgs on /fmu/in/gimbal_manager_set_attitude and receive the gimbal's attitude on /fmu/out/gimbal_device_attitude_status.
The only problem is that the camera is not stabilized. I think flags are not managed, so it should not be a problema of how flags are set in the GimbalManagerSetAttitude msg. What could be the problem?

@Jaeyoung-Lim
Copy link
Member

@michele-colombo Please do not hijack the topic of this thread. If you have a question/issue please open a new issue

JoelJ18 pushed a commit to microstrain-robotics/PX4-Autopilot that referenced this pull request Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants