Gimbal hardware for RandyM

Topic:3-axis Gimbal Hardware for Randy

Proposal type: Hardware [x]

Description:

I’m working in improving our gimbal support (see issues uncovered here) and it would help my development and testing if I had the hardware to at least bench test each of these gimbal controllers:

Planned amount $315 (USD) + shipping ($100?)

Estimated time for completion: 1 month

Note: removed the HAKRC SToRM32 : (12730 JPY) $100 USD

6 Likes

I approve ! :slight_smile: Thanks Randy

How relevant are those gimbals and controllers in 2022?

Randy has alerted me of this post in Gimbal enhancement list · Issue #20985 · ArduPilot/ardupilot · GitHub, and if I didn’t got it wrong was asking for an opinion on STorM32 gimbals.

Sadly, the reality is that there is no thing like a STorM32 gimbal which could be purchased or would be available otherwise.

The listed HAKRC gimbal does indeed use a STorM32 controller, but its IMU is connected via the I2C bus, which was given up by the STorM32 project something like 5 or more years ago. That is, one only can run this gimbal with firmware version v0.96, which is said years old. One implication is, that its MAVlink capabilities is not up to date, and in fact is “incorrect”, as the whole comp_id thing wasn’t worked out on all sides at this time. To cut a long story short: I really cannot recommend this gimbal as-is for any effort to modernize gimbal drivers.

The minimum one would have to do, IMHO, in order to be able to use the latest STorM32 firmware, is to replace the I2C based IMU by an NT bus IMU, which implies some manual labour for the conversion. What is more serious is that there are essentially no good sources anymore for getting NT IMUs … the Corona & chip crisis appear to have been kind of last nail in the coffin. ENSYS lists some as available, STorM32 NT IMU Module v3.0 – ENSYS. Gapey builds on demand, but I’m not sure he still does or is able to (we have a war since few months in Europe) Assembled PCB Storm32 / T-Storm32 - Сайт t-storm32!.

To make it even worse, one also has to face the fact that - in my observation - the v1.3x type controllers on the market, which is also on the HAKRC gimbal, started to lack quality. It kind of appears that all stuff which wouldn’t had been sold few years back are now cleared out at all costs.

I guess I don’t have to find words for a summary. My conclusion is probably self-explanatory.

Even though it’s already a very long text, I’d like to grab the opportunity for exposing what I think could be an approach to this situation.

The STorM32 serial driver could be with little changes updated to work also with later firmware versions (at least I think so … 5 years is a lot time to lose memory of details LOL). There are indeed still users of I2C based STorM32 gimbals, so some minimum support might be appreciated.

The current MAVLink-based STorM32 driver could be replaced by a generic MAVLink gimbal driver, which can be designed such as to work with any MAVLink enabled gimbal, specifically Gremsy, Alexmos, STorM32. It could be resulting from overlapping of what is currently there for Gremsy and STorM32 in the BetaPilot fork.

I find it important to add, that, since STorM32 still sees development (at varying pace), I would not think that an extra STorM32-Mavlink gimbal driver is reasonable. I try to keep the BetaPilot somewhat up-to-date, and anyone serious with STorM32 can use this. I thus would think that the mentioned generic MAVLink gimbal driver should be indeed generic, which IMHO implies that it should conform to some standard, which all parties can settle for.

Not sure this is very helpful, and sorry for the long text,
Olli

1 Like

@olliw42,

Txs for the insight.

So sounds like the HAKRC gimbal isn’t useful and there aren’t any easy-to-buy replacements that I could order for either the I2C or NT versions of STorM32 which leaves me in a bit of a pickle when it comes to testing whether my changes improve or break these drivers.

I’m happy to update the STorM32_serial driver to work if you think some users out there would find that useful. On the other hand, if we can’t find any interested users it might be just as well to remove the driver and focus our efforts elsewhere including the STorM32_mavlink driver. I peeked at the BetaPilot AP_Mount library and it looks like you’re perhaps not maintaining the STorM32_serial driver either so perhaps we should just let it go? I’m OK either way I just might need some direction if we want to rescue it.

Re the STorM32_mavlink driver, should I look at blending in the changes you’ve made here? If “yes” and after I do that, maybe you could help me test?

By the way, I certainly like the idea of a single MAVLink gimbal driver but so far I’ve seen 3 different mavlink implementations (STorM32, Gremsy, NextVision) and they’re all different enough that I fear I would be unable to actually make it work. So for now I think I’m going to stick with separate drivers and hopefully the day will come where we can make them all inherit from the same base class.

-Randy

I think Gremsy gimbals are very common now . Maybe Gremsy would send something…

Hi @norim,

Yes, Gremsy has been kind enough to send me a Gremsy PixyU and this is my main testbed of various gimbal enhancements (see latest discussion here).

My core problem is that I can’t properly test if these enhancements are working correctly on the other gimbals we support.

So sounds like the HAKRC gimbal isn’t useful and there aren’t any easy-to-buy replacements that I could order for either the I2C or NT versions of STorM32 which leaves me in a bit of a pickle when it comes to testing whether my changes improve or break these drivers.

yes, concerning this type of gimbals the market situation has changed fundamentally in the last half decade

to throw a bit more salt into the soup, from the pictures the linked-to DYS gimbal appears to have an old 8-bit Alexmos 3-axis board and might not be what you actually would hope to have either

I’m happy to update the STorM32_serial driver to work if you think some users out there would find that useful. On the other hand, if we can’t find any interested users it might be just as well to remove the driver and focus our efforts elsewhere including the STorM32_mavlink driver. … perhaps we should just let it go? I’m OK either way I just might need some direction if we want to rescue it.

no comment. Not a decision I’d like to get involved with :slight_smile:

It seems to me that the lowest common interface of all these gimbals (including the tarot) is two wires for controlling pitch/yaw via rc signals. One probably could add a 3rd for switching from pan - lock, if a gimbal supports that.

I peeked at the BetaPilot AP_Mount library and it looks like you’re perhaps not maintaining the STorM32_serial driver either

correct. I am working only on the TYPE=83 driver and what it needs (while also trying to keep the infection of any other code as minimal as possible).

Re the STorM32_mavlink driver, should I look at blending in the changes you’ve made here 1? If “yes” and after I do that, maybe you could help me test?

I’ll PM.

By the way, I certainly like the idea of a single MAVLink gimbal driver but so far I’ve seen 3 different mavlink implementations (STorM32, Gremsy, NextVision) and they’re all different enough that I fear I would be unable to actually make it work

sad to hear. I would think that it would need just few not very significant changes on the gimbals sides to support a common subset. Anyway.

I fear I would be unable to actually make it work. So for now I think I’m going to stick with separate drivers and hopefully the day will come where we can make them all inherit from the same base class.

I sure understand why you consider this the proper approach. Btw: One other reason for the split into gimbal manager - gimbal device was exactly to allow handling different gimbals behind the curtins of a common interface exposed to the outside (= joysticks, missions, gcs, …), even “dump” gimbals like those which only accept rc signals.