Look at the title of this post: T7 7.7.1 requires ArduCopter 4.3-x.
Hi @naturobotic,
Re MAVProxy’s message, did you type in “module load message” first?
On the wiki page linked it says this:
The example commands below can be copy-pasted into MAVProxy (aka SITL) to test this command. Before running these commands enter:
- module load message
Maybe the formatting of this was not clear? Maybe I should move the “module load message” up so it’s not a bullet point.
By the way, I think investigating in getting an RC transmitter/receiver is a good idea. flying a drone without any RC is somewhat dangerous especially if you haven’t flown it before. It will also make the setup much easier.
1 Like
Hello I test following this post upgrading gimbal t3v3 and autopilot with 4.3beta. It works relly better than before in auto mode and in speed mode.
Just for this who want to use rc in angle mode with rc pot, the gimbal still not reacting proportionality to the pot for pitch for example.
Can you check this feature for feedback?
1 Like
Hi @kuspower,
Txs for testing the new Gremsy gimbal driver. So you’re saying that the gimbal’s actual pitch is not reaching the limit you expect? I suspect the issue is a mismatch between the gimbal’s internal pitch range and the MNT1_PITCH_MAX parameter. I have added this to the 4.3 issue list for investigation and I will test on my own vehicle but if you have a log file that might also be useful.
Txs again.
Hello Randy, no is not this behavior.
The gimbal achieve min max angles so no issue on this sides.
Pitch Min max are 90. -90.
Pot is set on Rc8 1000-2000us no dead band.
So pot set to 1500 gimbal is at 0 perfect
If pot is set between 1500 1750 or 1250 1500 nothing.
If pot is set to 1751 or 1249 gimbal axes ±45deg directly.
Over this values we have expected proportional behavior.
So its impossible to pitch between 1 to 44 or -1 -44 deg
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.
Hi @kuspower,
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.
Hi @rmackay9 ,
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
Troy
The gimbal really consumes AUTOPILOT_STATE_FOR_GIMBAL_DEVICE for better state estimation. We use q[4] and feed_forward_angular_velocity_z.
For more information, you can ping support@gremsy.com for more information.
Hi @Minh_Le
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?
Best,
Troy
@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).
You need to update the gimbal firmware for that to work
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.
TEST_001.param (13.7 KB)
2 Likes
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?
2 Likes
You need to use the latest Gremsy firmware on the gimbal and the latest ArduCopter 4.3.2 firmware on the flight controller.
Have you done that?
2 Likes
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.
2 Likes
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
Thank you in advance for any help
1 Like
Hi @rmackay9, @amilcarlucas and @Crea ,
Interesting discussion about Gremsy, you could try:
First install gTune Desktop preview gTuneDesktop v1.4.9.0 - Preview
Than install manually gremsyS1V3_v773_Preview
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
2 Likes
Hi @rmackay9, @amilcarlucas and @robertocalvi ,
Our test was:
- Mavproxy with TCP connection (in our case)
mavproxy.py --master=tcp:0.0.0.0:5760 --baudrate=115200
- Wrote the command:
module load message
- Replaced x,y,z in “message COMMAND_LONG 0 0 205 0 x y z 0 0 0 2”
(with x=Pitch/Tilt, y=Roll and Z=Yaw/Pan)
For example:
message COMMAND_LONG 0 0 205 0 10 39 -10 0 0 0 2
Works! 
Thank you to the team for help!
1 Like