Gimbal limits with SToRM32 backend (MAVLink) not applied correctly?


I’m having trouble with a MAVLink controlled gimbal (basecamelectronics firmware) with AC4.0 where the applied angle commands from RC are limited to a wrong range. Same setup works well on AC3.6.12.

The parameters are following:
MTN_ANGMIN_TILT = -9000 (-90 degrees)
MTN_ANGMAX_TILT = 1000 (+10 degrees)

Software limits on gimbal:
Tilt axis low: -90 degrees
Tilt axis high: +15degrees

On 3.6.X the gimbal works like expected with these settings mentioned above. On tilt axis, it can point -90 degrees down and +10 degrees up.

On 4.0 the gimbal range is limited to -90 deg to -40 deg with these same settings. Note that I don’t know if the autopilot is commanding angles lower than -90 deg as it is limited by the gimbal software and hardware.

Using MTN_ANGMAX_TILT = 11000 (+110 degrees) and MTN_ANGMIN_TILT = -9000 (-90 degrees) gives the wanted control range of -90 to +10 degrees.

I checked the MAVLink messages with Qgroundcontrol MAVLink inspector and found that MOUNT_STATUS message, which contains the commanded angles, has limited range.

It should have the range from -90 to +10 degrees, but the commanded range is only -90 to -40 degrees.


This message is made here:

And the following angle set here on RC control:

Can anyone spot where the cause for the problem is?

I have replicated the function on this line and got following results that match the Gimbal output I have got:

Here the angle_max=10 and angle_min=-90 which gives us a range of -0.9 to -0.4 -> -90 to -40deg

Here the angle_max=110 and angle_min=-90 which gives us a range of -0.9 to 0.1 -> -90 to 10deg

So the problem is in that function.


Great, thanks for the report and investigation. I hope to investigate this next week.

1 Like

@VDLJu Thanks for the analysis.

Just starting to look at this.

First thing I’d note is that that range on f appears to be incorrect. You need to remove the *0.5 or change the range from 0 to 2. f here is (rc->norm_input() + 1.0f) and given norm_input returns -1 to 1, the range is 0-2.

Some parenthesis in the original code might have made it a bit clearer what was going on (changing a range of -1 to 1 to a range of 0-1).

It would be nice to see a log with the problem happening - particularly it would be nice to see that your RC inputs are meeting the RCn_MIN and RCn_MAX values specified in the parameters.

I’ve added a test for your specific case here:

Current code does seem to give the correct numbers there - note that this is a servo mount rather than a mavlink backend, 'though!

I’m leaning towards the problem being on the output side rather than the input side at the moment.

Those logs would be handy :slight_smile:

@peterbarker Thanks for looking into this.

I’m quite busy right now and not able to get you the needed logs.
I’ll get back to this as soon as possible, probably at beginning of next week.

Hi @peterbarker,

Here are logs with both ANGXXX_TILT settings:

MTN_ANGMIN_TILT = -9000 gives -90 degrees
MTN_ANGMAX_TILT = 11000 gives +10 degrees
2020-02-03 10-23-02_wrong_limits_work.bin (298.4 KB)

MTN_ANGMIN_TILT = -9000 gives -90 degrees
MTN_ANGMAX_TILT = 1000 gives -40 degrees
2020-02-03 10-25-08_correct_limits_not_working.bin (439.5 KB)

I’m not aware of a way to see the mavlink output from the logs. Let me know if there is a way.

Just making it clear that Qgroundcontrol MAVLink inspector shows that MAVLink output is not correct.


I had a quick look at reproducing this and I think the issue exists in Copter-3.6.12 as well. So not saying that it’s not an issue but just that it’s perhaps not a regression.

In the screen shot below you can see that I’ve got Copter-3.6.12 on the vehicle (a CubeBlack not that it matters) and the MNT_ANGMAX_TIL is set to 45deg but I’ve managed to set the target to 80deg using a mission command

Here’s a screen shot of the command just FYI:

I’m still investigating though…


I think I’ve discovered the issue that you’ve hit. It is caused by this PR which had the side effect of adding a requirement that the RCx_TRIM be set correctly. Looking at your logs it seems like the RC7_TRIM is set to the top of the range.

I will likely revert the portion of the above change that added the dependency on the RCx_TRIM value.

Thanks for the report!


I’ve reproduced the issue you were seeing and I’ve created a PR here which removes the reliance on the RCx_TRIM value. This will be peer reviewed and then I expect we can release it with Copter-4.0.4 that should start beta testing in about a month.