feat(gimbal): support mount gimbal manager#27121
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| #ifndef EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
| #define EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
|
|
||
| #include <uORB/topics/external_gimbal_manager_set_attitude.h> |
There was a problem hiding this comment.
[error] clang-diagnostic-error [error]
uORB/topics/external_gimbal_manager_set_attitude.h file not found
minhleGremsy
changed the title
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 3696 byte (0.18 %)]px4_fmu-v6x [Total VM Diff: 3720 byte (0.19 %)]Updated: 2026-05-20T02:27:49 |
|
@julianoes Might be worth you looking at this? I would have thought this just a PX4 configuration issue. |
|
I currently have a full plate, so if this is urgent, Gremsy can consider sponsoring me to move this along. |
| #ifndef EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
| #define EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
|
|
||
| #include <uORB/topics/external_gimbal_manager_set_attitude.h> |
There was a problem hiding this comment.
[error] clang-diagnostic-error [error]
uORB/topics/external_gimbal_manager_set_attitude.h file not found
| #ifndef EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
| #define EXTERNAL_GIMBAL_MANAGER_SET_ATTITUDE_HPP | ||
|
|
||
| #include <uORB/topics/external_gimbal_manager_set_attitude.h> |
There was a problem hiding this comment.
[error] clang-diagnostic-error [error]
uORB/topics/external_gimbal_manager_set_attitude.h file not found
Hi @julianoes , currently, this feature is not urgent for us. However, we still look forward to your review. Do you have estimate time for the review? And which level of sponsor are required for this? Thank you |
|
@minhleGremsy I had a quick first look through the changes. Can you explain to me why the gimbal needs/wants to be a gimbal manager and not a device? Why is that required, or what additional features does that bring? I really want to understand this fully before reviewing. Also, how would we test this going forward? Could we create a gimbal manager for SITL? Also, please check the conflicts and clean up some of the commits that have unrelated changes. |
Hi @julianoes , thanks for your time. If you need hardware device for testing, we can lend it to you. |
|
Ok, that makes sense. I don't need to test it now, assuming you have tested it on your side. However, in the future, when there are gimbal-related changes, you will have to re-test it still works with your gimbal/camera. |
github-actions
Bot
added
kind:feature
|
Hi @julianoes thanks for your trust. We tested PX4 with our gimbal manager/gimbal device and QGC. The implementation follow MAVLink standard so it'd work with other smart gimbal as well. I resolved the conflicts. Please, help me review PR. This is our first PR in PX4, many things new |
|
|
||
| // Conflict occurs when PX4 itself acts as a gimbal manager while also communicating with an external gimbal manager. | ||
| if (px4_acts_as_gimbal_manager && connected_to_external_gimbal_manager) { | ||
| PX4_ERR("MNT_MODE_OUT=MNT_MODE_OUT_TO_GIMBAL_MANAGER is only compatible with MNT_MODE_IN=AUTO or RC."); |
There was a problem hiding this comment.
This is interesting. In theory, it should be possible to have two gimbal managers in a system: e.g. PX4 is a gimbal manager talking to its gimbal device while there is a second gimbal manager such as the integrated camera/gimbal.
Everything should then flow seamlessly through mavlink, so any gimbal command should just be sent or forwarded to the gimbal manager. I need to think more about that case.
There was a problem hiding this comment.
Hi @julianoes , that works in theory. But, PX4 default find a gimbal device with COMP_ID=MNT_MAV_COMPID which is default as 154, similar to most mavlink gimbal device. It might make the gimbal device confuse, so I made this to prevent this situation.
Also, PX4 always broadcast it as a gimbal manager even if it does not find any its gimbal device. I think this behavior is not correct.
There was a problem hiding this comment.
Also, PX4 always broadcast it as a gimbal manager even if it does not find any its gimbal device. I think this behavior is not correct.
Indeed, so that might be the first thing to fix.
There was a problem hiding this comment.
Hi @julianoes , I tried to fix the issue PX4 always act as a gimbal manager even when a gimbal device is not belong to it.
After deep dive to the code https://github.dev/PX4/PX4-Autopilot/blob/d5f5c503309c14321934602b037148cd3756c465/src/modules/gimbal/gimbal.cpp#L568-L569 I found params MNT_MAV_SYSID, MNT_MAV_COMPID are only use for gimbal protocol v1, which not support gimbal device discovering.
In gimbal protocol v2, https://github.dev/PX4/PX4-Autopilot/blob/d5f5c503309c14321934602b037148cd3756c465/src/modules/gimbal/output_mavlink.cpp#L191-L199 PX4 auto discover for gimbal device by gimbal_device_information, so it steal our gimbal device. Of course, we can modify our gimbal device to reject PX4 gimbal_manager message, but can not apply widely. I'd like to hear your thought about this. How would we decide which gimbal device below to which gimbal manager in a complex system with multiple gimbal or multi component want to act as gimbal manager. Currently, mavlink has not have any message field for the gimbal_device to public who is its manager.
Another comment, in our setup, our gimbal manager is successfully integrated with the GCS via standard mavlink GCS <-> gimbal_manger, tested with QGC and our NexGCS. We need integration to PX4, because we want to have manual control via RC input and control in a flight mission with precise control and gps. For now, PX4 support only one gimbal, if PX4 support mount to a gimbal manager, I think there is no meaning to keep PX4's gimbal_manager anymore. How do you think?
|
FYI: I'm looking into this now. |
|
@minhleGremsy I've looked into this and there are a few aspects we need to look at:
I have done some testing using a MAVSDK gimbal manager example, see: mavlink/MAVSDK#2921 |
In mission mode, the gimbal manager can handle ROI well. But for task like drone mapping, surveying. We need higher sync between gimbal operation, camera capture and drone position, so we prefer to have Autopilot control the gimbal manger in a flight mission, control gimbal attitude and trigger camera capture when reach a way point. Also, currently, when create a new flight mission from popular GCS like QGC, AFAIK, only generate way point and command target for the Autopilot, as payload side, we dont figure out any other way for the payload get the flight mission and sync the execution with the Autopilot. So, we think the Autopilot should be in charge to translate and send command to other components in the system. |
3 participants
Problem
Gremsy's smart camera gimbals implement their own gimbal manager and communicate directly with the gimbal device. PX4-Autopilot, however, also currently operates as a gimbal manager. As a result, both PX4 and Gremsy system manage the same gimbal control path, creating a role conflict that can lead to command ownership issues, duplicated control logic, and inconsistent gimbal behavior.
Solution
To solve this conflict, we introduce an output path for external gimbal managers instead of treating the downstream Gremsy system like a normal gimbal device. In this mode, PX4 does not act as the final gimbal manager anymore. It only generates mount setpoints and forwards them to the external gimbal manager.
On the output side, a new
OutputMavlinkToGimbalManagermodule discovers the external gimbal manager, checks control ownership, requests control when needed, and publishesexternal_gimbal_manager_set_attitudeonly after a valid manager is found and PX4 is allowed to send commands.On the input side, we add gating to reject invalid configurations where it would still act as a full gimbal manager while
MNT_MODE_OUTis set toMNT_MODE_OUT_TO_GIMBAL_MANAGER. Therefore, this output mode is only allowed withMNT_MODE_IN = AUTOorRC. In theAUTOcase,InputMavlinkGimbalV2switches to a mission-only mode. This keeps support forROIand mission-driven pointing, but avoids handling downstream gimbal-manager ownership commands inside PX4.Test Coverage
MNT_MODE_OUT=MNT_MODE_OUT_TO_GIMBAL_MANAGERis used withMNT_MODE_IN=MAVLINK_ROI,MAVLINK_DO_MOUNT, orMAVLINK_V2.MNT_MODE_IN=AUTOandMNT_MODE_IN=RC.AUTO+MNT_MODE_OUT_TO_GIMBAL_MANAGERto confirmInputMavlinkGimbalV2runs in mission-only mode.DO_GIMBAL_MANAGER_CONFIGUREis ignored in mission-only mode.GIMBAL_MANAGER_INFORMATIONuntil an external manager is detected.sysid,compid, andgimbal_device_id.GIMBAL_MANAGER_STATUSupdates for primary, secondary, and no-control cases.ACCEPTED,IN_PROGRESS, rejected), retry limit, and 15s backoff behavior.