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.
1 Like
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.
1 Like
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.
Maybe try emailing gremsy support? support@gremsy.com
2 Likes
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 
2 Likes
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.
@Peterarnold Did you find a solution ? I have similar problem with new Pixy LR gimbal. When it’s working via Mavlink and it is in “follow mode” it has very jerky yaw…in SBUS everything works ok.
No I didn’t get it solved but that was before the testing finished and I expect there has since been firmware updates. Its sitting on a test rig so I will try again.
When I connect Pixy LR gimbal via mavlink with instructions and connection cables from Gremsy:
I can control the gimbal but I can’t control the camera…
When I set everything with Entire R3 (to control the camera) and Herelink and MavCam app, sometimes gimbal gets crazy sometimes works…and when it’s working and following the drone in yaw it is vibrating in pitch…The manual for setting the gimbal is here:
What is more interesting the gimbal can be also controlled by SBUS but in that mode “Pitch” doesn’t go to full 90 degrees The maximum pitch is 85-87 degrees down 
Hi @norim,
Our Gremsy setup instructions are here on the AP wiki but I don’t know of any core developers that have confirmed that the Entire works so it’s not too surprising that there are issues. I do actually have a really old Entire that I’ve been meaning to upgrade and test.
FYI @CraigElder
I did second try with Gremsy and Entire… and I changed all Servo9_Parameters - Servo16_Parameters parameters to 0 and all RC_Options also to 0. I also changed INS_LOG_BAT_OPT from 2 to 0.
Others parameters are:
SERIAL1_PROTOCOL: “Mavlink2”
SERIAL1_BAUD: “921600“
MNT1_DEFLT_MODE: “3”
MNT1_TYPE: “6”
CAM1_TYPE: “5”
Entire Firmware: 1.874
Arducopter firmware: 4.4.4
and the gimbal and Entire R3 started to work in Mavlink. I can control the gimbal and camera via MavCam in Herelink. Gimbal is stable not like before.
From time to time during initial boot of the copter control of the camera doesn’t work but if I reboot everything works.
Also when gimbal is in “Mavlink mode” I can’t find it in gTune Desktop and I can’t connect via USB to my PC computer. If I disconnect the serial port from Cube Orange and gimbal changing it’s mode to Herelink/Sbus I can connect the gimbal via gTune desktop. The problem is that gimbal doesn’t remember the settings for “Mavlink mode” when it’s connected via “Herelink mode”. I sent this second problem to Gremsy.