Glad it’s working.
So message “205” is the older MAV_CMD_DO_MOUNT_CONTROL message which we don’t recommend except for changing the mode of the mount subsystem.
For moving the gimbal we recommend the MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW command as described in our MAVLink Interface wiki page here.
Hi @rmackay9,
We tested the message = 1000 MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW, it works thank you 
But the problem is on the ROLL of the Gimbal.
Since the first days the ROLL was tilted about +5 degrees.
With firmware 7.7.1 changing the OFFSET of the ROLL did not change anything (it stayed tilted).
With firmware 7.7.3 Preview the OFFSET appears set to the value 5.
If we try to change the value it starts to spin a wheel around the number but does not register it.
Maybe it is not the OFFSET that needs to be changed?
Maybe I need to change the ACCEL parameters? Or others?
We can’t straighten the horizon of the camera.
Could you please help us?
Hi @Crea,
Thanks for testing and confirming the the new mavlink command is working.
I’m afraid I don’t know how to fix the tilt but I don’t think it is AP related. My guess is it is some kind of calibration issue within the gimbal itself. I’ll ping one of the gremsy engineers to see if they can help but I can’t promise anything.
Txs again.
Hi @Crea, Thanks for your effort to test the beta firmware. Please contact support@gremsy.com so we can help you further.
Dear All & Dear @rmackay9, we hope this message finds you well. We are writing to inquire about connecting S1V3 Gremsy to CubePilot Orange. We currently have the TELEM1 and TELEM2 ports occupied and we’re wondering if there is another way to connect the Gimbal to a third TELEM port.
We are interested in using a CAN BUS port with the duplicator and would like to know which pins should be connected. The CAN BUS port has four pins: VCC_5V, CAN_H, CAN_L, GND (How-To connect them with S1V3).
Pin connection:
Solution A (Gremsy236 to CAN234)
Solution B (Gremsy236 to CAN324)
What parameters should we change in Mission Planner?
Can you provide any assistance in resolving this issue?
Thank you for your time and expertise.
We would like to apologize because we modifyed the previous message (we accidentally included arguments about a Raspberry Pi issue see: Discuss95870). We will be more careful in the future to ensure that our communications are clear and accurate.
Subject: Issue with MAVLink message using Node.js and Mavproxy
I am currently using Node.js to send MAVLink messages and Mavproxy as the ground control software. I have noticed that when I keep Mavproxy open and send a MAVLink message, it is received and I get the response Got COMMAND_ACK: DO_GIMBAL_MANAGER_PITCHYAW: UNSUPPORTED (even if the last time it gave me an “ACCEPTED”), on the other hand if with the mavproxy i run the command message COMMAND_LONG 0 0 1000 0 0 0 0 0 0 0 0 it gives me Got COMMAND_ACK: DO_GIMBAL_MANAGER_PITCHYAW: ACCEPTED.
If i run the command from the mavproxy command line it works fine, but when I was sending the message from node and got back and “accepted” result it didn’t move at all. Now i even receive “unsupported” when i run from node
parameters.param (15.3 KB)
This is our pixhawk configuration
Could you please provide some clarification on this issue and if there is anything I need to be aware of?
Thank you for your time and assistance.
Re the gimbal not moving, it would be good to confirm that the gimbal driver’s mode is MAVLINK_TARGETTING.
If the command works when sent from MAVProxy then I think the issue with running the same command from Node must be node specific. Maybe the messages takes a different route and the “unsupported” message is not coming from ArduPilot but instead from some other component of the system. I don’t know, it’s just a guess.
By the way, AP doesn’t support using DroneCAN for communicating with gimbals. Some gimbals will support CAN in the future but at the moment there aren’t even any DroneCAN message definitions for gimbals so we are at least a few months from adding support.
Hello @rmackay9 thank you for the help you are giving us.
Now the gremsy succesfully rotates but it is too fast.
I see on the MavLink messages page that i have to change param3 and param4 in orderd to slow it down, or in general chose the speed at which it moves.
I am using this library in order to send the messages, and it works fine, as you see I tried to put 1 on both param3 and param4 to get a speed of 1deg/s but it is really fast, especially when the pitch changes, I really don’t want it to break because of this. Do you have any idea on how to slow it down? Do i have to change some parameters on Mission Planner? Do I have to change some settings on GTuneDesktop?
Thank you in advance.
Hi @Crea,
I’m afraid that ArduPilot cannot specify the maximum speed of the gimbal so that will need to be done from within gTune. The DO-GIMBAL-MANAGER-PITCHYAW command has pitch and yaw rate fields but these are not meant to control the maximum rate of the gimbal. They specify the target rate when the gimbal is being controlled using pitch and yaw rates.
Hope that helps.
We tried making the S1V3 Gimbal movements smoother by adjusting parameters in GtunesDesktop, but still couldn’t get the desired result.
If anyone could help us solve this issue, we would greatly appreciate it.
HI @rmackay9,
We are seeking support regarding a slower (support@gremsy.com) as you suggested, but fundamental for us are also info about movement of the gimbal. It would be useful to have feedback on the gimbal’s angular position, for example using the message "
GIMBAL_DEVICE_ATTITUDE_STATUS
" or “MOUNT_STATUS”. We ask if you know if this works with Gremsy and some details, Thank you in advanced.
Yes, that should already work. The gimbal sends its attitude to the autopilot and then the autopilot sends that to the ground station.
By the way, we have this mount-poi lua script which can estimate the lat,lon and altitude of what the gimbal is pointing at.
Hi @rmackay9,
I have one question.
How can I obtain GIMBAL_DEVICE_ATTITUDE_STATUS message in dataflash log file?
I tried with Gremsy T3V3 but I cannot obtain that information in any log message. I hoped to find it in MNT message but I couldn’t find it
Somewhat amazingly, we’ve never logged the mount’s actual angles until recently. That code change is currently only in 4.5.0-DEV (aka “latest”). We may backport this change to 4.4.x but it’s not decided yet because there are just so many enhancements that backporting is slightly difficult.
In case you’d like to test “latest” it can be installed by going to MP’s firmware install screen and then press Ctrl-Q to switch to 4.5.0-DEV, then click on the appropriate icon to install. Note that while “latest” is generally safe it changes each day and hasn’t been through beta testing so it can have bugs.
Hello @rmackay9, I’ve been testing the Gimbal Gremsy T3V3, and I haven’t got a satisfactory control using Mavlink.
So, I decided to do some tests using Mavproxy. These are the commands that I’m sending, but the Gimbal behaves with an infinity rotation.
I want to command a specific angle using MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW (1000 ) (Based on this information Control a Gimbal / Camera Mount — Dev documentation )
No matter what I command, the Gimbal always describes an infinity rotation.
These are the firmware version:
Gimbal: firmware T3V3 v773
Autopilot Pixhawk 6C: ArduCopter V4.3.7
Thank you in advance for any help.
Finally , I found out the problem , and the Gimbal is working 
Care to share the solution with us?
Sure! @amilcarlucas ,It is needed to configure the Gremsy gimbal in angle instead of count If you are using a non-autopilot device MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW.
