Why does pitch get reversed for storm32 gimbals?

Hardware
,
42

This is why I’m so confused. Setting the serial port for Mavlink2 solving all the problems just doesn’t make sense. Not that I’m complaining about it actually working properly. But if something is set incorrectly, and that makes it work correctly, there is definitely still a problem to address :slight_smile:

43

@olliw42 the guy who was having gimbal issues got it resolved. Turns out he didn’t have it configured for serial connection but for RC control.

44

All very encouraging, now if I can just get that t-storm32 built somewhere yehawwww

45

THX
good to know

now, the only explanation I see for why it is working is that the Solo smartshoot is NOT using the MAVLINK_TARGETING mode to control the gimbal, as I was assuming. This would fit also to the fact that the STorM32 ID 71 is used, and not 1, which is kind of breaking with Ardu’s “Mavlink gimbal rules”. I find the presumed bug, reported in the above and here https://github.com/ArduPilot/ardupilot/issues/7246, glaringly obvious.

So, guys: Which messages are used by Solo to control the gimbal?

46

now if I can just get that t-storm32 built somewhere yehawwww

the Eagle files for the v3.3 board and v2.x motor modules have been released
at rcgroups there had been some discussion about using an assembly facility, such as e.g. macrofab. It “just” needs to be attempted by someone. Maybe if you join forces with likes such as mike_kelly etc. it could lead to somewhere. The more participate, the cheaper.

47

It 100% is definitely using mavlink targeting mode.

48

It 100% is definitely using mavlink targeting mode.

thx. This of course makes sense. So, let me ask the reverse:

Does it use anything else than MAVLINK_TARGETING mode?

For instance, when the slider on the transmitter is moved, is this translated by whatever intermediate program into a mavlink message to the gimbal, or is the mount’s RC_TARGETING mode invoked?

49

During normal flight modes (not smart shots), the mount mode is RC Targeting using RC Channel 6 input. That input is derived from the paddle on the controller.

During smart shots, the mount mode is mostly Mavlink Targeting. There are a few specific instances where the user is controlling the gimbal during the smart shot and it switches back to RC Targeting. But for the most part, it is mavlink targeting. The smart shot sends MSG_MOUNT_CONTROL or MAV_CMD_DO_MOUNT_CONTROL with pitch and yaw angles, ignoring RC CH6.

50

many thx also for these clarifications

so, the main mystery, “How is it possible that the STorM32 works at all” remains.

It is simply a fact that (up to the latest release v2.33e) the STorM32 did use it’s own angle convention in the MAV_CMD_DO_MOUNT_CONTROL message.

This I think anyone can double-check/convince her/himself of by just sending mount_control messages “by hand”. So, how the heck can all those functionalities where a mount_control message is sent DIRECTLY (i.e. bypassing the mount code as in MAVLINK_TARGETING) be working ???

I would think that’s the question to which we can boil down the discussion.

Anyways, since the STorM32’s handling of the mount_control message is obviously wrong, this got corrected in the latest firmware release v2.33e of two days ago. This probably will momentarily add to the confusion.

BTW: In order to be sure about this claim, I just double checked also with the v0.96 code.

In the course of that I realized that there are differences between v0.96, and the latest firmwares. For reference I’d just like to list some further things:

  • The attitude and mount_status messages which the STorM32 sends out uses the angles in ArduPilot convention. The v096 does only allow attitude, mount_status and streams are available only in later firmwares.

  • The handling of messages is quite different for v0.96 and latest. For the latest firmwares it is as described in post 20. For v0.96 it is so:
    It accepts messages when the msg system ID is different from the gimbal’s system ID, plus if either

  • the msg has no target system
  • the msg has a target system = gimbal system and a target component = 0
  • the msg has a target system = gimbal system and a target component = gimbal component

It should be noted that the v0.96 response rules were set in place a year and more before the ArduPilot routing rules came to life. It should also be noted that the condition msg system ID != gimbal system ID effectively prevents the v0.96 gimbal to work as a component.

51

You suggest moving to a NT IMU, loading the new v2.33e firmware and it should correct issues within the v0.96 firmware?

52

loading the new v2.33e firmware … should correct issues within the v0.96 firmware?

yes

You suggest moving to a NT IMU,

no
I’m not implying that it would correct issues seen with Solo and STorM32. No idea about the latter. What I’ve seen so far doesn’t appear to follow a pattern.

53

But isn’t the v2.33e firmware for the 1.3x storm32 boards NT module required? Just trying to figure out what I should do.

54

yes, for using the v2.33e firmware you need an NT imu module

55

I want to move this back out into the forum since I think we’re homing in on solutions rather than problems now.

Looking at the flow in the code, here’s what I see:

STOCK OLD ARDUCOPTER used on a stock Solo

  1. Solo smart shots send MSG_MOUNT_CONTROL to ArduCopter (Sys ID 1, Comp ID 1). Example here in the multipoint smart shot: https://github.com/OpenSolo/shotmanager/blob/master/multipoint.py#L298

  2. Mavlink DO_MOUNT_CONTROL message is received here in GCS_Mavlink: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/ArduCopter/GCS_Mavlink.pde#L1831

  3. Then sent here to AP_MOUNT: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount.cpp#L573

  4. Then sent here in MOUNT_BACKEND: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_Backend.cpp#L45

  5. Then sent here in MOUNT_BACKEND to produce angle target variables: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_Backend.cpp#L8

  6. Those variables are read by the update() method in AP_MOUNT_STORM32 here. But without resend_now = true, it only updates the gimbal once per second which makes it jumpy: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L85

  7. AP_STORM32 then ultimately blasts out it’s own MAV_CMD_DO_MOUNT_CONTROL message with the angle information, to include reversing, here: https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L117

  8. That message is sent specifically to the Storm32 Gimbal using SYS_ID 71 / COMP_ID 67 as defined here (https://github.com/3drobotics/ardupilot-solo/blob/29ff0d7b45cb3e9ac50aeea91654ac3d1473b8b7/libraries/AP_Mount/AP_Mount_SToRM32.h#L20)

I think the fix here is to put resend_now = true; into the mavlink targeting case of ap_mount_storm32. There’s no sense in making it only set true when a message is received, because messages are received continuously anyway. So just setting it true should be fine. That will take care of the 1 second movements on the stock solo.

Is the SYSID = 71 and COMPID = 67 what your controllers use as default values? Do people every change them to something else? I guess the only use case to change it, would be if you have two gimbals? If there is a use case to change it, we should have a parameter for SYID and COMPID in ArduCopter.

ArduCopter master is very similar

  1. Solo smart shots send MSG_MOUNT_CONTROL to ArduCopter (Sys ID 1, Comp ID 1). Example here in the multipoint smart shot: https://github.com/OpenSolo/shotmanager/blob/master/multipoint.py#L298

  2. Mavlink DO_MOUNT_CONTROL message is received here in GCS_Mavlink: https://github.com/ArduPilot/ardupilot/blob/6c82f7671d8643c8ba21b596f9a9a5bf56a2f367/ArduCopter/GCS_Mavlink.cpp#L1657

  3. Then sent here to AP_MOUNT: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount.cpp#L578

  4. Then sent here in MOUNT_BACKEND : https://github.com/ArduPilot/ardupilot/blob/c808ee2f497e7a7a6d570632a3224e655b377323/libraries/AP_Mount/AP_Mount_Backend.cpp#L45

  5. Then sent here in MOUNT_BACKEND to produce angle target variables: https://github.com/ArduPilot/ardupilot/blob/c808ee2f497e7a7a6d570632a3224e655b377323/libraries/AP_Mount/AP_Mount_Backend.cpp#L6

  6. Those variables are read by the update() method in AP_MOUNT_STORM32 here. But without resend_now = true, it only updates the gimbal once per second which makes it jumpy: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L75

  7. AP_STORM32 then ultimately blasts out it’s own MAV_CMD_DO_MOUNT_CONTROL message with the angle information, to include reversing, here: https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L75

  8. That message is being broadcast to sysid 0 and comp id 0 as seen here, which also seems dumb. https://github.com/ArduPilot/ardupilot/blob/903ef4d065129f54354b06dc7cce72fafe4b231f/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L10

The only difference I see is blasting everything out to 0/0 instead of 71/67. Should this be changed to use 71/67 like it used to be? And same question as with the old version, is there a use case for making sysid and comp id parameters? It also needs the resend_now = true thing. If this is what needs to be done, it’s fast and easy for both the old ArduCopter and master.

Where in master is the problem with the yaw? That is very annoying, since I’m sure you saw I had to make it send different messages to make the yaw work.

58

Alright, let’s try this again… There is so much going on in this, and so many people reporting various things, that it’s difficult to keep my head wrapped around what is really going on. But I think I have at least a starting point.

  • You must set the Storm32 controller’s mavlink system ID to 1 and component ID to 67.
    The default SYSID is 76, and that freaks things out. I modified the old ArduCopter FW to use 1 instead of 76 for the Storm32. ArduCopter 3.5 will autodetect that you set the gimbal for 1.

  • You must set the mavlink dropdown in the Storm32 controller for heatbeat. Don’t use the other options.
    The other options like attitude status really aren’t used by anything and only serve to clog the mavlink traffic up, so don’t use them. You must not set it for no heartbeat or the gimbal will not be detected.

  • Must set the MNT_TYPE parameter for Storm32 Mavlink (not serial)

  • Must set Serial4_Protocol for 1 (Mavlink)

  • On the old Solo ArduCopter FW, you must set SERIAL2_PROTOCOL for DISABLED.
    On the that old stuff, there is no automatic detection of mavlink channels. It is hard coded to use the second instance of mavlink on a serial port. The first instance is always going to Serial 1 for the IMX. So the next has to be the gimbal on Serial port 4. That would make it the second mavlink channel. If you enable mavlink on serial 2, that would make the gimbal the 3rd channel and it won’t work.

  • On ArduCopter 3.5, it will auto-detect the mavlink serial channel, so just make sure serial 4 is set for mavlink and you’re good.

Please try this with the attached ArduCopter firmware and report results. Thx

ArduCopter 1.5.4 Solo S32 Fix.zip (489.6 KB)
ArduCopter_3.5.4_Solo_S32fix.zip (679.8 KB)

1 Like
59

it is sad that you had decided not to listen right away, wasting people’s time
at least you now seem to have decided to take comments seriously, sadly not yet all
you want to delete the long analysis post 4 posts back, as it contains several serious inaccuracies, as well as the settings in the last post, at least those for old arducopter-solo fw

btw, using codes of others without reference is widely considered malpractice

in the arducopter-solo fw:

  • remove also the other two lines, removing resend_now at two places, as I’ve suggested
  • revert the change of SYS_ID, and keep SYS_ID = 71
  • as I’ve explained, the handling of the has_pan as I’ve suggested and taken over by you, should be considered experimental. It is actually not really needed at this point, and should be removed.

in order to get it working on the old stock solo, there is one further point to be solved, namely the smartshot .py files, as I’ve also explained before. I can do that myself, or we can do it cooperatively.

60

WHAAAAAT? Ollie, this is why you didn’t get a lot of help from the dev team. You got insulting and irate with them for absolutely no reason. And now out of the blue you’re doing it to me too. All I’m doing is trying to help get your hardware to work. Nobody is ignoring you. But you’re doing a good job isolating yourself…

  • I deleted the above posts because they’re a waste of time to read and interfere with troubleshooting. Nothing to hide. You all already read them. They also had attachments that have been superceded.

  • Nobody is stealing your code.Ns nothing going on here is widely considered malpractice. Other than. Your crazy attitude. Inline comments with your name are not allowed. There is nowhere in ArduPilot where people put their name in the comments to demand recognition. My code is all over in many places without my name. You’re welcome to do a PR if you want your name memorialized as a contributor. But you’re refusing to do that and sent me code to put in for you.

  • I asked why that haspan was needed to begin with and you didn’t answer. Since I decided put the rest of that checking in, I out the haspan in too, since I assumed you had a reason. So don’t complain that didn’t use it, then complain that I used it. Make up your mind.

  • The system ID being 1 on the old firmware is what you suggested earlier in this thread. And it’s what it should be to begin with based on mavlink standards. Unless you now have a better reason to make it 71 again?

  • If you would prefer to do all of this yourself, please feel free. There are other things I could have been doing the last three evenings than trying to fix the drivers for your controller, which I do not even own.

61

fact is I worked out the issue(s) and solution(s), indicated and explained them to you including code, it is you who decided to ignore comments and explanations and to jump into the wild with inaccurate codes and guide lines, and yet you appear to think that this is proper, respectful cooperation. I don’t.

I had explained the has_pan situation. It doesn’t make sense to me to respond to later questions which ignore previously given info. I have never said that the ID should be changed to 1 for arducopter-solo. What many appear to fail to see is that what is considered “mavlink standard” has significantly changed over time, and was quite different at the times of AC3.3/AC3.4 than for AC3.5 and today, which makes that argument stale.

As I’ve explained to you solving all this is not my cup of tea. I’ve also explained to you that if you feel that you do that for me that then you totally got it wrong and shouldn’t do it at all. You really can’t blame me for having spend 3 days, since if you would have taken my suggestions instead of your diversions it would have saved also you time. I too could have doing many better things in the last two weeks than trying to weed out ArduCopter/Solo issues.

Given that Solo is a dead horse anyhow, I guess we should stop this here, and advise Solo users to look for gimbals with alternative controllers.

All the best, Olli

62

That is all untrue. Completely.

Im not going to argue back and forth about this since you’re being completely unreasonable and insulting for absolutely no reason at all… If you’d like to contribute towards your own driver for your own controller at this point, as the saying goes: PRs welcome. Have a lovely day.

In the meantime, I will continue to work with the others in this thread and on the Facebook groups to find a working solution.

63

to conclude things from my side:

A) I wish to seriously apologize for any wording which may have been considered insulting. I do however stand to the contents.

B) I’d like to share my findings about Solo and STorM32 (copying from PMs), just in case it may be beneficial:

I got the smart shots working on ardupilot-solo1.5.3 or at least for cablecam/multipoint at the moment; it needs some changes in the .py files, which I have only done momentarily for mulitpoint.py. It is not yet working perfectly, because the ardupilot AP_Mount class for StorM32 sends the mount control to the gimbal only every 1 sec when in mavlink_targeting, so the pitch is quite stepy. It’s easy to correct. I think I know very precisely what needs to be done, in arducopter-solo.

This video I did some days back:


Ugly, I know, but it shows a two point cable cam with camera interpolation in pitch and yaw. This is with stock cube, arducopter-solo 1.5.3, Solo App, and works with any STorM32 (it needs adaption of the smartshot .py’s, but that’s needed anyhow, and is simple since it’s just drag&drop). It clearly shows that everything is working fine except of these “pitch jumps” every 1 sec. This is obviously due to the fact that arducopter sends out a message to the STorM32 only every 1 sec when in MAVLINK_TARGETING.

There are various different approaches one can take, from very simple to “smarter”, depending on preferences, and how much one would be willing to invest.

The most simplest solution would be to simply change the define AP_MOUNT_STORM32_RESEND_MS from 1000 to e.g. 100, or maybe even 50. https://github.com/OpenSolo/ardupilot-solo/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.h#L23
Alternatively one could insert a “resend_now = true;” in here https://github.com/OpenSolo/ardupilot-solo/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L61
One could do somewhat better. One could e.g. add a uint16_t _counter and emit a message every 5th or so update. Or one could e.g. track the last angle values, and trigger a send then they have changed. This would reduce the workload to what is needed. Or one could add a bool _anglesupdated which is set whenever a new angle is set, so that the update() knows of it. … Each of these would be few more, but straightforward lines, which I could provide. Many, simple options, one just needs to decide.

If one wanted to, one could also discuss weeding out other issues (for each I could provide code). E.g. a proper handling of the has_pan_control() flag. As I see from the shotmanager .py’s Matt also stumbled across the fact that ArduPilot does not suppress a yaw pan of the camera, as it is supposed to when has_pan_control is false. This discussion would be benefitial also for any future ArduPilot versions (3.6).

I think the simple changes to avoid the 1sec pitch jumps would already be a significant step forward.

To give … an idea of what we are talking about, a code suggestion
AP_Mount_SToRM32_new_lastmethod.zip (3.3 KB)
One can trace my changes by searching for //OW. I here choose the “track changes” approach, since it affects only the two files (the “anglesupdated” approach would need also changes in the backend) and yet it should be good a keeping the traffic low. I also added the suggestion for dropping the yaw response in case of has_pan_control = false, which will work for Solo in mavlink targeting, but I’m not 100.00% sure if it’s correct in all possible situations.

Would these changes apply to ArduCopter master too? I’m not sure. ArduCopter master has some additional issues/bugs not present in ardupuilot-solo, and some of them I just can clearly “see” but do not see the origin in the code. That’s why I’m only talking about arducopter-solo.

Master has some additional issues. I have looked carefully at the mavlink messages which the STorM32 receives, and in master the routing definitely makes it get additional messages. Unfortunately, from looking at the code it is not at all clear to me why this is so. And there are further issues. So, I don’t think that one can simply extrapolate from ardupilot-solo to master.

In addition to the changes in ardupilot-solo, one needs also changes in the smartshot manager’s .py files. That’s mostly because ardupilot-solo uses the “old” mount messages while master uses the “new” mount messages, so there is no way out (unless one would backport the “new” messages to ardupilot-solo, which one probably doesn’t want to do). In the course of that I’ll also clean up the py codes a bit, which will remove some few bugs&inconsistencies. I’ll certainly provide these files too. They’re easy to “install”, they just need to be copied over to Solo. The bottom line, without these files it’s pointless trying to test the new .px4.

One unavoidable consequence will be that one needs different .py files for arducopter-solo and for master (I’ll abstract it to a point that it is a change in only one place). Or: there is a means for the scripts to detect which version is installed, and to adapt itself to this. The latter I have not yet figured out however.
15.Dez.-20.Dez.

1 Like