Since the update in November my panorama mission is not working anymore. I use a relative condition-yaw command to turn the copter for every column and a do_mount_control for every row of pictures. Since November, I guess update “Copter 3.6.1 10-Nov-2018 / 3.6.1-rc1 06-Nov-2018”, the yaw value of the do_mount_control (I only have a two axis gimbal) yaws the copter itself. The result is, that the copter is always (after a short yaw try) reorientated towards 0 degree/north.
So I asking myself now whether I discovered a bug or a feature?! If it is a feature, is there a relative setting for the “mount yaw”?
I also tried my missions in the simulator with the latest firmware and got the same result.
do mount control should only yaw the copter if the gimbal does not provide yaw movement.
Check your gimbal parameters, if you disabled the gimbal yaw channel, the copter itself will yaw.
Thank you vey much, you are right, if I change the setting for the yaw gimbal output the copter starts to turn again (in the simulation).
Anyhow, if there is no relative yaw for the gimbal in the current implementation I think I cannot use the so_mount_control command but I will have to switch to set the servo pwm instead. Or is there a switch to change he setting to relative?
With absolute I mean that 0 degree eqauls a heading towards north and 180 degree equals south. 0 degree means that the copter turns towards north.
With relative I mean relative to the current position. So 90 degree would not result in an orientation towards east but to a 90 degree turn relative to the current position. 0 degree would mean no movement.
A relative movement is only way to make use of the do_jump command and save significant time when writing the mission. My panorama mission is based on 13x 30 degree movements to turn the copter.
Enabeling a gimbal yaw output which does not exist in order to get back the relative yaw behavior does not feel right to me. The absolute gimbal behavior is new since November. Before that the same mission worked flawlessly many times.
I think what you need is a feature that doesn’t exist yet. Neither mavlink command nor mission command DO_MOUNT_CONTROL have a parameter to select relative vs earth framed yaw like CONDNITION_YAW does.
It probably wouldn’t be difficult to add the functionality. There are no available parameters in DO_MOUNT_CONTROL, which would have been ideal. So it would require adding a parameter to the mount library such as MNT_YAW_FRAME where 0 is earth (no change from now) and 1 is vehicle orientation.
given that according to the TO it went from working to non working from one day to the other, and the TO’s description of the problem, I would not think that the problem is due to a non existing mavlink message feature but due to has_pan_control and it’s changed handling, as the TO indeed also found. Since this is a property of the gimbal it should get a parameter to set it, and since there had been such and such kinds of gimbals since ever there should have been such a parameter since ever. It’s pointless to have a has_pan variable which modifies the behavior and have no user way to set it. Seems the TO has discovered what is both a feature and a bug .
Alternatively one also could remove the pointless has_pan_control and extend the mavlink capabilities, which might be considered cleaner, but will break older scripts.
Note however that neither approach would solve the general underlying logical conflict that the copter’s yaw and the gimbal’s yaw are in fact different properties but are sometimes wanted to be treated as the same. For instance a gimbal’s yaw can be put into hold and follow mode, which would require different behavior again. So, for a correct complete solution one would need an extended mavink message but also a means to specify if the copter’s and gimbal’s yaws are linked or not, and for the latter it should be possible to specify it permanently, like has_pan parameter and change it dynamically to allow for hold vs follow changes.
ok, thank you all!
I use a STorM32 NT gimbal, it works great “out of the box”, I didn’t even allocate more than 10 min. for tuning because I’m really satisfied (only 2 axis to save weight)
Yesterday I tested my panorama mission again with the non existing yaw/pan axis of the gimbal activated (by selecting a unused servo output). With this settings, the original mission is working again as it always did. So I guess olliw right, it is
So I think to have a “fake” yaw/pan axis is a workaround for the issue, but I would be great to extend the existing mavlink message (or to realize any further improvement, I think in the long run it is good to solve logical conflicts as soon as possible).
I’m not seeing where adding to MAV_MOUNT_MODE is practical. Whether the mount has pan control, and whether you want reletive vs earth framed yaw is not a mount mode. The mount modes are gps pointing, mavlink targeting, rc control, etc. Pan axis options are not modes separate from those. They’re are options that could apply to any of those modes.
Yaw relative vs earth framed yaw would be best as a parameter in the DO_MOUNT_CONTROL command, but all 7 parameters in that command are used.
I’m not sure how else to do it without a vehicle parameter in that case.
