Does anyone use SToRM32 Serial gimbal driver?

[rmackay9]

Does anyone use the SToRM32 Serial gimbal driver (e.g. MNT_TYPE = 5)? I think SToRM32 gimbal users all use the SToRM32 MAVLink driver or use RC passthrough to more directly control the gimbal from the RC.

The reason I ask is that ArduPilot 4.3 includes some significant improvements to our camera gimbal support but I would also like to remove older drivers that nobody is using because this will save some development and support effort. I think we can safely remove SToRM32 Serial driver but I wanted to ask first.

4.3 will still have the Servo, Alexmos Serial, SToRM32 MAVLink drivers and a new Gremsy driver.

[rmackay9]

@olliw42,

We have a reply on the parallel facebook post where the user says that the SToRM32 Mavlink driver doesn’t work with his older Storm32 v1.32 board (so he must use AP’s SToRM32 serial driver). He says you’ve already confirmed this but I wanted to hear it “straight from the horse’s mouth” so to speak…

[silentjet (Andy)]

Yup faced the same issue last year…

[olliw42]

hey @rmackay9
thx for pinging me
(btw, fyi, I’ve dropped your post also in the storm32 thread at rcgropus)

I cannot respond with 100% authority, since I never actually tested these drivers myself, only looked at the code a while back
however:

the issue is not the board type, but whether a user uses a I2C setup which limits the user to firmware v0.96, which is extremely outdated
the issue is however that the storm32 gimbals you (still) can buy (like the one you recently suggested in a thread of yours) all do have an I2C setup… that is, anyone who wants a quick entry into gimbals and has bought or buys today a storm32 gimbal gets a I2C setup i.e. firmware v0.96 …
in order to use latest firmware you need to convert to a NT setup, which implies additional hoops to jump through… which not all do … (it’s sadly also difficult to get NT parts these days)
the message: there are two groups of users, those limited to v0.96 firmware and those running latest firmware

my understanding of the drivers is that the serial driver is restricted to v0.96 firmware, but won’t work properly with latest STorM32 firmware. For the storm32 mavlink driver I’m not sure from top of my head what the situation is, what is sure is however that v0.96 firmware does NOT have MAVLink implemented according to standard !! (at the time of v0.96 it was thought to be the right way, but the standard progressed substatially concerning components since then) It appears thus natural to conclude that the storm32 mavlink driver won’t work properly with firmware v0.96…
It might well be that at the time where the one facebook user was asking I might have had a better knowledge on the mavlink diver, that is: if the facebook user says I confirmed it to her/him, then that’s likely accurate…

hence, to sum up, the situation seems to be

• users of I2C setups/firmware v0.96 may want to use the storm32 serial driver
• users of NT setups/later firmwares may want to use the storm32 mavlink driver

in addition - at least in my own very subjective estimation - many of the NT setup/later firmware users seem to be willing to go with betapilot … i.e., it may not be so clear how much use the mavlink driver is actually seeing

it’s a bit of a complicated situation, lot’s of history in here and also recent events … anyway, hope this brings a bit of clarification

(btw, I just try to compile the “facts”, I’m not and am not trying to express some own opinion or similar)

[rmackay9]

OK, thanks for this feedback. We will keep the SToRM32 serial driver available then. I’ve created a PR to improve the wiki instructions to point users towards the correct driver to use (e.g. MAVLink vs Serial).

[olliw42]

I’m not sure I am happy with that wiki changes are made based on what I stipulated in the above … I mean, I just looked at the wiki, and it seems to me it is potentially outdated (wrong?) in more places … I think the facts should first be established and then the wiki be updated to the facts

for the moment I see only one fact: the serial driver does not work properly for latest firmware but only v0.96 (this is so because it uses the ‘d’ command to read the angles, and the layout of the return structure has changes somewhat)

with regards the mavlink driver the situation is less clear
e.g. if sysid = 71 indeed works as suggested by the wiki why doesn’t it work with v0.96
I wonder, is it actually working at all with latest firmware? (there is this factor 100 bug in AP since 4.x)
a can of worms here

i.e., I am not convinced you are actually improving the situation by basing on non established facts

[rmackay9]

@olliw42,

We can always update the wiki again and I think the changes are an improvement. Basically it’s just improved formatting and adding these two lines:

• SToRM32 gimbals with I2C setups and firmware v0.96 should use the SToRM32 Serial driver
• SToRM32 NT gimbals running firmware above v0.96 should use the SToRM32 MAVLink driver

… So moving on, I agree that we should figure out if these drivers work. I assumed they worked but maybe not.

@silentjet do you think you could put “latest” on your vehicle and test either the SToRM32 serial or MAVLink driver for us? The key things to test are:

1. Can the angle of the gimbal be controlled from the transmitter?
2. In addition to (1), If the gimbal is a 3-axis gimbal then setup an auxiliary switch to switch between “follow” and “hold” (set RCx_OPTION = 163 (Mount Lock)) and confirm the gimbal’s yaw moves correctly in each mode.
3. Does the gimbal move correctly when the pilot right-moust-button-clicks on the MP map and selects, “Point Camera Here”
4. Does the MP’s Data, Actions tab’s Mount control drop-down and “Set Mount” button allow the pilot to control the mount’s mode (e.g. retracted, neutral, RC-targetting, etc)?

I’ve posted a link to Divyanshu Harkhka who responded on the facebook post and hopefully he can help us test too.

[harkhka (Divyanshu Harkhka)]

Hello @rmackay9,

Just to clarify the air a bit, yes I was talking about using an I2C sensor with v0.96 firmware only, because it is widely available with all the storm32 gimbals and getting an NT sensor is kind of a pain, specially these days. Sorry for not specifying the firmware version earlier.

With the I2C sensor and v0.96 firmware (which a decent amount of storm32 users are using), it is almost impossible to use the device with storm32 Mavlink protocol. Using an I2C sensor only works with the Storm32 Serial protocol.

In the past I did some experiments and discussions to find out the “factor 100” problem which @olliw42 was mentioning.

You can read that discussion here: RC Groups - View Single Post - STorM32 BGC: 32-bit 3-axis brushless gimbal controller

Please read from post 13633 to 13640. I did everything I could to find the problem, and even probed the mavlink lines with an STM32 to see the data sent from the Arducopter. Details are in the discussion.

I would be happy to help you to test the code if needed.

Thanks,
Divyanshu

[olliw42]

@harkhka
many thx for posting your knowledge here.
I just loosely recalled things but didn’t recall the details. The link plus followup posts however really give a quite good summary of the issues at hand.
So, you are confirming the “factor 100” issue as culprit, as well as #13638 figures that v0.96 gimbals cannot work as mavlink component.

So, I am afraid the situation appears to be

1. I2C setups/v0.96 can only work with the serial driver and never ever will work with whatever mavlink driver
2. the STorM32 mavlink driver may not be ever fully functional again, because the “factor 100” issue is not (likely) to be ever resolved in AP (I had rasied it few times in the github repo, and one time peterbarker responded in that sense)

[rmackay9]

OK, for reference I think this is the issue you’ve raised re “factor 100”
- Bug in Mavlink MOUNT_CONTROL handling · Issue #7384 · ArduPilot/ardupilot · GitHub

I had a look for 13638 but I couldn’t immediately find anything.

I’ll ask @peterbarker if he remembers the issue but I guess we are either sending mavlink commands to the SToRM32 mavlink gimbal that are 100x too big or 100x too small.

I think anything is fixable. Worst case we may need to change the enum for the SToRM32 MAVLink driver to a new number in order to ensure that users actively move over to a corrected version.

[olliw42]

this is one of the threads, but - I think - there is also a later one with a more clear conclusion of peterbarker

concerning 13638, you may find it easier to go with this link: STorM32 BGC: 32-bit 3-axis brushless gimbal controller - Page 273 - RC Groups
it jumps into the thread and not into the post, which should make it more convenient to scroll through

it’s 100x too small (that’s why folks initially believe it doesn’t work, since e.g. 45° just does 0.45°, which is then not noticed …)

the rcgroups posts 13633-13640 are really readworthy as they sum it all up quite clearly…

sure, anything is fixable … but obviously not everything fixable is being fixed (this is frankly all known since ages and not news at all)

concerning a new enum, my hope would be that there would be a MAVLink compliant driver … ( I may have voiced this hope before LOL)

the “100 factor” issue may not be totally trivial, it goes through various parts of AP code

btw, STorM32 does what the standard says, so a standard compliant driver would solve it automatically for STorM32 …

[rmackay9]

@olliw42,

I did a test of what AP’s SToRM32 MAVlink gimbal driver is sending and it appears that it sends the roll, pitch and yaw targets in degrees when using the DO_MOUNT_CONTROL message. Below shows some debug output after I clicked on the MP map and selected, “Point Camera Here” (with Alt = - 100).

I guess you’re saying that the SToRM32 gimbal expects it in centi-degrees?

The mavlink message description (upstream, AP mavlink) is slightly vague on which it should be but in the end I’m happy to change it so that it actually works. I just need someone to help me test my changes so we’re sure.

Maybe I’ll post on that RC groups thread and ask for someone to help test over here (or in a new thread here).

I’m also happy to try and bring over the SToRM32 MAVLink driver from BetaPilot but I think I can’t do that due to lack of available hardware. If we can somehow get over this hardware issue that would be nice… but…

[olliw42]

I guess you’re saying that the SToRM32 gimbal expects it in centi-degrees?

no, it expects it in degrees, since ever, and today

(today: MAVLink Communication - STorM32-BGC Wiki)
(since ever: Serial Communication - STorM32-BGC Wiki V1)

The mavlink message description is slightly vague

I don’t think so, I think it is crystal clear. It says “pitch depending on mount mode (degrees or degrees/second depending on pitch input)”. Since it’s not rate = deg/sec, it only can be deg. Never cdeg.

I repeat, this (and other) issue wasn’t there before 4.x … I must admit I don’t like the tendency to mystify this matter … the mavlink spec has not changed from AP 3.x to 4.x, that’s a fact … so if things were ok in 3.x but started to fail in 4.x … connect the dots

I think you first want to get the code paths outside of the STorM32 drivers corrected. In the github link which you cited I have given most if not all pointers (I hope they still refer to the correct locations), and just by looking at these code pieces it should be obvious that something is wrong. E.g., look at which message expects int and which float and compare to the function headers …
It’s the deprecated MOUNT_CONTROL message which wants cdeg, while the command wants deg, that’s what AP mixes up

I am not sure this is helpful, and I don’t really expect anyone to do it, but seraching in the betacopter fork for //OW woul retrieve a couple of comments which refer to the “factor 100” bug, i.e., may give pointers to places to look at

I may sound inappropriate, but I really think you need to understand what’s up in the AP code base before venturing into “solutions” (and I also think you want to connect with peterbarker and double check with his reasons why it couldn’t be resolved before)(from what I recall, he eventually fully acknowledged the issue but said it can’t be changed without breaking some things)

why is all this always so difficult? I am saying all this literally for the fifth or so time now. You may understand that it feels a bit tedious. Anyway, I really appreciate your current efforts, it looks like you are serious with looking at the issues, very much apprecited.
(I only would wish I wouldn’t have to say things always five times LOL)

[rmackay9]

Hi @olliw42,

Ah, ok. Somehow I was thinking that there was an issue in the SToRM32 mavlink driver but now I understand that the problem is at the higher level handling of the MAV_CMD_DO_MOUNT_CONTROL command.

I’ve created a PR which corrects the problem I think.

Somewhat tangentially, I’ve also made AP send deprecated warnings to the caller if they try to use the MOUNT_CONTROL or MOUNT_CONFIGURE messages. These messages work but they’re not very well structured and we’ve got better alternatives now.

After these PRs go in I plan to create another wiki page on our MAVLink interfaces area to describe how users can control the gimbals using mavlink.

[olliw42]

first off, as said in the PR also, this is really fantastic that you are taking the steps to solve that … I fully understand the pain in this process given it involes also all the GCSes and all sorts of other parties. It’s really a major step you do here, and I am amazed to see it happen.
(somewhat sad though it took > 5y, the Solo and STorM32 could have been a great couple)

I am not saying that the STorM32 mavlink driver may not have some problems, but the “factor 100” problem isn’t

I think it is a good decission to factually deprecate the MOUNT_xxx messages (they had been deprectaed in the .xml since long, I think)
might make it interesting for the Solo though

so I guess my job is done here LOL (“only” need to get the v2 gimbal messages streamlined now :))

[rmackay9]

Hi @olliw42,

Txs for the feedback and encouragement. Sorry it took so long.

I’ve created another PR which resolves another long standing issue with the SToRM32 drivers. The issue was that they always returned “false” when asked if they had pan control. This meant the vehicle would unnecessarily point its nose at the Location (sent by a DO_SET_ROI, etc) instead of letting the gimbal do the work.

I’m pretty sure you were aware of this bug too because I think it was mentioned in the comments of the earlier PR.

There is actually still one last issue which is that the gimbal drivers are not always respecting the angle limits specified by the user in the MTN_ANGMIN/MAX_xxx parameters.

[olliw42]

@rmackay9
well you are now touching two very difficult topics, and I cannot give you clear ideas on either, just provide some random thoughts. I will need to think carefully about a reponse, to not say nonsense. Just this hence:

Generally, I think things need to be very well thought through, since otherwise it’s easy to limit the use scenarios too much.

Generally, I think one can’t get away with deducing has_pan from other parameters, like min/max angles. Might work in few specific situations.

pl note that gimbals may have also slip rings on yaw, and can turn around indefinitely. Also this you want to reflect in has_pan and min/max angles settings & behavior.

[silentjet (Andy)]

@rmackay9

do you think you could put “latest” on your vehicle and test either the SToRM32 serial or MAVLink driver for us?

yup, I will try to… But it will take some time, since working with some plane staff ATM