OK, could you check the RC8_TRIM value to ensure it is halfway between RC8_MIN and RC8_MAX? I think I saw something similar a few days ago myself and the issue for me at least was the way AP uses the trim value… We should potentially just ignore the _TRIM but let’s first be sure this is the problem.
… could you also check the RC8_DZ value?
… and finally if possible could you provide an onboard log file? It might be necessary to set LOG_DISARMED = 1 to allow producing an onboard log while the vehicle is disarmed.
I wonder if you managed to get the Gremsy gimbal working OK? There is a new -beta2 available now although there are really no differences with previous versions.
I’ve added this to our 4.3 issues list so I’m keen to get to the bottom of the issue.
I see you are sending AUTOPILOT_STATE_FOR_GIMBAL_DEVICE to the Gremsy gimbal.
Do you know if Gremsy is actually consuming AUTOPILOT_STATE_FOR_GIMBAL_DEVICE or whether you are simply future proofing the code for a time when Gremsy actually decides to use the information?
If so, do you know which fields the Gremsy is consuming?
The reason I am asking is I am writing a custom device driver for a non-autopilot device and it will take a lot of effort to compile the information for insertion into the message.
Thank you for getting that information so quickly. One last question, if you don’t mind. Does the gimbal also consume the ATTITUDE message? The reason I ask is that it contains duplicate roll, pitch, yaw information.
Which message gets used if both ATTITUDE and AUTOPILOT_STATE_FOR_GIMBAL_DEVICE are sent to the gimbal?
@juzzle1 I got SBUS RC working while receiving gimbal angles. But as far as I can tell, it only works with MAVLink Gimbal V1 (MOUNT_ORIENTATION, DO_MOUNT_CONFIGURE, DO_MOUNT_CONTROL), and NOT MAVLink Gimbal V2 (ATTITUDE_STATUS, GIMBAL_DEVICE_SET_ATTITUDE).
Because the gimbal still supports AP version lower 4.3, which AUTOPILOT_STATE_FOR_GIMBAL_DEVICE is not present, gimbal consumes both messages. But AUTOPILOT_STATE_FOR_GIMBAL_DEVICE has higher priority.
In your application, you can send ATTITUDE or AUTOPILOT_STATE_FOR_GIMBAL_DEVICE messages to the gimbal. But if an autopilot is present in the system, gimbal prefer consuming info from the autopilot.
Hi @rmackay9,
I’ve set up the gremsy S1V3 on gtune and on missionplanner as you wrote, when set on retracted mode and I right click on the map telling the gremsy to rotate it works, even the “DO_MOUNT_CONTROL” command sent using MAVproxy works for changing mode but not for roll, pitch and yaw (i know that this says it doesn’t work with that command, but I tried it anyway), then I tried using the “DO_GIMBAL_MANAGER_PITCHYAW” but it says it is an unsupported command HOLD> Got COMMAND_ACK: DO_GIMBAL_MANAGER_PITCHYAW: UNSUPPORTED
I’ve been trying to control the gimbal using mavlink messages by searching in forums, github, ardupilot pages but I can’t find anything that helps me and I don’t know how to make it work.
You’ve done a great work on Gremsy (there is not much documentation online) and ardupilot in general, thanks in advance for any help you’ll give us.
I think this vehicle is not running 4.3 because the relevant parameters all start with MNT_ but in 4.3 they’ve been renamed to MNT1_. Could you upgrade the vehicle to 4.3 and try again?
I’m actually surprised that the S1V3 accepts the mavlink interface because it’s not listed on our AP+Gremsy wiki page. I’ve asked our contact at Gremsy to confirm… but if you have it moving then it must be working.
Hi @rmackay9 and @amilcarlucas
thank you very much, now we’re running 4.3 beta for the Rover (the project is on a Rover) and now it works, BUT not properly:
COMMANDS(MAVproxy):
message COMMAND_LONG 0 0 205 0 x y z 0 0 0 2
message COMMAND_LONG 0 0 1000 0 z x float("NaN") float("NaN") 0 0 0
PROBLEMS:
roll doesn’t work → -40 < y < +40
pitch doesn’t work → -40 < x < +40
yaw doesn’t work → -41 < z < +41
When we try to run a Mavlink Command to make the Gimbal move as we want and we pick angles between that range (red area in the image) it goes back to the neutral position, any idea?
Note we’re using a Raspberry Pi connected to the S1V3 with Telemetry2
This version add MAVLink integration into the Ardupilot system (AP version 4.3 and above) and gimbal control over MAVLink and gTune connection in COM2, COM4, and micro USB ports.
Please try if it works
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).
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.
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.
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).
